Criticism of jit-lock--antiblink-post-command

[Alan Mackenzie]

Hello, João.

I've been taking a closer look at the jit-lock antiblink functionality,
and some things seem to want comment.

Firstly, jit-lock-antiblink-grace is tested for being nil, yet is
declared in its customization scheme only as a number.  Should it not
alternatively be customizable to nil instead of a number?  This would
enable a user to disable it without having to read the source code and
use a setq.  The variable's doc string should surely also document this
possibility.

You have mentioned that this antiblink is redundant when using things
like electric-pair-mode, in which case the mode merely slows down the
processing.  The same is true of CC Mode, where there are no
unterminated strings.  These are good reasons for making antiblink easy
to disable.

In jit-lock--antiblink-post-command, you create lots of markers, one per
command.  You don't do anything to get rid of them, beyond waiting for
the next garbage collection to do its work.  This could easily lead to
several hundred markers slowing down operations in a buffer.  Maybe.
Page "Overview of Markers" in the Elisp manual recommends making them
point nowhere when you have finished with them, using (set-marker m
nil).  Please consider doing this.

-- 
Alan Mackenzie (Nuremberg, Germany).