Hello, Mohammed.
Post by Alan Mackenzie#include "gtk/gtk.h"
, I also get the unwanted spaces. If this is what you mean when you say
that electric-spacing-mode "breaks", it might well be a problem in
electric-spacing-mode, which you would probably do better to report to
I don't know which version of electric-space-mode you are using.
When I try from master (from melpa) #include "gtk/gtk.h" have no issues.
Fair point! Yesterday, I actually had an older version of
electric-spacing-mode.el, dated November 2015, which I got from GNU elpa.
I've just downloaded electric-spacing-20161113.916.el from the melpa
website, and I still see unwanted spaces inserted when I type a "/" after
#include "gtk .
Which version are you using? Maybe the differences we are seeing are
caused by something else, not electric-spacing.el itself.
However, in the following function (from ...-20161113.916.el)
(defun electric-spacing-/ ()
"See `electric-spacing-insert'."
;; *nix shebangs #!
(cond ((and (eq 1 (line-number-at-pos))
(save-excursion
(move-beginning-of-line nil)
(looking-at "#!")))
(insert "/"))
(t
(electric-spacing-insert "/"))))
, it seems clear that the spaces are inserted around a "/" everywhere
except on the first line of a file when that line begins with "#!".
Post by Alan MackenzieThis would be a lot of work. The character "<" is a syntactic horror in
CC Mode, since it has three distinct uses: (i) less than; (ii) A
delimiter in #include <foo.h>; (iii) a template/generic delimiter in
C++/Java. I wouldn't really want to undertake this work unless there
were a clear advantage in doing it, and there weren't a simpler way of
fixing whatever problem it was causing.
in #include <stdio.h>, <stdio.h> is already having a style like a string.
ie, `face-at-point' returns font-lock-string-face
So would setting syntax-ppss be hard?
It would not be particularly hard (I've done something similar for
template/generic delimiters in C++/Java), but it would be tedious and
take a long time.
The way to do this would be to set "string" syntax-table text properties
on the pertinent "<" and ">". But, consider: these properties cannot be
set on a single "<", they must be set on "<" and ">" in pairs, otherwise
the single "<" in an incomplete "#include <" would make the rest of the
file into one long string (more or less).
Everytime a "<" or a ">" is inserted OR DELETED, the code would have to
analyse whether it's a less/greater-than, a template delimiter, or an
include file delimiter. Assuming it's an include file delimiter, the
code needs to check whether a syntax-table text property needs to be
applied OR REMOVED. More involved checking would be needed to remove the
text properties when "#include" is damaged, say to "#includee".
And anyway, at the time when you would be typing the "/" in
"#include <gtk/", the "<" wouldn't yet have the "string" syntax-table
text property (see two paragraphs back), so I'm not sure what would be
gained by applying these properties to the "<" and ">" later.
And so on..... It could be done, certainly, but it would be a lot of
work.
Question: why can the analysis of this situation not be performed in
electric-spacing-/? All that would be needed would be an extra arm in
the `cond' form which would check for "^[ \t]*#[ \t]*include[ \t]+[<\"]"
at the beginning of the current line. This would be direct, safe, and
much less involved than modifying CC Mode.
--
Alan Mackenzie (Nuremberg, Germany).
------------------------------------------------------------------------------