Re: Performance degradation from long lines

[Phil Sainty <psainty@orcon.net.nz>]

On 28/10/18 11:15 AM, Stefan Monnier wrote:
> When introducing such a blacklist of modes, it's always good to also add
> some way for a mode to voluntarily flag itself as "black", so the list
> has a chance to shrink over time.
> 
> E.g. we could add a symbol property `slow-on-long-lines` which
> font-lock-mode could set to announce that it assumes lines aren't
> terribly long.

I've not implemented this suggestion at this point -- I thought it
warranted further discussion, and I wanted to get the other changes
dealt with first.

It's not entirely clear to me how this should be managed.

One approach is that modes which identify themselves this way would
be disabled automatically, and users would have no control over it.
That would probably be easiest to implement, but I don't particularly
like the idea that users lose control and/or visibility over what's
being done.

However, any approach whereby users do have control would seem to
imply some significant complications to the code and user interface;
especially as modes flagged in this way are not necessarily loaded
at the time when the user is customizing the so-long options.

The very simplest thing I can think of is a single boolean user option
to say "deal with any flagged modes too" (the currently-loaded instances
could be displayed in the UI).

Potentially `custom-add-frequent-value' could be employed to present
flagged modes as checkbox options which then remain visible even if
the user disables them; but that only works for 'hook' and 'alist'
custom types, and `so-long-minor-modes' is just a list of symbols.

If the user does get to confirm each flagged mode and save that
configuration in their custom file, then there's the issue of modes
which were flagged at one time (and saved by the user), but were
subsequently improved such that the symbol property is no longer
needed.  In that situation it would be nice to differentiate between
"modes that the user saved on purpose" and "modes which the user
saved because they used to be flagged".  In general, it would be
nice if the user could distinguish the automated settings from the
ones which they personally selected, in a non-cumbersome manner.

I suppose the list of modes could become an alist, with an associated
classification for each mode (e.g. 'auto for modes which should be
dealt with based upon their symbol property).  That would be a breaking
change, as `so-long-minor-modes' has existed as a simple list since
early 2016, so some kind of migration or other backwards-compatibility
support would be needed.

I expect that all this would apply to `so-long-variable-overrides'
as well.

I'm not sure this is necessary for an initial release, mind, but it
does seem like a good thing to provide at some point.

How would other people approach it?


-Phil