GNU bug report logs - #55451
28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode

Previous Next

Full log

Message #25 received at 55451 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 55451 <at> debbugs.gnu.org
Subject: Re: bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not
 disable jit-lock-mode
Date: Thu, 19 May 2022 21:49:21 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  55451 <at> debbugs.gnu.org
>> Date: Wed, 18 May 2022 19:27:58 +0200
>> 
>> Ihor Radchenko <yantar92 <at> gmail.com> writes:
>> 
>> > However, I am confused why it is impossible to follow +1/-1 convention.
>> > Looking through jit-lock.el I do not see any place where any value other
>> > than non-nil/nil is considered.
>> 
>> It would be incompatible -- all non-nil values switch jit-lock on
>> presently, including -1.
>
> Yes.  Moreover, it's hardly worth the hassle: who would switch off
> jit-lock, except for debugging jit-lock?  Most people will never do,
> which is very unlike every minor mode out there -- those are switched
> on and off all the time.  It isn't an accident that we don't have the
> "M-x jit-lock-mode" command.

That's exactly the situation I had:
1. Tried M-x jit-lock-mode. Did not work. Understandable - special minor
   mode.
2. M-: (jit-lock-mode -1). No error. Executed.
3. Tried to debug something assuming that jit-lock is disabled.
4. After several minutes, realised that jit-lock is still working.

So, similar to other Elisp conventions, I do expect everything called
minor mode to follow the calling convention with +1/-1. Not doing so is
a surprise. Not doing so without a clear indication (like an error) is a
recipe for confusion.

I would not expect users to read minor mode docstring every time to
check if the usual convention is broken. There should be some kind of
indication at least, be it an unusual symbol name, a user error, or
something similarly noticeable.

Best,
Ihor

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.