--- Begin Message ---
|
Subject: |
26.0.50; Minor mode functions should do strict argument type checking |
|
Date: |
Sun, 16 Oct 2016 17:45:58 +0200 |
After defining a minor mode with
(define-minor-mode foo-mode nil)
its docstring will be
"Toggle Foo mode on or off.
With a prefix argument ARG, enable Foo mode if ARG is
positive, and disable it otherwise. If called from Lisp, enable
the mode if ARG is omitted or nil, and toggle it if ARG is ‘toggle’."
This appears to indicate that
(foo-mode 'banana)
should disable foo-mode, but it enables it. I think minor modes should
simply not allow anything but integers and 'toggle for ARG, avoiding
this confusion.
In GNU Emacs 26.0.50.3 (x86_64-apple-darwin16.0.0, NS appkit-1504.00 Version
10.12 (Build 16A323))
of 2016-10-16 built on p
Repository revision: cf566b46a6cf85c6d54d0b0db80e32ed6ae8d1ca
Windowing system distributor 'Apple', version 10.3.1504
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Configured using:
'configure --with-modules --enable-checking
--enable-check-lisp-object-type --without-xml2'
Configured features:
RSVG IMAGEMAGICK DBUS NOTIFY ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS
MODULES
Important settings:
value of $LANG: de_DE.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind kqueue cocoa ns multi-tty
make-network-process emacs)
Memory information:
((conses 16 206734 11456)
(symbols 48 20333 0)
(miscs 40 50 157)
(strings 32 18351 5209)
(string-bytes 1 593891)
(vectors 16 35291)
(vector-slots 8 676180 5448)
(floats 8 183 64)
(intervals 56 219 0)
(buffers 976 12))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#24706: 26.0.50; Minor mode functions should do strict argument type checking |
|
Date: |
Thu, 1 Oct 2020 05:12:49 -0700 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philipp Stephani <p.stephani2@gmail.com>
>> Date: Sat, 1 Aug 2020 22:47:03 +0200
>> Cc: Drew Adams <drew.adams@oracle.com>, 24706@debbugs.gnu.org
>>
>> Am Mi., 26. Apr. 2017 um 13:27 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>> >
>> > > From: Philipp Stephani <p.stephani2@gmail.com>
>> > > Date: Sun, 23 Apr 2017 17:51:32 +0000
>> > > Cc: drew.adams@oracle.com, 24706@debbugs.gnu.org
>> > >
>> > > Eli Zaretskii <eliz@gnu.org> schrieb am So., 16. Okt. 2016 um 20:51 Uhr:
>> > >
>> > > > From: Philipp Stephani <p.stephani2@gmail.com>
>> > > > Date: Sun, 16 Oct 2016 18:25:08 +0000
>
> It's hard to have a useful discussion when messages are several months
> apart.
>
>> > > The patch for the ELisp manual simply rearranges the same words, so
>> > > it's not clear to me why we would prefer it to what's already there.
>> > >
>> > > I don't think there's any repetition or rearranging here.
>> >
>> > Here's the ELisp manual part of your proposed change:
>> >
>> > If the mode command is called from Lisp (i.e., non-interactively), it
>> > -should enable the mode if the argument is omitted or @code{nil}; it
>> > -should toggle the mode if the argument is the symbol @code{toggle};
>> > -otherwise it should treat the argument in the same way as for an
>> > -interactive call with a numeric prefix argument, as described above.
>> > +should toggle the mode if the argument is the symbol @code{toggle}; it
>> > +should disable the mode if the argument is a non-positive integer;
>> > +otherwise, e.g., if the argument is omitted or nil or a positive
>> > +integer, it should enable the mode.
>> >
>> > Don't you agree that it does little apart of re-shuffling the same
>> > words?
>>
>> It also describes what happens when the argument is neither nil nor
>> `toggle' nor an integer. That is currently unspecified, or rather
>> implicitly specified by the observable (but unspecified) behavior of
>> `prefix-numeric-value'.
>
> I think the "otherwise" part describes that.
>
>> > > The key difference is that when called from Lisp with an
>> > > argument that is neither nil nor an integer, the mode is also enabled.
>> >
>> > Why would we want to require that? This subsection describes the
>> > conventions, it doesn't describe the effect of certain popular
>> > implementation of those conventions, because we don't really want to
>> > _require_ modes to behave in any way beyond the described behavior.
>>
>> This isn't about the implementation but the interface, i.e. the
>> observable behavior of minor mode functions.
>
> I don't see how making this the matter of interface changes anything.
> We still don't want to require modes to interpret the interface the
> way you'd like to see.
>
> Bottom line: I think there's nothing important left to discuss here.
That was 8 weeks ago, and there has been no further comments. I'm
therefore closing this bug now.
If there is anything more to do here, please reply to this email (use
"Reply to all" in your email client) and we can reopen the bug report.
Best regards,
Stefan Kangas
--- End Message ---