Re: CC Mode and electric-pair "problem".

[João Távora]

Alan Mackenzie <address@hidden> writes:

> Hello again, João.

Hello again, Alan

> On Mon, Jun 18, 2018 at 18:01:18 +0100, João Távora wrote:
> Probably other people have thought of it.  The actual doing was quite
> involved.  But maybe we'll see whether or not the idea spreads.
>
>> > We could argue about words like "terminate" indefinitely.  What I
>> > think is incontrovertible is if you open a line in a string, the
>> > portion after that opening is not part of the string opened on the
>> > line above.  The new fontification reflects this fact.
>
>> OK, but now reflects it reflects something that is also wrong (they're
>> not statements either), but to a much greater degress. And on top of
>> that with many more adverse side effects, of which only one is breaking
>> e-p-m mode.
>
> How adverse are they really?  I mean, I think you are currently in the
> "looking for flaws" mode, which is essential, worthwhile, and
> appreciated, but if you were just using, say, C++ mode, how bad would
> these side effects actually be?  That's not a rhetorical question.  It's
> about deciding whether to invest the work to make the "correct" behaviour
> optional.

Honestly, I don't know.  You're right I am indeed in "looking for flaws"
mode.  "Once you see it, you can't unsee it".

After reading your example below, I think the feature you are adding is
good for people who inadvertently delete the terminating quote, but not
for those who once in a while add a newline inside a string.  I am in
the latter group: I almost never unbalance by buffer (thanks mostly to
e-p-m) and I like to navigate by sexp, even in languages other than lisp
(even in message-mode, for instance).  So I get sad when something
breaks this balance.

>> > I've tried this, obviously, but as far as I'm aware, the operation of
>> > C-M-* is correct for the (now syntactically incorrect) buffer.  If you
>> > can give me a concrete example, I can look at it and correct it.
>
>> It's now much hard to select the whole invalid string.  It used to be a
>> matter of C-M-u C-M-SPC.  To use query-replace in the region, for
>> example.
>
> OK, thanks.  But how often does this happen?

Well, there's obvious the case of actually writing a multi-line string,
such as when writing a "usage:" blurb.  Here I believe most users, like
I, will first draft out the string visually and then add "\n\" to every
line, perhaps by selecting the string where point is in, which is now
much harder.

While it's true I don't write many of those lately, it will probably bug
me much more often in another situation: I'm in the the habit of C-o'ing
a lot (everywhere, not just in strings, obviously) to "open space" for
my thoughts, i.e. for the thing I am going to write next.  And this new
behaviour breaks that.

But now I've tested a bit more and can be specific: it breaks *some* of
that. C-M-u C-M-SPC is indeed broken.  That's what I use, for example,
just before I deciding to replace the string with a variable.  But
curiously, chomping to the end quote is working, which is nice.  And if
I can somehow make it to the closer quote, C-M-b works, though C-M-f at
the opener doesn't.  In any case, things were more predictable before.

>> These accidents, as you have them, work just fine in just about any
>> other mode I can imagine.  And they worked just fine in c-mode up until
>> your change.
> I suspect it is more that people have got so used to them, that any
> change will appear to be bad.  Maybe.

As we all know, Emacs is fertile in this regard. For example, I can
think of a certain version control system, rhymes with "knit"...

>> Well, programming is a continuous problem in general.  If I understand
>> correctly, the thing you're trying to change is an implementation detail
>> of electric-pair-mode, not part of its contract, right?  If, on the
>> contrary, you think it is a bug, let me know.
> It is what I said at the end of my previous post.  e-p-m assumes that
> whitespace has "neutral" syntax.  When it doesn't (like here, with a
> string-fence property), the scan-sexps doesn't work as desired.  I'm
> convinced this could be changed.

OK. I'll have a look (I admit to not having looked at that code in depth
since I wrote it 5 years ago).  I was pretty much convinced it was
flawless :-)

>> Well, it's handling the rarities that makes Emacs stand out.
> Indeed!  Let's carry on doing this.
>>    int main () {
>>       printf("foo
>>              ); 
>>       printf("bar");
>>       return 0;
>>      }
>
> Maybe the compiler has the same bug as the old CC Mode.  ;-)

No, I passed it a silly example.  It does indeed look past the
unterminated string.

> But to see my point of view, type the following into a C Mode buffer in
> Emacs-26.1, the last two lines first, then type in the first line above
> them:
>
> char *foo = "foo;
> int bar = 5;
> char *baz = "baz";
>
> face.  We've been used to this for so long that we've lost sight of just
> how bad and amateurish it really is.
>
> Now do the same in master.  The fontification of the last two lines
> remains unaffected by typing in the first line, as it should.

Indeed, I admit this is better.  I very rarely get a buffer like this,
though.

João