On Sat, Oct 12, 2019 at 2:33 PM Eli Zaretskii <
address@hidden> wrote:
> The post-command-hook is notorious for slowing down cursor motion.
Probably a fame unjustly inherited from functions that people put there.
> > Can you tell me more about the kinds of files you're anxious about
> > and exact meaning of "paging"? Is it C-n'ing from the first line to
> > the last? I could benchmark.
>
> C-n and C-v. Try C mode for starters, and then Emacs Lisp.
OK, will do.
> > > If there's no better solution than using that over-used hook,
> >
> > My very first version relied on an extension of the existing
> > jit-lock-context-time, but I seem to remember it broke down here and
> > there sometimes. I agreed with Stefan (possibly off-list) to use a
> > post-command-hook, which is safer. But I can have a look at the
> > original version and re-study those problems more closely.
>
> We also have display-related hooks. If you could use one of them,
> that might be better, because one could generally type quite a few
> commands before redisplay kicks in, and post-command-hook runs once
> for every command.
OK, will try that.
> > > then at the very least we should give users a way of NOT adding a
> > > post-command-hook when this feature is disabled.
> >
> > Given that I intend for this to be controlled via a customization
> > variable, I only see it done via a `:set` hook or something like that.
>
> I'm not sure I understand. What I wanted to suggest is that when the
> new defcustom is nil (which seems to be the way to disable this
> feature), the post-command-hook should not be added.
If we do it like that, it will take effect only when jit-lock-mode is
toggled. Therefore, if you set the variable to nil in a buffer you will
only see the desired effects in post-command-hook after additionally
toggling jit-lock-mode on and off again.
> In addition, I think major modes which present read-only buffers
> should also disable this feature, and not add to post-command-hook.
OK.
> > > > +Setting this to a positive number of seconds helps avoid the
> > > > +fontification "blinking" behaviour observed when adding temporarily
> > > > +unterminated strings to source code. If the user has recently created
> > > > +an unterminated string at EOL, jit fontification allows this idle
> > > > +"grace" period to elapse before deciding it is a multi-line string and
> > > > +fontifying the remainder of the buffer accordingly.
> > >
> > > This should be simplified and shortened. (In general, copy/paste of
> > > doc strings into NEWS is not a good idea.) In particular, if the
> > > default is to have this behavior (see below), the NEWS entry should
> > > tell how to disable that.
> >
> > OK. Supposing you've already already gotten the idea, I invite you to
> > submit a suggestion.
>
> I'd rather had you try. I think it's important that more people can
> write good documentation, and I think in this case it isn't hard. You
> can use other entries as examples.
Naturally Eli, I hope you believe me that I try hard, indeed very hard,
to write good documentation. I spend I good deal of time in it,
sometimes much more than writing the code itself. If I sometimes fail
to meet your standards, it's to be expected, (1) because they are high
(which is very good) and (2) because we all have unwritten guidelines of
what we believe is good style. I tried many versions (many more than
you can probably get evidence of in the emacs-diffs ML) and settled on
the one I presented.
With requesting a suggestion from you, I am not taking an adversarial
position, simply a way forward on what I (and many) consider to be a
difficult and underestimated problem in programming. Also, English is
not my first language, and Emacs-english has certain rules that you will
much more familiar with.
> > > (I question the wisdom of making this the default behavior, btw.)
> >
> > What's bothering you?
>
> 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. 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 don't understand the "at EOL" part: isn't any unterminated string
> > > appear as if it is "at EOL"?
> >
> > An unterminated string at EOL might be terminated somewhere _after_ EOL,
> > i.e. a perfectly legitimate (as "in your intentions") multiline string.
>
> I still don't think I understand what would constitute an
> "unterminated string at EOL", then. Could you show two examples, one
> where there is such a string, the other where there isn't?
Buffer 1:
l1: foofoo "bar < unterminated string at EOL, terminated multiline string
l2: barbar" foofoo
Buffer 2:
l1: foofoo "bar < unterminated string at EOL, unterminated string
l2: barbar
It's an informal way of referring to both situations at line 1. If I
said "unterminated string" the user might be led to believe it doesn't
apply to the situation of buffer 1.
But the fact that it confused you so much is probably a hint it's not a
great idea. Again, let me humbly request a suggestion for rephrasing :-)
> > Moreover this is a hint as to how the system is implemented, which some
> > users may appreciate.
> This kind of stuff should be in comments, not ion doc strings, IMO.
Maybe. Sometimes such hints are good because they help consolidate the
user's prediction of timer-based behaviour.
> > > Please don't use such cryptic variable names, at least not on the file
> > > level (preferably also not locally inside functions).
> >
> > The docstring explains the abbreviation. I'm afraid that given current
> > naming practice (prefix, double dash, sub-feature) I couldn't do much
> > better. I think jit-lock--antiblink-l-b-p is a better name than
> > jit-lock--antiblink-pos, or jit-lock--pos, because it makes the reader
> > "chase" the doc and learn of the exact meaning of the abbreviation.
>
> The variables don't need to use jit-lock--antiblink- prefix, they
> could use jit-lock-- prefix instead. jit-lock--last-line-begpos
> doesn't sound too long to me, for example.
It doesn't, but then I lose the ability to i-search for
jit-lock--antiblink and see its related variables. It's all trade-offs.
But I'll put in the longer names or use a plist, don't worry.
> > > > + (when jit-lock--antiblink-grace-timer
> > > > + (message "internal warning: `jit-lock--antiblink-grace-timer' not null"))
> > >
> > > We should in general avoid calling 'message' here, because such a
> > > message will appear after every command, which is a nuisance. Is this
> > > really needed?
> >
> > This is an internal consistency check, i.e. a run-time assertion. It
> > should never happen, except when the program is buggy. I had this set
> > to 'warn', but Stefan suggested I change it. What do you suggest?
> > Perhaps I could warn and turn off the feature.
>
> Why not just lose the message?
Huh? If I lose the message the form becomes a noop.
> Why is it important to display it?
Run-time consistency assertions are useful, right? I can change
'message' to whatever you think has the optimimum noise-level for such
an assertion ('warn' with a :debug level, maybe?) I can also remove the
form completely and we just pray that noone every breaks the mechanism
in subtle ways :-)
João