[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: jit-lock-antiblink-grace
From: |
Alan Mackenzie |
Subject: |
Re: jit-lock-antiblink-grace |
Date: |
Sat, 12 Oct 2019 16:14:00 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, João.
On Sat, Oct 12, 2019 at 15:23:08 +0100, João Távora wrote:
> On Sat, Oct 12, 2019 at 2:33 PM Eli Zaretskii <address@hidden> wrote:
[ .... ]
> > It's a backward-incompatible behavior, and is not being developed due
> > to bug reports, so why make it the default right from the start? It
> > also slows down cursor motion (which should probably be in the doc
> > string as well).
> Regarding slowdown, we have to check by how much. Regarding the
> pertinence of the modificaiton, there are mode-specific modifications
> with (IMO much worse) backward-incompatible behaviour being made to
> modes like to c-mode to circumvent precisely this problem.
No. The feature in CC Mode I think you're referring to, namely the
correct fontification of unterminated strings is a static feature,
clearly indicating that the string hasn't (yet) been terminated, and
where its current end (as would be interpreted by a compiler) is. The
feature you've implemented is, if I understand correctly (I haven't tried
it, yet) a dynamic one, where fontification gets delayed a bit to give
the user a certain chance to terminate an unterminated string before
fontification kicks in.
I would guess that your new feature is less needed in a CC Mode mode than
in modes where the fontification of a string extends to the next string
quote, no matter how far away.
> Perhaps you could weigh in on the pertinence of those on-by-default
> (and moreover impossible-to-turn-off) alternatives, too. Although
> those other modifications target a reduced subset of modes, indeed
> precisely because of that fact, I think it's better that Emacs provides
> an effective and more generic solution to this problem.
I agree with that. My view is that such a feature should be provided in
syntax.c and the font locking system, such that a major mode can specify
that unterminated strings are to be regarded as terminated by an
unescaped new line.
I think I said this before, off hand, but it didn't go anywhere.
[ .... ]
> João
--
Alan Mackenzie (Nuremberg, Germany).
- Re: jit-lock-antiblink-grace, (continued)
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/10/12
- Re: jit-lock-antiblink-grace, João Távora, 2019/10/12
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/10/13
- Re: jit-lock-antiblink-grace, João Távora, 2019/10/13
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/10/13
- Re: jit-lock-antiblink-grace, João Távora, 2019/10/13
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/10/13
- Re: jit-lock-antiblink-grace, João Távora, 2019/10/14
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/10/15
- Re: jit-lock-antiblink-grace, João Távora, 2019/10/15
- Re: jit-lock-antiblink-grace,
Alan Mackenzie <=
- Re: jit-lock-antiblink-grace, João Távora, 2019/10/12
- Re: jit-lock-antiblink-grace, Alan Mackenzie, 2019/10/13
- Re: jit-lock-antiblink-grace, João Távora, 2019/10/13
Re: jit-lock-antiblink-grace, Alan Mackenzie, 2019/10/13