Comments on setopt

Comments on setopt

[Philip Kaludercic]

Hi Lars,

I'm glad to see the recent addition of the setopt macro.  Having have
experimented with similar macros in the past, I wanted to raise these
points:

- Unless it makes more sense for `customize-set-variable' to take care
  of it, should there be some type checking with errors or warnings if
  the value doesn't match the type of a user option?

- As `customize-set-variable' is being used directly, the "user" theme
  is modified, and a customisation might be mirrored in
  `custom-set-variables'.  This can lead to the unfortunate situation
  where your setopt configuration is overriden by the
  `custom-set-variables', depending on when and how you load `custom-file'
  and when and how the `custom-set-variables' was generated.

- While I don't mind it really, I can imagine that others might object
  to the "long" name, when compared to setq.  Would a default alias like
  "seto" or "setc" be worth it or not?

-- 
	Philip Kaludercic

Re: Comments on setopt

[Po Lu]

Philip Kaludercic <philipk@posteo.net> writes:

> Hi Lars,
>
> I'm glad to see the recent addition of the setopt macro.  

Indeed, it's a great addition.

> - While I don't mind it really, I can imagine that others might object
>   to the "long" name, when compared to setq.  Would a default alias like
>   "seto" or "setc" be worth it or not?

I think setopt is enough.  "seto" might be confused with oset, while I
don't immediately see what "setc" is supposed to represent.

What I find problematic is the large scale replacement of
`custom-set-variables' with setopt in the user manual.  I think there
was once a specific reason to use `custom-set-variables' there, but I
can't remember what.

Re: Comments on setopt

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > - While I don't mind it really, I can imagine that others might object
  > >   to the "long" name, when compared to setq.  Would a default alias like
  > >   "seto" or "setc" be worth it or not?

  > I think setopt is enough.  "seto" might be confused with oset, while I
  > don't immediately see what "setc" is supposed to represent.

Setting a command line option is not especially common.
I don't think it calls for a name of only 6 characters -- if I were
choosing one afresh, I think I would choose `set-command-option'.

The only reason to use `setopt' is to for parallelism with `getopt'.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Comments on setopt

[Rudolf Adamkovič]

Richard Stallman <rms@gnu.org> writes:

> Setting a command line option is not especially common.
>
> […]
>
> The only reason to use `setopt' is to for parallelism with `getopt'.

A command line option?

> I don't think it calls for a name of only 6 characters -- if I were
> choosing one afresh, I think I would choose `set-command-option'.

I agree on unnecessary brevity.

Why not call it `set-user-option', given its description?

"This is like ‘setq’, but is meant for user options […]"

Rudy
-- 
"It is no paradox to say that in our most theoretical moods we may be
nearest to our most practical applications."
-- Alfred North Whitehead, 1861-1947

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Comments on setopt

[Phil Sainty]

On 2022-02-16 20:04, Rudolf Adamkovič wrote:
> I agree on unnecessary brevity.
> Why not call it `set-user-option', given its description?

Even better, let's call it `customize-set-variable'? (/joke)

I managed to fail to CC the list address in an earlier response, but
for the record I've always thought that `setc' would be a good name
for such a thing, and IMO giving it a name that is at least nearly as
succinct as `setq' is not merely a good idea, but the primary benefit
over using `customize-set-variable' directly (indeed, I believe the
verbosity of the name `customize-set-variable' is a significant reason
why many people prefer to use `setq' for everything, even when they
know that user options can have setters).

To me, `setc' would be "like `setq' but for custom/user options",
and it's not going to be any more confusing than `setq' either.

If the name has to be longer then I think `setopt' is a good choice,
but I think that anything more verbose than this is missing the point
(either that, or I am).


-Phil

Re: Comments on setopt

[Stefan Monnier]

> over using `customize-set-variable' directly (indeed, I believe the
> verbosity of the name `customize-set-variable' is a significant reason
> why many people prefer to use `setq' for everything, even when they
> know that user options can have setters).

Hmm... I'm not sure I understand the motivation behind the introduction
of `setopt`, to be honest.  As pointed out, `setopt` should probably not
be used at top-level in a `.emacs` because Custom will think this was
set via `customize-set-variables` and will save that setting back into
`custom-file` next time we ask to save the customized variables.

