Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Basil L. Contovounesios]

Lars Ingebrigtsen [2022-08-21 16:13 -0400] wrote:

> branch: master
> commit 48aacbf292fbe8d4be7761f83bf87de93497df27
> Author: Lars Ingebrigtsen <larsi@gnus.org>
> Commit: Lars Ingebrigtsen <larsi@gnus.org>
>
>     Make many seldom-used generalized variables obsolete
[...]
>  (gv-define-setter frame-height (x &optional frame)
>    `(set-frame-height (or ,frame (selected-frame)) ,x))
> +(make-obsolete-generalized-variable 'frame-height 'set-frame-height "29.1")
[...]
>  (gv-define-setter frame-width (x &optional frame)
>    `(set-frame-width (or ,frame (selected-frame)) ,x))

If frame-height is obsolete, frame-width should be as well, right?

Thanks,

-- 
Basil

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> If frame-height is obsolete, frame-width should be as well, right?

Yup.  Now done.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Ihor Radchenko]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> If frame-height is obsolete, frame-width should be as well, right?
>
> Yup.  Now done.

This commit also obsoleted a number of generalized variables used by
Org. In particular, `buffer-substring', and `buffer-string'.

While it is indeed possible to set buffer contents without the above
variables, it cannot (AFAIK) be done using a single function call.
Would it be possible to provide a function replacement for setting a
buffer text in the whole buffer/buffer region?

Also, obsoleting `buffer-file-name' revealed one potentially concerning
fact about generalized variables. The expansion of `buffer-file-name'
setter, `set-visited-file-name' "... also renames the buffer to
correspond to the new file." I am now wondering if there are any
non-obvious side effects when using other generalized variables - there
is (AFAIK) no documentation about what exactly various setters for
generalized variables do other than occasional paragraph in the manual.

-- 
Ihor Radchenko,
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

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Ihor Radchenko <yantar92@gmail.com> writes:

> This commit also obsoleted a number of generalized variables used by
> Org. In particular, `buffer-substring', and `buffer-string'.
>
> While it is indeed possible to set buffer contents without the above
> variables, it cannot (AFAIK) be done using a single function call.
> Would it be possible to provide a function replacement for setting a
> buffer text in the whole buffer/buffer region?

"Setting a buffer text" is something that is un-Emacsey, in my opinion.
That is, (setf (buffer-substring ...) ...) is pretending that we're
operating on some object, but instead we're altering global (buffer)
state.

Just delete and insert instead

> Also, obsoleting `buffer-file-name' revealed one potentially concerning
> fact about generalized variables. The expansion of `buffer-file-name'
> setter, `set-visited-file-name' "... also renames the buffer to
> correspond to the new file." I am now wondering if there are any
> non-obvious side effects when using other generalized variables - there
> is (AFAIK) no documentation about what exactly various setters for
> generalized variables do other than occasional paragraph in the manual.

All these obsoleted generalised variables had non-obvious side effects,
which is why I obsoleted them.

I don't think anybody could guess what (setf (point-min) 2) actually
does without reading the expanded code.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Ihor Radchenko]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Setting a buffer text" is something that is un-Emacsey, in my opinion.
> That is, (setf (buffer-substring ...) ...) is pretending that we're
> operating on some object, but instead we're altering global (buffer)
> state.
>
> Just delete and insert instead

Well. What about `replace-buffer-contents'?

(For context, this is a very minor issue, and I am not pushing hard for
it. Just a minor annoyance.)

>> Also, obsoleting `buffer-file-name' revealed one potentially concerning
>> fact about generalized variables. The expansion of `buffer-file-name'
>> setter, `set-visited-file-name' "... also renames the buffer to
>> correspond to the new file." I am now wondering if there are any
>> non-obvious side effects when using other generalized variables - there
>> is (AFAIK) no documentation about what exactly various setters for
>> generalized variables do other than occasional paragraph in the manual.
>
> All these obsoleted generalised variables had non-obvious side effects,
> which is why I obsoleted them.
>
> I don't think anybody could guess what (setf (point-min) 2) actually
> does without reading the expanded code.

Sure, but not all the generalized variables were obsoleted. Do you claim
that all the remaining generalized variables are simple enough to not
require documentation? I am pretty sure that third-party setters may
still do non-obvious things.

Would it be possible to accept docstring in gv-define-setter and then
display it in the help buffer for the relevant variable?

-- 
Ihor Radchenko,
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

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Ihor Radchenko <yantar92@gmail.com> writes:

> Well. What about `replace-buffer-contents'?

