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 <sch...@linux-m68k.org> 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." >