As a general rule, it should also be avoided by packages because
packages shouldn't change user options behind the user's back.

So the remaining places where it makes sense to use it are fairly
rare, AFAICT.

Am I missing something?


        Stefan

Re: Comments on setopt

[Phil Sainty]

On 2022-02-17 02:23, Stefan Monnier wrote:
> As pointed out, `setopt` should probably not be used at top-level
> in a `.emacs` because Custom will think this was set via
> `customize-set-variables` and will save that setting back into
> `custom-file` next time we ask to save the customized variables.

 From the description I thought this would invoke any setter function
but otherwise act like setq in that it would *not* touch the user's
custom file.

That would be the desirable behaviour, no?


-Phil

Re: Comments on setopt

[Stefan Monnier]

Phil Sainty [2022-02-17 11:34:00] wrote:
> On 2022-02-17 02:23, Stefan Monnier wrote:
>> As pointed out, `setopt` should probably not be used at top-level
>> in a `.emacs` because Custom will think this was set via
>> `customize-set-variables` and will save that setting back into
>> `custom-file` next time we ask to save the customized variables.
> From the description I thought this would invoke any setter function
> but otherwise act like setq in that it would *not* touch the user's
> custom file.
> That would be the desirable behaviour, no?

Agreed.  Then maybe I misunderstood?


        Stefan

Re: Comments on setopt

[Philip Kaludercic]

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

>> over using `customize-set-variable' directly (indeed, I believe the
>> verbosity of the name `customize-set-variable' is a significant reason
>> why many people prefer to use `setq' for everything, even when they
>> know that user options can have setters).
>
> Hmm... I'm not sure I understand the motivation behind the introduction
> of `setopt`, to be honest.  As pointed out, `setopt` should probably not
> be used at top-level in a `.emacs` because Custom will think this was
> set via `customize-set-variables` and will save that setting back into
> `custom-file` next time we ask to save the customized variables.

The issue lies in `customize-set-variable' modifying the user theme.
Without that (or if one can indicate that a customisation shouldn't be
added and stored again in the user theme).

> As a general rule, it should also be avoided by packages because
> packages shouldn't change user options behind the user's back.
>
> So the remaining places where it makes sense to use it are fairly
> rare, AFAICT.

I honestly don't see any at all, if the issue with
`customize-set-variables' is considered to be critical.

> Am I missing something?
>
>
>         Stefan
>

-- 
	Philip Kaludercic

Re: Comments on setopt

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Setting a command line option is not especially common.
> I don't think it calls for a name of only 6 characters -- if I were
> choosing one afresh, I think I would choose `set-command-option'.
>
> The only reason to use `setopt' is to for parallelism with `getopt'.

This macro sets a customizable variable in Emacs, it's not related to
`getopt'.  Here is its definition:

  (defmacro setopt (&rest pairs)
    "Set VARIABLE/VALUE pairs, and return the final VALUE.
  This is like `setq', but is meant for user options instead of
  plain variables.  This means that `setopt' will execute any
  Customize form associated with VARIABLE.

  If VARIABLE has a `custom-set' property, that is used for setting
  VARIABLE, otherwise `set-default' is used.

  \(fn [VARIABLE VALUE]...)"
    (declare (debug setq))
    (unless (zerop (mod (length pairs) 2))
      (error "PAIRS must have an even number of variable/value members"))
    (let ((expr nil))
      (while pairs
        (unless (symbolp (car pairs))
          (error "Attempting to set a non-symbol: %s" (car pairs)))
        (push `(customize-set-variable ',(car pairs) ,(cadr pairs))
              expr)
        (setq pairs (cddr pairs)))
      (macroexp-progn (nreverse expr))))

Thanks.

Re: Comments on setopt

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This macro sets a customizable variable in Emacs, it's not related to
  > `getopt'.  Here is its definition:

Since it isn't meant for the command line options that `getopt' examines,
the name `setopt' is misleading.  (It already misled me!)
This name should be changed to something longer and clearer.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Comments on setopt

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

>   > This macro sets a customizable variable in Emacs, it's not related to
>   > `getopt'.  Here is its definition:

> Since it isn't meant for the command line options that `getopt' examines,
> the name `setopt' is misleading.  (It already misled me!)
> This name should be changed to something longer and clearer.

How about `set-custom-variable'?

