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

[Ihor Radchenko <yantar92@posteo.net>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> 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:
> ...

> These were exactly the kind of problems why those place expressions had
> been obsoleted.

Do note that the original reason of obsoletion was different:

   48aacbf292fbe8d4be7761f83bf87de93497df27
    Make many seldom-used generalized variables obsolete
    
    The vast majority of these are unused in-tree, and many of them
    perform actions that aren't obvious when reading the code.

No arguments have been listed about "actions that aren't obvious" wrt
`buffer-substring' generalized variable. And, as we see, "unused" is
only true for Emacs sources, but not for third-party libs.

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

FYI, I never had this kind of confusion. It is perfectly expected for
_buffers_ that any kind of modification may render point positions
inaccurate. If one needs to track specific region even when
modifications are performed, this is what markers are for. And markers
do work when used as arguments for buffer-substring.

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

Maybe. But I would argue that `buffer-substring' is already _the most
popular_ among obsoleted generized variables. Clearly, people do find it
useful; and, clearly, obsoleting it forces many library authors to do
extra work that is not justified.

I would be ok with adding a helper _in addition_ to generalized
variable, but I do not see it justified to make it replace it (at least,
not until we see that the added new helper is vastly more popular)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>