bug#71370: 30.0.50; Please un-obsolete buffer-substring as a generalized variable

[Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andrea Corallo <acorallo@gnu.org> writes:

> [...]
> Interesting, I took the time to apply your methodology to all GV
> obsoleted by the same commit and this is the result:
>
> | GV                           | file occurrences |
> |                              |        in github |
> |------------------------------+------------------|
>   [... I picked the lines with 100+ matches ...]
> | buffer-string                |              142 |
> | buffer-substring             |              512 |
> | current-buffer               |              234 |
> [...]

> While some of them are rarely/not used some others looks quite popular.
> This is an indication that the popular ones are probably a good
> abstraction or they are just convenient.

More of the latter I would say.  Nonetheless that's one aspect that
counts.

But especially `buffer-substring' doesn't convince me as a gv because
semantics are very doubtful:

- You say (setf (buffer-substring START END) STRING).  The first thing
  that is not crystal clear is the question whether STRING will be
  added, or will replace, existing text.

- The END argument is either redundant, or, if text is replaced (which
  is what the current implementation does), it is unclear what happens
  if STRING has a length different from (- END START).  The current
  implementation doesn't even fulfill the most _basic_ assumption about
  places: if STRING has a different length, after
  (setf (buffer-substring START END) STRING),
  (buffer-substring START END) will _not_ be equal to STRING.  This is
  very bad, conceptually.

- For this reason resetting the place to the old "value" will not
  always restore the old situation.

- With `cl-letf' the generalized variable gets even more doubtful: if
  you edit the buffer contents inside the scope of the binding,
  reverting a `buffer-substring' gv binding will give surprising
  results, especially if START and END were specified as integers then
  pointing to unrelated positions.

These were exactly the kind of problems why those place expressions had
been obsoleted.  Adding a little helper function with clear semantics
really looks more appropriate in this case in my opinion, even if you
have to remember one more name.


Michael.