On Tue, Jul 9, 2019 at 1:33 PM Clément Pit-Claudel <
address@hidden> wrote:
> * Fontifying to the end of the line and not past it minimizes refontification in that case
>
> Is that controversial?
I didn't say it was. I don't care about "(re)fontification minimization" because
I don't know what that amounts to" care about:
- consistency: this is not consistent with how the rest of Emacs works.
- distraction: this is just as "distracting", and I actually like the current "global
switch" more as it helps me spot the error easily;
- efficiency: this might well be less efficient (see below).
> > Both situations are wrong, and neither is "more wrong" than the other.
> I'm glad we agree. That's why I wrote 'That's not more "correct", of course'
You seemed to imply there was some kind of advantage. I don't see which,
or at least I don't see any advantage that outweighs the fact that this
breaks consistency to virtually all other emacs major modes. In breaking
that consistency other minor modes and commands are broken, such
as C-M-stuff and electric-pair-mode.
> > But the version you propose is much harder to implement, likely less
> > efficient,
> Strong words :) Are you saying refontifying the whole screen after the
> point is faster than just refontifying to the end of the line?
In your model, you are not refontifying "to the end of the line".
You may have meant to say "to the next closing double quote", which may
happen after the end of the screen. While that may be less text, I would
expect perfomance of (re)fontification to vary according to the thing being
fontified. A large string is probably easier to handle than parsing
lots of other types of tokens, which is what you would be doing to
the text that was formerly a string. And there's the added complexity
to implement this to start with.
> > Depending on how it is implemented (certainly how Alan
> > implemented it) it breaks things in Emacs core and third-party code.
>
> But surely the quality of Alan's implementation has little impact on the
> worthiness of the feature in general (I'm not arguing about how things
> should be in cc-mode today — just saying that I like the general idea)
Like I said, depends on how you value consistency to other parts of
emacs. For example, I particularly value the ease in which the
unequivocally wrong situation can be fixed. But even if you develop a
very complex implementation (presumably such as the one Alan is
developing now) which allows that, it is probably a net loss (in Emacs)
because navigation and fontification won't go hand-in-hand like before.
> > It is also
> > useless in languages which do allow unescaped multi-line strings
> And more strong words :) I'm saying it's an option I'd like to have while conceding
> it's not universally better, so it surely wouldn't be useless to me ^^
Perhaps I'm not following. What use would it be in a language that
does allow unescaped multi-line strings? Say, what use would it
be in elisp or ruby?
> Do we know what behavior is standard in other IDEs, and whether it is configurable?
> On my machine I have vim, geany, gedit, and vscode, and all of the behave like Emacs
> currently does (but they refontify immediately, without a jit-lock idle delay).
What are you doing with those other editors installed, you heretic?
Joke aside, do any of those editors have a paren-matching solution that also
does paren-balancing? I remember searching a bit and not finding anything
interesting.
Curiously, in cc-mode, the behavior is easily configurable (earlier I though
it didn't work but it does, it's just not officially "blessed" by the maintainer,
and unfortunately not the default).
(add-hook 'c++-mode-hook (lambda () (setq c-multiline-string-start-char t)))
João