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

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

[Ihor Radchenko]

Hi,

I recently tried to disable jit-lock-mode using the usual syntax
(jit-lock-mode -1)

However, the mode was not disabled, which is unexpected.
I believe that the problem is caused by

....
If you need to debug code run from jit-lock, see `jit-lock-debug-mode'."
  (setq jit-lock-mode arg) ;; <- this sets jit-lock-mode to non-nil even if I pass -1 argument
  (cond
   ((and (buffer-base-buffer)
....

Best,
Ihor

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Mon, 16 May 2022 22:00:58 +0800
> 
> I recently tried to disable jit-lock-mode using the usual syntax
> (jit-lock-mode -1)

jit-lock-mode is not a minor mode, so the usual syntax doesn't work
with it, and isn't documented to work.  Set it to nil to disable.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> jit-lock-mode is not a minor mode, so the usual syntax doesn't work
> with it, and isn't documented to work.  Set it to nil to disable.

The doc string could do with some explicit text about this, so I've
added that to Emacs 29.  But since this is working as intended, I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Ihor Radchenko]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> jit-lock-mode is not a minor mode, so the usual syntax doesn't work
>> with it, and isn't documented to work.  Set it to nil to disable.
>
> The doc string could do with some explicit text about this, so I've
> added that to Emacs 29.  But since this is working as intended, I'm
> closing this bug report.

Thanks! It certainly improves the situation.
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.

A possible patch is attached.

Best,
Ihor


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-jit-lock-mode-Treat-1-and-1-ARG-as-other-normal-mino.patch --]
[-- Type: text/x-patch, Size: 1011 bytes --]

From a9da60ba42f6745f4bbdb305e057639c40f8d34e Mon Sep 17 00:00:00 2001
Message-Id: <a9da60ba42f6745f4bbdb305e057639c40f8d34e.1652874345.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Wed, 18 May 2022 19:44:25 +0800
Subject: [PATCH] jit-lock-mode: Treat +1 and -1 ARG as other normal minor
 modes

* lisp/jit-lock.el (jit-lock-mode): Recognise +1/-1 arguments using
minor mode conventions.
---
 lisp/jit-lock.el | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index 20c1202474..224223fc7e 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -218,7 +218,12 @@ jit-lock-mode
 the variable `jit-lock-stealth-nice'.
 
 If you need to debug code run from jit-lock, see `jit-lock-debug-mode'."
-  (setq jit-lock-mode arg)
+  (setq jit-lock-mode
+        (pcase arg
+          (`+1 t)
+          (`-1 nil)
+          (`nil nil)
+          (val val)))
   (cond
    ((and (buffer-base-buffer)
          jit-lock-mode)
-- 
2.35.1

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

[Lars Ingebrigtsen]

Ihor Radchenko <yantar92@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.

It's pretty unlikely that anybody's using -1 to switch it on, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  55451@debbugs.gnu.org
> Date: Wed, 18 May 2022 19:27:58 +0200
> 
> Ihor Radchenko <yantar92@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.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  55451@debbugs.gnu.org
>> Date: Wed, 18 May 2022 19:27:58 +0200
>> 
>> Ihor Radchenko <yantar92@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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  55451@debbugs.gnu.org
> Date: Thu, 19 May 2022 21:49:21 +0800
> 
> > 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.

But the doc string already caters to your use case:

  If you need to debug code run from jit-lock, see `jit-lock-debug-mode'

> I would not expect users to read minor mode docstring every time to
> check if the usual convention is broken.

Users don't need to turn off jit-lock.  People who want to debug it,
OTOH, _are_ expected to read the doc string.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

I don't think I have ever turned off Jit-Lock mode _as such_, but I
turn off Font-Lock mode in some major modes.  I don't know whether
that is that pertinent to this issue; I mention it just in case.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, yantar92@gmail.com, 55451@debbugs.gnu.org
> Date: Thu, 19 May 2022 19:13:43 -0400
> 
>   > 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.
> 
> I don't think I have ever turned off Jit-Lock mode _as such_, but I
> turn off Font-Lock mode in some major modes.  I don't know whether
> that is that pertinent to this issue

It isn't, AFAIU.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.
>
> But the doc string already caters to your use case:
>
>   If you need to debug code run from jit-lock, see `jit-lock-debug-mode'

To clarify, I was trying to debug race condition in font-lock itself.
jit-lock made things even more complex and I just wanted to quickly
disable it. I did not want to debug jit-lock behaviour at all.

>> I would not expect users to read minor mode docstring every time to
>> check if the usual convention is broken.
>
> Users don't need to turn off jit-lock.  People who want to debug it,
> OTOH, _are_ expected to read the doc string.

I understand. I do not consider the described issue critical. However,
from a perspective of Elisp developer, minor mode docstrings rarely
contain low-level information. Rather general minor mode description +
standard boilerplate generated by define-minor-mode. That boilerplate is
well-known an is usually not worth checking out multiple times:

>>> This is a minor mode.  If called interactively, toggle the
>>> Org-Indent mode mode.  If the prefix argument is positive,
>>> enable the mode, and if it is zero or negative, disable the mode.
>>> 
>>> If called from Lisp, toggle the mode if ARG is toggle.  Enable
>>> the mode if ARG is nil, omitted, or is a positive number.
>>> Disable the mode if ARG is a negative number.
>>> 
>>> To check whether the minor mode is enabled in the current buffer,
>>> evaluate ...

So, I would not expect that habituated developers actually check out the
docstring regarding enabling/disabling the mode. At least I did not
until I realised that something is strange and jit-lock-mode was not
disabled after M-: (jit-lock-mode -1)

Again, it is just my perspective consisting of a single personal
datapoint. If you think that the current state is ok, feel free to
disregard my complaint.

Best,
Ihor