It's a very specialised function used for reverting.  (Also see
`replace-region-contents'.)

> Sure, but not all the generalized variables were obsoleted. Do you claim
> that all the remaining generalized variables are simple enough to not
> require documentation?

I went through them all and obsoleted all the weird ones, so yes.  But I
may have missed some, of course.

> I am pretty sure that third-party setters may still do non-obvious
> things.

I don't really control code that's not in Emacs, unfortunately.  😀

> Would it be possible to accept docstring in gv-define-setter and then
> display it in the help buffer for the relevant variable?

It would be possible, but then we'd just be encouraging people to write
illegible code.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Stefan Monnier]

>> Would it be possible to accept docstring in gv-define-setter and then
>> display it in the help buffer for the relevant variable?
> It would be possible, but then we'd just be encouraging people to write
> illegible code.

Largely agreed.  There is some occasional need for documentation of the
setter, for example we could argue that `alist-get` (when used as a gv)
should document that the ALIST argument needs to be a gv-place as
well.  But when needed it can be added to the function's docstring.
So, I'm leaning towards YAGNI.


        Stefan

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Ihor Radchenko]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Would it be possible to accept docstring in gv-define-setter and then
>>> display it in the help buffer for the relevant variable?
>> It would be possible, but then we'd just be encouraging people to write
>> illegible code.
>
> Largely agreed.  There is some occasional need for documentation of the
> setter, for example we could argue that `alist-get` (when used as a gv)
> should document that the ALIST argument needs to be a gv-place as
> well.  But when needed it can be added to the function's docstring.
> So, I'm leaning towards YAGNI.

I do not have anything against this paradigm.
However, it would be useful then to document this convention in
"12.17.2 Defining new ‘setf’ forms" section of the Elisp manual.

-- 
Ihor Radchenko,
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

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Stefan Monnier]

Lars Ingebrigtsen [2022-09-10 08:45:45] wrote:
> Ihor Radchenko <yantar92@gmail.com> writes:
>> This commit also obsoleted a number of generalized variables used by
>> Org. In particular, `buffer-substring', and `buffer-string'.
>>
>> While it is indeed possible to set buffer contents without the above
>> variables, it cannot (AFAIK) be done using a single function call.
>> Would it be possible to provide a function replacement for setting a
>> buffer text in the whole buffer/buffer region?
>
> "Setting a buffer text" is something that is un-Emacsey, in my opinion.
> That is, (setf (buffer-substring ...) ...) is pretending that we're
> operating on some object, but instead we're altering global (buffer)
> state.

Ihor doesn't specifically ask to keep the generalized variable, but to
offer some straightforward replacement.

> Just delete and insert instead

That's indeed what `cl--set-buffer-substring` (the workhorse of the
current gv-expander) does, but it's not ideal: it should insert first
and then delete, so as to better preserve markers.

For this reason, I do think we should provide a function to do that.

