On Wed, Jul 10, 2019 at 11:32 AM Alan Mackenzie <
address@hidden> wrote:
Hello, João.
On Tue, Jul 09, 2019 at 19:53:17 +0100, João Távora wrote:
> On Tue, Jul 9, 2019 at 7:26 PM Alan Mackenzie <address@hidden> wrote:
> > Not really. The overwhelmingly most common use case is typing in a
> > short string which fits on one line, when the next line is (almost)
> > always a line of code. It is not sensible to fontify arbitrarily large
> > pieces of code as a string, just because the user hasn't yet reached her
> > closing double quote.
> You think that's the "overwhelmingly" most common use case. But if
> the user is using electric-pair-mode (the thing you just "fixed", the thing
> that the original author of the bug is using), it just doesn't happen.
Even if electric-pair-mode is enabled, the overwhelmingly most common
use case will still be a short string which fits on a single line, and
the next line will still (almost) always be a line of code.
You misunderstood me. What I said "just doens't happen" is "fontify arbitrarily
large pieces".
That's fine for users of electric-pair-mode, but that's a minority
sport. Many, likely most, users don't use that mode. For that
majority, CC Mode no longer fontifies arbitrarily large pieces of code
as a string.
Even if electric-pair-mode users are a minority users of autopairing
solutions such as smartparens are most definitely not. Every modern
editor has one of those. The very same applies to those users. But even
if those users are a minority (< 50%), it still doesn't justify breaking
long-held behavior that they expect.
> Now if you don't use electric-pair-mode or another paren-matching
> solution you will see the common blinking, precisely because the major
> mode doesn't know if the user is keeping a closing quote in his
> "mental stack".
With all due respect, I think this anthropomorphic view of major modes
supposedly "guessing" what the user wants is wide of the mark.
Precisely. I say it _doesn't_ know and _can't_ know. So any guess,
such as the one you're taking, that it's an invalid string, is wrong
some percentage of the time.
In C
Mode, a string starts at an opening ", and stops at the next " or
unescaped NL. That's how a compiler handles it. It's that simple.
The compiler doesn't edit code. It's irrelevant how it views the lines after
the error, so long as it hightlights the error in the correct line.
> All that Stefan is saying is that you are providing for this group of
> people, but that there is another group of people for which not only
> the functionality you are developing isn't useful, but also
> potentially harmful.
I fail to see this harm.
Stepping carefully on the terms, you have made two patches since
this "problem" happened:
1. One to restore the previous e-p-m behaviour in cc-mode
2. A long patch devised "just for me" to restore previous C-M-behaviour
The necessity of such patches, and the fact that patch 2 is likely buggy,
according to you, can be seen, in my opinion, as an _expression_ of "harm".
> We all agree that if an unterminated string occurs, be it accidentally
> by the deletion of a closing quote, or transiently (because the user
> hasn't downloaded his "mental closing quote"), the matter should
> be annotated on that line.
I don't agree. Or rather, that characterization is a gross distortion
of my take on the matter, which I stated last Thursday. This is the
passage which Stefan refuses to reply to, or even acknowledge I wrote:
>> The error is clear: There is an opening quote without a matching
>> closing quote. The former part of the error is at the opening quote,
>> so we must indicate its position somehow, most simply by marking it
>> with warning-face. The latter part of the error happens at the first
>> unescaped EOL; this is what defines the string as invalid. We must
>> indicate this position as well, and the best way of doing this is
>> terminating the string-face at that position.
>> It is not arbitrary. We are not trying to guess the intention of the
>> user; we are pointing out the objective error.
So the "gross distortion" is that you think it's absolutely necessary that
the error be annotated both at string start and invalid string end? Only one
of them is are totally wrong for you. Is that it, the thursday thing?
I proposed can highlight wherever you most desire. I don't know about
Stefan's solution, though.