Re: Comments on setopt

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: philipk@posteo.net,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sat, 19 Feb 2022 13:07:44 +0800
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >   > This macro sets a customizable variable in Emacs, it's not related to
> >   > `getopt'.  Here is its definition:
> 
> > Since it isn't meant for the command line options that `getopt' examines,
> > the name `setopt' is misleading.  (It already misled me!)
> > This name should be changed to something longer and clearer.
> 
> How about `set-custom-variable'?

set-user-option is better, IMO.

Re: Comments on setopt

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Since it isn't meant for the command line options that `getopt' examines,
> the name `setopt' is misleading.  (It already misled me!)
> This name should be changed to something longer and clearer.

You mean you thought this had something to do with getopt.h?  I don't
thing confusing `setopt' with that has potential to confuse many people
writing Lisp code -- most people haven't heard of getopt.h, there is no
`getopt' function in Emacs Lisp, and what would setting a command line
switch even mean?

The point is that we need a variant of `setq' for user options that
people can use when saying `M-:' and in init files, so it needs to be
short and snappy.  `seto' and `setc' were proposed, but I thought those
were too confusing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Comments on setopt

[Mathias Dahl]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

setuopt?

On Sat, Feb 19, 2022 at 12:17 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> > Since it isn't meant for the command line options that `getopt' examines,
> > the name `setopt' is misleading.  (It already misled me!)
> > This name should be changed to something longer and clearer.
>
> You mean you thought this had something to do with getopt.h?  I don't
> thing confusing `setopt' with that has potential to confuse many people
> writing Lisp code -- most people haven't heard of getopt.h, there is no
> `getopt' function in Emacs Lisp, and what would setting a command line
> switch even mean?
>
> The point is that we need a variant of `setq' for user options that
> people can use when saying `M-:' and in init files, so it needs to be
> short and snappy.  `seto' and `setc' were proposed, but I thought those
> were too confusing.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

