[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fontifying unterminated strings [was: CC Mode and electric-pair "problem
From: |
Alan Mackenzie |
Subject: |
Fontifying unterminated strings [was: CC Mode and electric-pair "problem".] |
Date: |
Tue, 26 Jun 2018 16:08:50 +0000 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
Hello, Stefan.
On Mon, Jun 18, 2018 at 21:48:41 -0400, Stefan Monnier wrote:
> > char *foo = "foo;
> > int bar = 5;
> > char *baz = "baz";
> > The entire second line, and the third line, up to the first ", get string
> > face. We've been used to this for so long that we've lost sight of just
> > how bad and amateurish it really is.
> But what about when you write
> char *thedoc = "Here it is:
> - First do this
> - Then do that
> And that's it!";
> ?
> Both cases are valid transient states. Which one will occur more often
> depends a lot on the particular kind of code you write and your
> coding habits.
I suggest the most common case by far will be writing
char *foo = "foo....
in the middle of an existing buffer.
> Emacs can't reliably distinguish the two cases, so whichever behavior it
> chooses it will look "amateurish" in some cases.
No, you've misunderstood my point. It is not the aesthetic "niceness",
the lack of which is amateurish; it is fontifying as a string something
which isn't a string (as defined by the compiler's error messages).
> I think the better option here is to focus on the following:
> 1- Make sure the programmer is aware there's a problem in its code.
> I.e. highlight the opening quote or the non-escaped end-of-line or
> something in bright red or something like that.
> 2- Don't try to guess what the user intended to do.
> Instead keep our code as simple as possible: the C code we're handed
> is broken, so there's no real clear "right behavior" anyway.
How about the following suggestion - instead of having permanent
string-fence syntax-table text properties to define the ends of
unterminated strings:
(i) We leave the syntax of the string opener and EOL alone;
(ii) we amend font-{lock,core}.el to apply the desired fontification, to
be like the new fontification in CC Mode?
This could be done straightforwardly in font-lock by temporarily putting
the string-fence properties on these strings, applying all the face
properties, then removing these properties again. It would need a few
new customisation variables to specify what counts as an open string,
and so on.
> -- Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- Re: CC Mode and electric-pair "problem"., (continued)
- Re: CC Mode and electric-pair "problem"., Alan Mackenzie, 2018/06/18
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/18
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Stefan Monnier, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Clément Pit-Claudel, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Stefan Monnier, 2018/06/19
- Re: CC Mode and electric-pair "problem"., Clément Pit-Claudel, 2018/06/20
- Fontifying unterminated strings [was: CC Mode and electric-pair "problem".],
Alan Mackenzie <=
- Re: Fontifying unterminated strings [was: CC Mode and electric-pair "problem".], João Távora, 2018/06/26
- Re: Fontifying unterminated strings [was: CC Mode and electric-pair "problem".], Stefan Monnier, 2018/06/28
- Re: Fontifying unterminated strings [was: CC Mode and electric-pair "problem".], Stefan Monnier, 2018/06/28
- Re: CC Mode and electric-pair "problem"., Stephen Leake, 2018/06/18
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Clément Pit-Claudel, 2018/06/18
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/19
- Re: CC Mode and electric-pair "problem"., Alan Mackenzie, 2018/06/19
- Re: CC Mode and electric-pair "problem"., Stefan Monnier, 2018/06/20
- Re: CC Mode and electric-pair "problem"., Alan Mackenzie, 2018/06/26