bug#29889: 27.0.50; Slow visual selection

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Sujith <m.sujith@gmail.com>,  29889@debbugs.gnu.org
> Date: Sat, 06 Jan 2018 10:37:27 -0500
> 
> > 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).

So do we change it back to 'only' for Emacs 26?  Sounds a bit risky to
me, after it has been t for 2 major releases, with no one complaining
until now.

> 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").

But do we have a way of "adjusting" a string like that?  Or did you
think of a primitive that avoids consing a new string (assuming the
text properties were already stripped from the 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).

That sounds cleaner to me.  Also much easier to implement.

But it can only be done on master, I think.