bug#29889: 27.0.50; Slow visual selection

[Stefan Monnier]

> In fact, I cannot understand why the default was changed to t in
> 7c23dd4.  The discussions leading to those changes all mention the
> value 'lazy' (later renamed to 'only') as the default, and there's
> nothing I could find explaining why t was eventually deemed a better
> default.

FWIW I was also surprised to see its default is t rather than `only`
(and even more surprised that I hadn't noticed it all this time).

I think to make t work well (i.e. to avoid the obvious performance issue
discussed in the current bug-report), we'd need to rework the code so as
to try and avoid re-allocating a complete brand new string all the time.

E.g. special-case the common situation where nothing in the buffer has
been modified since last time and only extract some kind of "adjustment"
(i.e. something that says "remove last N chars" or "append this string").

Or maybe extract the region lazily: only remember the start and end
position of the region in the post-command-hook and postpone extracting
the region until either the primary selection is requested or the text
is about to be changed/destroyed (i.e. from before-change-function or
kill-buffer-hook).

> Regardless, I still wonder whether region-extract-function should call
> buffer-substring-no-properties, at least when it's used to set the
> primary selection.  Stefan, any thoughts?

We could try to do that to reduce the pain a bit, but
region-extract-function should generally preserve text properties (when
its output is used by Emacs rather than by another application), so we'd
need to add some way to specify whether we want the properties or not.
I think I'd rather "fix it right" than add such a hack.


        Stefan