>> Also, obsoleting `buffer-file-name' revealed one potentially concerning
>> fact about generalized variables. The expansion of `buffer-file-name'
>> setter, `set-visited-file-name' "... also renames the buffer to
>> correspond to the new file." I am now wondering if there are any
>> non-obvious side effects when using other generalized variables - there
>> is (AFAIK) no documentation about what exactly various setters for
>> generalized variables do other than occasional paragraph in the manual.
>
> All these obsoleted generalised variables had non-obvious side effects,
> which is why I obsoleted them.

+1


        Stefan

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Sean Whitton]

Hello,

On Sun 21 Aug 2022 at 04:13PM -04, Lars Ingebrigtsen wrote:

> branch: master
> commit 48aacbf292fbe8d4be7761f83bf87de93497df27
> Author: Lars Ingebrigtsen <larsi@gnus.org>
> Commit: Lars Ingebrigtsen <larsi@gnus.org>
>
>     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.

I found this in some code of mine, now generating warnings:

    (if (> (point) (mark))
        (progn (cl-incf (point)) (cl-decf (mark)))
      (cl-incf (mark)) (cl-decf (point)))

I guess the replacements would be forward-char and set-mark?  Is there
anything simpler?

-- 
Sean Whitton

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> I guess the replacements would be forward-char and set-mark?  Is there
> anything simpler?

I don't think so.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Jonas Bernoulli]

I am a bit surprised Stefan Monnier is fine with these deprecation.
If I remember correctly it was him who added the generalized variables,
and back when he did it, I got the impression that there was more to come.

I never used many of these, so I am generally fine with this change,
just somewhat surprised.  Unintuitive side-effects sounds like a good
reason to deprecate them, on the other hand I don't necessarily agree
that, e.g., (setf (point) n) is not intuitive, once you have wrapped
your head around setf.  But seeing that in the wild never-the-less
felt a bit weird.

> I found this in some code of mine, now generating warnings:
>
>     (if (> (point) (mark))
>         (progn (cl-incf (point)) (cl-decf (mark)))
>       (cl-incf (mark)) (cl-decf (point)))
>
> I guess the replacements would be forward-char and set-mark?  Is there
> anything simpler?

As I understood it the idea behind generalized variables wasn't to use
them mainly with setf, when a perfectly fine, explicit setter function
exists; but to use them in situations like this, with other functions
that understand generalized variables.  Made sense to me when the
feature was introduced.

I guess I am just wondering whether generalized variables are generally
seen as a failed experiment, and if so why exactly.  Or if not, I would
be interested in some guidance on when it is considered good practice to
use them and when not.

(Maybe we are going a bit overboard with the deprecations? Maybe we
should instead focus on documenting potentially surprising effects.
If we can think of reasonable use-cases (such as, IMO, the above) then
maybe we should not deprecate.  But again, I don't actually care that
much, just expressing my surprise and resulting uncertainties.

There is one generalized variable that I would like to see undeprecated
though:

   (setf (buffer-local-value 'var buffer) val)

That made a lot of sense to me.  I don't look forward to having to
wrap some (setq-local var val) with with-current-buffer again.  And it
appears I am not the only one you used buffer-local-value like this; 5%
of the out-tree packages that I have installed use it, and they are not
all authored by me.

     Jonas

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@bernoul.li> writes:

> There is one generalized variable that I would like to see undeprecated
> though:
>
>    (setf (buffer-local-value 'var buffer) val)

See bug#26624.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Jonas Bernoulli]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> There is one generalized variable that I would like to see undeprecated
>> though:
>>
>>    (setf (buffer-local-value 'var buffer) val)
>
> See bug#26624.

In short, it doesn't work as expected with cl-letf and fixing that
would not be worth the effort, if it's possible at all.

I can live with that, but have you considered adding a plain old
set-buffer-local-value function? buffer-local-value isn't any more
*necessary* than that; they both just relieve us from the need to
use with-current-buffer explicitly.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Augusto Stoffel]

On Mon, 19 Sep 2022 at 12:01, Jonas Bernoulli wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>
>>> There is one generalized variable that I would like to see undeprecated
>>> though:
>>>
>>>    (setf (buffer-local-value 'var buffer) val)
>>
>> See bug#26624.
>
> In short, it doesn't work as expected with cl-letf and fixing that
> would not be worth the effort, if it's possible at all.
>
> I can live with that, but have you considered adding a plain old
> set-buffer-local-value function? buffer-local-value isn't any more
> *necessary* than that; they both just relieve us from the need to
> use with-current-buffer explicitly.

Is it possible at all to set a variable buffer-locally but outside any
let-bindings?  If not, it would be one more reason to add such a
function.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Augusto Stoffel <arstoffel@gmail.com> writes:

> Is it possible at all to set a variable buffer-locally but outside any
> let-bindings?

That's what `setq-local' does (but you have to switch to the buffer
first).

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Augusto Stoffel]

