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

[Adam Porter]

Hi Eli,

On 6/5/24 06:52, Eli Zaretskii wrote:
> > Date: Tue, 4 Jun 2024 20:33:13 -0500 From: Adam Porter 
> > <adam@alphapapa.net>
> >
> > Continuing with the theme of requesting the unobsoleting of some 
> > generalized variable forms (see [#65555] and [earlier discussion]),
> > and given Eli's recently [mentioning] the upcoming cut of the Emacs
> > 30 release branch, I'd like to request now that `buffer-substring'
> > be unmarked as obsolete.
>
> I think it's too late to do this now, not without a very good
> reason. Unless such a good reason emerges VSN, this will need to wait
> till Emacs 31 at least.

That would mean years more of unnecessary compilation warnings' annoying
users when they install packages that use this form.  Some of these
users misunderstand them as bugs and report them to package developers,
which wastes everyone's time.  It also clutters lint/build logs on CI,
sometimes making it impossible to have a clean linting pass (which
requires the developer to manually inspect every "failed" run to see if
it's just another of these warnings).

> > This form makes some operations much more concise than they would 
> > otherwise be.  For example, if one wants to update the text in a 
> > `magit-section' section, the code could be as simple as this:
> >
> > ┌──── │ (let ((inhibit-read-only t)) │   (setf (buffer-substring 
> > (oref (magit-current-section) start) │ (oref 
> > (magit-current-section) end)) │         "foobar\n")) └────
> >
> > Otherwise, one would have to use `delete-region' and then
> > `insert', which is more cumbersome and error-prone.
>
> I don't understand why it would be cumbersome, let alone
> error-prone. Less convenient than using setf, yes, but "cumbersome"?
> We've been doing that for decades.

The alternative means having to bind positions in variables, use
`goto-char' and `delete-region' and `insert' in a larger, more complex
form.  To me that seems much more cumbersome than this elegant GV form
which is a simple way of saying, "Replace that region with these contents."

> IOW, this is just a matter of convenience, nothing more.

*shrug*  Convenient code abstractions are easier to understand and
maintain; that's why I like to use this form, and why I like to use Lisp.

> > As I've mentioned in earlier discussions, the mass-marking of 
> > several GV forms as obsolete in commit 
> > 48aacbf292fbe8d4be7761f83bf87de93497df27 happened apparently 
> > without public discussion, as well as without checking the extent 
> > to which they are used outside of emacs.git.
>
> We don't discuss obsoletion, because it is never final.  The 
> rationale for obsoleting those forms is explained in the log message,
> so I think the implied accusation here is misplaced.

It was not meant as an accusation--just a statement of fact, an
observation; if I was incorrect, I'll be happy to be corrected.  My
point, of course, is that the marking--and creation of these new 
compilation warnings--happened without asking if anyone would be 
affected by it.

> > By the way, I'd also like to request that the `point' and 
> > `window-point' GV forms be unobsoleted, for the same reasons.  If 
> > it's permissible, I'd like to do so here rather than file separate
> >  bug reports for each of those, but if the maintainers prefer, I 
> > will do so.
>
> Let's see how many people want that now.

In fairness to them, most probably don't monitor emacs-bugs and are
unlikely to see this report, so I don't know if looking for replies here
would be an accurate indicator of interest.

> Use of those specific forms as GV was obsoleted in 48aacbf29 because 
> they are rarely if ever used as GV.  Unless this and the other two 
> requests suddenly get crowds of people demanding to un-obsolete them 
> (probably unlikely, since where were those people for the last 2 
> years?), I think Lars's decision to obsolete them is still solid.

I don't understand how an apparent lack of internal use is a good reason
to obsolete something useful.  There are parts of Emacs that seem to get 
 less use than these forms which are not marked obsolete.  As an Elisp
developer and tutor, I would like to see these forms used more
frequently, both inside and outside of emacs.git.  Emacs and Elisp are
so large that it takes years for knowledge about new or little-known
features to become widespread, and GVs in general are already a more 
advanced sub-topic.  I feel like obsoleting these forms is hardly giving 
them a chance, and doing so because they aren't yet widely used is like 
a catch-22.

--Adam