[-- Attachment #2: Type: text/html, Size: 1532 bytes --]

Re: Comments on setopt

[Dmitry Gutov]

On 19.02.2022 13:52, Mathias Dahl wrote:
> setuopt?

setcustom?

Name for `setopt` (was: Comments on setopt)

[Stefan Monnier]

We've clearly entered bikeshed territory, so I'll just +1 here to what
Lars said.


        Stefan


Lars Ingebrigtsen [2022-02-19 12:13:23] wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>> Since it isn't meant for the command line options that `getopt' examines,
>> the name `setopt' is misleading.  (It already misled me!)
>> This name should be changed to something longer and clearer.
>
> You mean you thought this had something to do with getopt.h?  I don't
> thing confusing `setopt' with that has potential to confuse many people
> writing Lisp code -- most people haven't heard of getopt.h, there is no
> `getopt' function in Emacs Lisp, and what would setting a command line
> switch even mean?
>
> The point is that we need a variant of `setq' for user options that
> people can use when saying `M-:' and in init files, so it needs to be
> short and snappy.  `seto' and `setc' were proposed, but I thought those
> were too confusing.

Re: Comments on setopt

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Since it isn't meant for the command line options that `getopt' examines,
>> the name `setopt' is misleading.  (It already misled me!)
>> This name should be changed to something longer and clearer.
>
> You mean you thought this had something to do with getopt.h?  I don't
> thing confusing `setopt' with that has potential to confuse many people
> writing Lisp code -- most people haven't heard of getopt.h, there is no
> `getopt' function in Emacs Lisp, and what would setting a command line
> switch even mean?
>
> The point is that we need a variant of `setq' for user options that
> people can use when saying `M-:' and in init files, so it needs to be
> short and snappy.  `seto' and `setc' were proposed, but I thought those
> were too confusing.

While I do see that there is potential for confusion between seto and
oset, I'd like to argue once more for setc.  It is no less confusing
from a non-lisp-hacker perspective than setq (that also only makes sense
when you understand set).

-- 
	Philip Kaludercic

RE: [External] : Re: Comments on setopt

[Drew Adams]

> The point is that we need a variant of `setq'
> for user options that people can use when
> saying `M-:' and in init files

We do?  Since when?  And why?

If we "need" that then why wasn't it proposed
and discussed somewhere?  (Was it?)

I've perused this thread but haven't seen any
proposal for `setopt' here either, or any
explanation for why it should be (was?) added.
I may have just not noticed it...(?).

I searched for "setopt" at the emacs-devel
archives, and that search found only this post
from 2007:

https://lists.gnu.org/archive/html/emacs-devel/2007-04/msg01534.html

Clearly I don't know how to use the Search box.
___

Is this just about an alias for
`customize-set-variable'?  Apparently not, and
the difference is apparently (?) that this
won't change the user theme.  That, and this
apparently won't be a command, so you can't
use `M-x' with it (?).

Whoever (Chong perhaps?) added changing the
user theme to `customize-set-variable' thought
that was appropriate.

I don't care about that, personally.  But if
you think we "need" a function that does what
`customize-set-variable' does but doesn't
affect the user theme, then...

> so it needs to be short and snappy.

It needs to be short & snappy for `M-:'?  Why?

`M-:' is for evaluating all kinds of Lisp
sexps.  Why does this, in particular, need a
short name?

If this is about being able to _only_ set an
option value interactively, then what's wrong
with a command? (`M-x customize-set-variable')

> `seto' and `setc' were proposed, but I thought
> those were too confusing.

It seems that `setopt' can also confuse.

And adding that function to `set-variable',
`customize-set-variable', `customize-set-value',
and `custom-set-variables' invites even more
confusion.

In the 2017 thread "custom-set-variables
considered harmful" there was talk of wanting
a shorter name for `custom-set-variables':

https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00048.html

And there was talk of a new function (with a
short name) that does, for options, what
`custom-set-variables' does, but does for
non-options what `setq' does.  For many use
cases users could just use that new function.

Is that what your `setopt' does?  Why not?
And why isn't it also a command?

Why wasn't there any proposal & discussion
for this (if I'm right that there was none)?

We have these commands: `customize-set-value',
`customize-set-variable', `set-variable', and
`customize-save-variable'.  And we have this
non-interactive function: `custom-set-variables'.

What more is really needed?  Just what is
`setopt' for, and exactly what does it do?
(No, I'm not going to download the code for
Emacs 29 to try to figure it out.)
___

There's also bug (enhancement request) #6578,
which asked to have `set-variable' respect a
defcustom :set.  You didn't want to do that.

That ER also asked to better document
`customize-set-variable'.  It isn't even
documented as such in the manuals (Emacs &
Elisp).  No wonder users don't use it as
much as they might.

Instead, the Emacs manual touts `set-variable',
even though it'll get you in trouble because
of :set.

 "The most convenient way to set a specific
  customizable variable is with 'M-x set-variable'."

ER #6578 also suggested:

 "harmonizing behavior/features ... among
  `set-variable', `customize-set-variable',
  and `customize-set-value'.

  Emacs should be enhanced to clear up the
  confusing differences and clear up the doc
  recommendations."

You closed #6578, with the only reason given
that `set-variable' does what it's doc says it
does.  (Uh, yeah, its doc would need to reflect
its enhancement of respecting :set.)
___

There have also been requests (e.g. bug #26910)
to have `customize-set-variable' optionally
type-check the supplied value.

That too went nowhere.  And yet, if it's to be
used as a replacement for the Customize UI, it
really needs to _be able_ to type-check, no?

In that bug thread there was also suggestion to
provide a function like `custom-set-variables',
but which would optionally type-check each
variable setting that has a `NOW' element.
That too went nowhere (not even a response).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26910#8
___

So now we have `setopt'.

Yesterday, we had daily cleaning.  And tomorrow
morning, we shall have what to do after firing.
But today, today we have `setopt'.

Re: Comments on setopt

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> - Unless it makes more sense for `customize-set-variable' to take care
>   of it, should there be some type checking with errors or warnings if
>   the value doesn't match the type of a user option?

`customize-set-variable' should indeed warn/error out if the value is
invalid.

> - As `customize-set-variable' is being used directly, the "user" theme
>   is modified, and a customisation might be mirrored in
>   `custom-set-variables'.  This can lead to the unfortunate situation
>   where your setopt configuration is overriden by the
>   `custom-set-variables', depending on when and how you load `custom-file'
>   and when and how the `custom-set-variables' was generated.

Isn't that the case no matter how these variables are set?  It depends
on the order.

> - While I don't mind it really, I can imagine that others might object
>   to the "long" name, when compared to setq.  Would a default alias like
>   "seto" or "setc" be worth it or not?

I think `seto' is confusing, and `setc' doesn't really tell you
anything.  The salient thing is that we're setting user option, not that
it's been defined by `defcustom'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Comments on setopt

[Stefan Monnier]

>> - As `customize-set-variable' is being used directly, the "user" theme
>>   is modified, and a customisation might be mirrored in
>>   `custom-set-variables'.  This can lead to the unfortunate situation
>>   where your setopt configuration is overriden by the
>>   `custom-set-variables', depending on when and how you load `custom-file'
>>   and when and how the `custom-set-variables' was generated.
>
> Isn't that the case no matter how these variables are set?  It depends
> on the order.

No.  If you set the variable with `setq` Custom will notice that it was
set "outside of Custom" and thus refrain from saving the value into its
`customize-set-variables` block.

>> - While I don't mind it really, I can imagine that others might object
>>   to the "long" name, when compared to setq.  Would a default alias like
>>   "seto" or "setc" be worth it or not?
> I think `seto' is confusing, and `setc' doesn't really tell you
> anything.  The salient thing is that we're setting user option, not that
> it's been defined by `defcustom'.

FWIW, it took me a while to understand what "long name" Philip was
talking about because I assumed `setopt` wouldn't be considered as
long.  ;-)


        Stefan

Re: Comments on setopt

[Philip Kaludercic]

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

>>> - While I don't mind it really, I can imagine that others might object
>>>   to the "long" name, when compared to setq.  Would a default alias like
>>>   "seto" or "setc" be worth it or not?
>> I think `seto' is confusing, and `setc' doesn't really tell you
>> anything.  The salient thing is that we're setting user option, not that
>> it's been defined by `defcustom'.
>
> FWIW, it took me a while to understand what "long name" Philip was
> talking about because I assumed `setopt` wouldn't be considered as
> long.  ;-)


