[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lo
From: |
Ihor Radchenko |
Subject: |
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@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, Ihor Radchenko, 2022/05/16
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Eli Zaretskii, 2022/05/16
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Lars Ingebrigtsen, 2022/05/17
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Ihor Radchenko, 2022/05/18
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Lars Ingebrigtsen, 2022/05/18
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Eli Zaretskii, 2022/05/18
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode,
Ihor Radchenko <=
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Eli Zaretskii, 2022/05/19
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Ihor Radchenko, 2022/05/20
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Richard Stallman, 2022/05/19
- bug#55451: 28.1.50; Executing (jit-lock-mode -1) does not disable jit-lock-mode, Eli Zaretskii, 2022/05/20