bug#73098: setopt float warning unexpected
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" "Float type." :type 'float) (setopt temp-float 2.0) ; works (setopt temp-float 2) ; Warning (emacs): Value '2' does not match type float -Stephane P.S. I reported a bug to Prot as some much more complex modus defcustom type definitions seem either themselves broken or setopt needs some work to accommodate them.
bug#73098: setopt float warning unexpected
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 > > expect constant numeric types to be coerced. > > > > (defcustom temp-float "Float" > > "Float type." > > :type 'float) > > > > (setopt temp-float 2.0) ; works > > (setopt temp-float 2) ; Warning (emacs): Value '2' does not match type > float > > If you are going to allow integer values, shouldn't :type be 'number, > not 'float? The documentation of 'float says: > > ‘float’ >The value must be floating point. > > "Must be floating point." The value 2 isn't. >
bug#73098: setopt float warning unexpected
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 #'= for these simple cases. On Sun, Sep 8, 2024 at 7:09 AM Eli Zaretskii wrote: > > 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. > > > > If you feel this is moot, then so be it. > > Let's see if there are other opinions. > > But basically, you'd like 'float to be an alias for 'number, right? >
bug#73098: setopt float warning unexpected
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 advisories for package authors to provide updates (though many seem fallow), and for users might be sufficient without resorting to monkey patching. Most, I suspect, will just revert to setq and ignore custom type validations. Most don't even check for the presence of setters and I've assisted many in my circles with their resulting heisenbugs. On Sun, Sep 8, 2024 at 7:39 AM Andreas Schwab wrote: > 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, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
bug#73098: setopt float warning unexpected
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 know this all too well). On Mon, Sep 9, 2024 at 11:28 AM Eli Zaretskii wrote: > > 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 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 #'= for these simple cases. > > > > 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'? > > And I'm also not sure we want this: presumably, if the defcustom's > author specified a type, they meant it, no? > > Which is why I asked for opinions (but for now got only yours). > > Stefan, WDYT? >
bug#73098: setopt float warning unexpected
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-set form associated with VARIABLE, and strictly ensure that VALUE is of the type declared by the user option. Example: If the user option is declared to accept a `float', set the option to 2.0, not to 2 which is considered an `integer'. Note: Many user options accept more complex types than a scalar float and that may pose a challenge to address when setting them in elisp using setopt. 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 ???" Then there's the twist that some options force content checks, not just type checks. An example of a user option that is intended to be overridden with custom entries is tab-bar-format. The setopt type checker will barf on entries not strictly in the tab-bar-format pre-populated list despite the type being a normal hook. On Wed, Sep 11, 2024 at 6:53 PM Stefan Kangas wrote: > 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 whole point of `setopt` is to check the value against the type. > > +1 >
bug#73098: setopt float warning unexpected
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 the type expected by the user option. Example: If the user option is declared to accept a `float', set the option to 2.0 rather than 2, which is considered an `integer'. Despite the warning, the user option will still be set to VALUE." On Fri, Sep 13, 2024 at 11:28 AM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Fri, 13 Sep 2024 11:11:18 -0400 > > Cc: Stefan Monnier , Eli Zaretskii < > e...@gnu.org>, > > 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. > > "Enforce" is inaccurate, since a value that doesn't match :type just > emits a warning (which can be shut up by the users, if they want), it > doesn't signal an error. And the variable is assigned the value event > if the type doesn't match. >
bug#73098: setopt float warning unexpected
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 > > 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 workarounds to use in case of bugs > (either the value you set is wrong, or the type (or type-checker) is > wrong). We usually don't do that in docstrings. > > > Stefan > >
bug#73098: setopt float warning unexpected
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-format-tabs-groups (lambda () " ") ; tab-bar-separator )) ■ Warning (emacs): Value '(nil tab-bar-format-tabs-groups (lambda nil " "))' does not match type hook On Fri, Sep 13, 2024 at 3:26 PM Ship Mints wrote: > 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 >> > 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 workarounds to use in case of bugs >> (either the value you set is wrong, or the type (or type-checker) is >> wrong). We usually don't do that in docstrings. >> >> >> Stefan >> >>
