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