The warning messages can be misleading. e.g., when trying to set
tab-bar-format-tabs-groups to include a simple lambda, it complains about
the wrong thing. It does match the hook type, but does not match the
hard-coded list of options.
(setopt tab-bar-format
`(
tab-bar-f
It was removed in a later proposed edit. I read the setopt code more deeply
and ran some tests.
On Fri, Sep 13, 2024 at 3:09 PM Stefan Monnier
wrote:
> > If you encounter a discrepancy that cannot be addressed by amending
> > the type specified by a setopt call, and you can deem the desired
> >
> If you encounter a discrepancy that cannot be addressed by amending
> the type specified by a setopt call, and you can deem the desired
> type compatible nonetheless, use setq. If the user option has an
> associated \"setter\" you may invoke it manually using ???"
You're here trying to describe
> setopt will execute any custom-set form
^^^
> associated with VARIABLE
1. "custom-set form" isn't mentioned, let alone
defined, in the Elisp manual. Should this
say "any defcustom :set function" instead?
2. What about what I suppose you would call a
Revised language:
"Set VARIABLE/VALUE pairs with type warnings, 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
custom-set form associated with VARIABLE, and will emit a
warning if VALUE is not of th
> From: Ship Mints
> Date: Fri, 13 Sep 2024 11:11:18 -0400
> Cc: Stefan Monnier , Eli Zaretskii ,
> Michael Heerdegen , 73...@debbugs.gnu.org
>
> Perhaps, some expanded advice in the docstring for setopt?
>
> "Set VARIABLE/VALUE pairs with enforced types, and return the final VALUE.
"Enf
Happy for the thoughtful feedback.
Perhaps, some expanded advice in the docstring for setopt?
"Set VARIABLE/VALUE pairs with enforced types, 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
custom-se
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" writes:
> I tend to agree. If the type doesn't accept the value, you can use
> something lower-level than `setopt`, while you argue with the maintainer
> to try and get them to change their type.
>
> IMO, the wh
>> I tend to agree. If the type doesn't accept the value, you can use
>> something lower-level than `setopt` [...]
> What would that be in case the option has a custom setter function?
AFAIK people used `setq` before `setopt`. For vars that come with
setter functions, this usually doesn't work q
> From: Stefan Monnier
> Cc: Michael Heerdegen , shipmi...@gmail.com,
> 73...@debbugs.gnu.org
> Date: Mon, 09 Sep 2024 18:41:46 -0400
>
> IMO, the whole point of `setopt` is to check the value against the type.
I agree, but some users expect setopt to be a variant of setq,
especially since we
Stefan Monnier writes:
> I tend to agree. If the type doesn't accept the value, you can use
> something lower-level than `setopt` [...]
What would that be in case the option has a custom setter function?
Michael.
> Like what? Would we accept, for example, a string where the type is
> 'symbol'? Or any value where type is 'boolean'?
>
> And I'm also not sure we want this: presumably, if the defcustom's
> author specified a type, they meant it, no?
I tend to agree. If the type doesn't accept the value, you
> From: Michael Heerdegen
> Cc: monn...@iro.umontreal.ca, shipmi...@gmail.com, 73...@debbugs.gnu.org
> Date: Mon, 09 Sep 2024 19:46:56 +0200
>
> Eli Zaretskii writes:
>
> > Thanks, but this sounds like overkill to me.
>
> Hmm... maybe. And the idea of an extra macro?
Likewise.
I think we
Eli Zaretskii writes:
> Thanks, but this sounds like overkill to me.
Hmm... maybe. And the idea of an extra macro?
Michael.
> From: Michael Heerdegen
> Cc: Stefan Monnier , shipmi...@gmail.com,
> 73...@debbugs.gnu.org
> Date: Mon, 09 Sep 2024 18:38:43 +0200
>
> Eli Zaretskii writes:
>
> > > How about adding an option letting the user disable the type checking of
> > > some options?
> >
> > Like what? Would we ac
Ship Mints writes:
> Perhaps an alternative macro `setopt-relaxed"? Documentation should
> suggest contacting package authors to request improvements (it's a
> very slow process to get misspecified packages updated and not all
> authors mean what they say when they themselves don't use the
> cust
Eli Zaretskii writes:
> > How about adding an option letting the user disable the type checking of
> > some options?
>
> Like what? Would we accept, for example, a string where the type is
> 'symbol'? Or any value where type is 'boolean'?
The new option would have as value a list of option nam
Perhaps an alternative macro `setopt-relaxed"? Documentation should suggest
contacting package authors to request improvements (it's a very slow
process to get misspecified packages updated and not all authors mean what
they say when they themselves don't use the customize system--this group
must k
> From: Michael Heerdegen
> Cc: Eli Zaretskii , 73...@debbugs.gnu.org
> Date: Mon, 09 Sep 2024 17:11:40 +0200
>
> Ship Mints writes:
>
> > I'm suggesting that there will be noise from people who convert from a
> > working (setq some-package-option 2) to (setopt some-package-option
> > 2). This
Ship Mints writes:
> I'm suggesting that there will be noise from people who convert from a
> working (setq some-package-option 2) to (setopt some-package-option
> 2). This is not a request to change the elisp type system, it is a
> request to consider if setopt's / customize internals should be
100% correct...when one controls the code base in question. For the many
packages out there with strict types in their defcustom definitions and
with many/most users using setq over customize, there will be lots of
surprise for simple cases like this when they try setopt. Perhaps more
vocal advisor
On Sep 08 2024, Ship Mints wrote:
> There are cases in elisp where numeric type coercion is the default,
> e.g., (= 2.0 2) is t. I expected it to be so here, too.
That's because the function accepts a number, not a float. If you want
to accept any kind of number, just say so.
--
Andreas Schwab
I'm suggesting that there will be noise from people who convert from a
working (setq some-package-option 2) to (setopt some-package-option 2).
This is not a request to change the elisp type system, it is a request to
consider if setopt's / customize internals should be relaxed to the
equivalent of
> From: Ship Mints
> Date: Sun, 8 Sep 2024 06:59:31 -0400
> Cc: 73...@debbugs.gnu.org
>
> Yessir. I was talking about users' likely expectations for type coercion.
> There are cases in elisp where numeric
> type coercion is the default, e.g., (= 2.0 2) is t. I expected it to be so
> here, too.
Yessir. I was talking about users' likely expectations for type coercion.
There are cases in elisp where numeric type coercion is the default,
e.g., (= 2.0 2) is t. I expected it to be so here, too.
If you feel this is moot, then so be it.
On Sun, Sep 8, 2024 at 2:07 AM Eli Zaretskii wrote:
> >
> From: Ship Mints
> Date: Sat, 7 Sep 2024 09:14:54 -0400
>
> This one bit me yesterday on Emacs 29.3 as I was revising my init file (for
> the thousandth time this week).
>
> As setopt becomes more widely recommended, people will likely encounter
> situations like the below where they
> expec
This one bit me yesterday on Emacs 29.3 as I was revising my init file (for
the thousandth time this week).
As setopt becomes more widely recommended, people will likely encounter
situations like the below where they expect constant numeric types to be
coerced.
(defcustom temp-float "Float"
"Fl
27 matches
Mail list logo