On Mon, 19 Sep 2022 at 14:22, Lars Ingebrigtsen wrote:

> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> Is it possible at all to set a variable buffer-locally but outside any
>> let-bindings?
>
> That's what `setq-local' does (but you have to switch to the buffer
> first).

set-local just relies on set, so if the variable is let-bound, then the
"toplevel" local value is unchanged:

   (progn (setq-local x 1)
          (let (x) (setq-local x 2))
          x)
   ==> 1

I've had some trouble with this when a major mode (and therefore its
mode hook) is called from a place with let-bound variables.  But then
one could argue that working around it is even more problematic...

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Augusto Stoffel <arstoffel@gmail.com> writes:

> set-local just relies on set, so if the variable is let-bound, then the
> "toplevel" local value is unchanged:
>
>    (progn (setq-local x 1)
>           (let (x) (setq-local x 2))
>           x)
>    ==> 1
>
> I've had some trouble with this when a major mode (and therefore its
> mode hook) is called from a place with let-bound variables.  But then
> one could argue that working around it is even more problematic...

But that's with the dynamic binding dialect -- with lexical binding, the
setq-local ignores that binding.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Augusto Stoffel]

On Mon, 19 Sep 2022 at 14:37, Lars Ingebrigtsen wrote:

> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> set-local just relies on set, so if the variable is let-bound, then the
>> "toplevel" local value is unchanged:
>>
>>    (progn (setq-local x 1)
>>           (let (x) (setq-local x 2))
>>           x)
>>    ==> 1
>>
>> I've had some trouble with this when a major mode (and therefore its
>> mode hook) is called from a place with let-bound variables.  But then
>> one could argue that working around it is even more problematic...
>
> But that's with the dynamic binding dialect -- with lexical binding, the
> setq-local ignores that binding.

True.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@bernoul.li> writes:

> I can live with that, but have you considered adding a plain old
> set-buffer-local-value function? buffer-local-value isn't any more
> *necessary* than that; they both just relieve us from the need to
> use with-current-buffer explicitly.

In my experience, it's pretty unusual to change the value of a
buffer-local value (in a different buffer), so I'm not sure it's worth
it.  But if there's great demand for it -- sure.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Stefan Monnier]

Lars Ingebrigtsen [2022-09-19 08:00:19] wrote:
> Jonas Bernoulli <jonas@bernoul.li> writes:
>> There is one generalized variable that I would like to see undeprecated
>> though:
>>
>>    (setf (buffer-local-value 'var buffer) val)
>
> See bug#26624.

FWIW, `alist-get` suffers from the same kind of problem.
If we want `cl-letf` to work well with "fancy" gv-places, we need to
make the gv-expanders aware of the `let` case so they can provide
special code for it.

Not sure it's worth the trouble.

Of course, the case of `alist-get` is somewhat different since it's
already useful with `setf`.


        Stefan

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Po Lu]

Apologies in advance for not following this discussion closely, if this
ends up not very relevant.

Before anyone thinks to obsolete the alist-get gv, please keep in mind
that it has been the only way to "put" in an alist for a long time, so
the consequences of such an obsoletion will be very bad.

Thanks.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Before anyone thinks to obsolete the alist-get gv, please keep in mind
> that it has been the only way to "put" in an alist for a long time, so
> the consequences of such an obsoletion will be very bad.

I don't think anybody has suggested obsoleting that generalised
variable.

Re: master 48aacbf292 2/2: Make many seldom-used generalized variables obsolete

[Stefan Monnier]

Jonas Bernoulli [2022-09-19 01:10:23] wrote:
> I am a bit surprised Stefan Monnier is fine with these deprecation.
> If I remember correctly it was him who added the generalized variables,
> and back when he did it, I got the impression that there was more to come.

AFAICT those that are being deprecated don't come from me, other than
the fact that I was the one who translated their previous definitions
from the `cl.el` syntax to the `gv.el` syntax.


        Stefan