unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
@ 2022-05-16 14:00 Ihor Radchenko
  2022-05-16 15:53 ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Ihor Radchenko @ 2022-05-16 14:00 UTC (permalink / raw)
  To: 55451

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-16 14:00 bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode Ihor Radchenko
@ 2022-05-16 15:53 ` Eli Zaretskii
  2022-05-17 18:03   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2022-05-16 15:53 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 55451

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-16 15:53 ` Eli Zaretskii
@ 2022-05-17 18:03   ` Lars Ingebrigtsen
  2022-05-18 11:46     ` Ihor Radchenko
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-17 18:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Ihor Radchenko, 55451

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-17 18:03   ` Lars Ingebrigtsen
@ 2022-05-18 11:46     ` Ihor Radchenko
  2022-05-18 17:27       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Ihor Radchenko @ 2022-05-18 11:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, 55451

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


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-18 11:46     ` Ihor Radchenko
@ 2022-05-18 17:27       ` Lars Ingebrigtsen
  2022-05-18 17:41         ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-18 17:27 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Eli Zaretskii, 55451

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-18 17:27       ` Lars Ingebrigtsen
@ 2022-05-18 17:41         ` Eli Zaretskii
  2022-05-19 13:49           ` Ihor Radchenko
  2022-05-19 23:13           ` Richard Stallman
  0 siblings, 2 replies; 11+ messages in thread
From: Eli Zaretskii @ 2022-05-18 17:41 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: yantar92, 55451

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-18 17:41         ` Eli Zaretskii
@ 2022-05-19 13:49           ` Ihor Radchenko
  2022-05-19 14:00             ` Eli Zaretskii
  2022-05-19 23:13           ` Richard Stallman
  1 sibling, 1 reply; 11+ messages in thread
From: Ihor Radchenko @ 2022-05-19 13:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 55451

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







^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-19 13:49           ` Ihor Radchenko
@ 2022-05-19 14:00             ` Eli Zaretskii
  2022-05-20  8:13               ` Ihor Radchenko
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2022-05-19 14:00 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: larsi, 55451

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-18 17:41         ` Eli Zaretskii
  2022-05-19 13:49           ` Ihor Radchenko
@ 2022-05-19 23:13           ` Richard Stallman
  2022-05-20  6:55             ` Eli Zaretskii
  1 sibling, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2022-05-19 23:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, yantar92, 55451

[[[ 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)







^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-19 23:13           ` Richard Stallman
@ 2022-05-20  6:55             ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2022-05-20  6:55 UTC (permalink / raw)
  To: rms; +Cc: larsi, yantar92, 55451

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode
  2022-05-19 14:00             ` Eli Zaretskii
@ 2022-05-20  8:13               ` Ihor Radchenko
  0 siblings, 0 replies; 11+ messages in thread
From: Ihor Radchenko @ 2022-05-20  8:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 55451

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






^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-05-20  8:13 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-05-16 14:00 bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode Ihor Radchenko
2022-05-16 15:53 ` Eli Zaretskii
2022-05-17 18:03   ` Lars Ingebrigtsen
2022-05-18 11:46     ` Ihor Radchenko
2022-05-18 17:27       ` Lars Ingebrigtsen
2022-05-18 17:41         ` Eli Zaretskii
2022-05-19 13:49           ` Ihor Radchenko
2022-05-19 14:00             ` Eli Zaretskii
2022-05-20  8:13               ` Ihor Radchenko
2022-05-19 23:13           ` Richard Stallman
2022-05-20  6:55             ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).