The only reason I bring this up is that if someone has a block like

  (setq save-interprogram-paste-before-kill t
        kill-do-not-save-duplicates t
        mouse-yank-at-point t)

they might hesitate to use setopt, purely because of the aesthetic
disadvantage of now being indented more:

  (setopt save-interprogram-paste-before-kill t
          kill-do-not-save-duplicates t
          mouse-yank-at-point t)

Again, nothing critical (one could also start listing option in the
second line), but something I could anticipate being brought up..

>
>         Stefan
>

-- 
	Philip Kaludercic

Re: Comments on setopt

[Lars Ingebrigtsen]

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

> No.  If you set the variable with `setq` Custom will notice that it was
> set "outside of Custom" and thus refrain from saving the value into its
> `customize-set-variables` block.

Hm, right...  perhaps it should just do the custom-set stuff and skip
the rest...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Comments on setopt

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> - As `customize-set-variable' is being used directly, the "user" theme
>>   is modified, and a customisation might be mirrored in
>>   `custom-set-variables'.  This can lead to the unfortunate situation
>>   where your setopt configuration is overriden by the
>>   `custom-set-variables', depending on when and how you load `custom-file'
>>   and when and how the `custom-set-variables' was generated.
>
> Isn't that the case no matter how these variables are set?  It depends
> on the order.

Well yes, but the issue can still be confusing and isn't obvious to
solve at first.  Just recently I had a similar issue where
smtpmail-smtp-service was set to 25, despite my configuration setting
int to 587, even after restarting Emacs.  The reason was that in my
custom-file, it was reverted to 25 (for some reason), and of course,
just deleting the line isn't enough, as it might be re-genereted again.
I can deal with this, but I also recognise the potential for confusion.

-- 
	Philip Kaludercic

Re: Comments on setopt

[Juri Linkov]

>> - Unless it makes more sense for `customize-set-variable' to take care
>>   of it, should there be some type checking with errors or warnings if
>>   the value doesn't match the type of a user option?
>
> `customize-set-variable' should indeed warn/error out if the value is
> invalid.

Maybe like `set-variable' checks for custom-type.

Re: Comments on setopt

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> `customize-set-variable' should indeed warn/error out if the value is
>> invalid.
>
> Maybe like `set-variable' checks for custom-type.

Right.  I've now added that for setopt.  And since it's not relying on
customize-set-variable any more, that means that we don't have to break
customize-set-variable compatibility.  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no