GNU bug report logs - #11017
24.0.94; emacs-lock--kill-emacs-query-functions should ding

Previous Next

To reply to this bug, email your comments to 11017 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.94; emacs-lock--kill-emacs-query-functions should ding
Date: Thu, 15 Mar 2012 05:48:48 +0100

Hello,

if I lock a buffer and try to exit Emacs, I only get a message:

  "Buffer %S is locked and cannot be killed"

This is IMHO not enough.  If the user tries to exit Emacs while there
are locked buffers, he obviously has forgotten about these locks.  So,
there should be a (ding) to attract the user's attention.

Without this, the user will possibly continue saying "yes" to the
expected questions Emacs typically asks, and accidentally modify some
buffer, which is annoying.


Thanks,

Michael


In GNU Emacs 24.0.94.1 (i486-pc-linux-gnu, GTK+ Version 3.2.3)
 of 2012-03-12 on zelenka, modified by Debian
 (emacs-snapshot package, version 2:20120312-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11103901
Configured using:
 `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.0.94/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.0.94/site-lisp:/usr/share/emacs/site-lisp'
 '--without-compress-info' '--with-crt-dir=/usr/lib/i386-linux-gnu/'
 '--with-x=yes' '--with-x-toolkit=gtk3' '--with-imagemagick=yes'
 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu'
 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2''

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Thu, 15 Mar 2012 13:54:12 +0100

On Thu, Mar 15, 2012 at 05:48, Michael Heerdegen
<michael_heerdegen <at> web.de> wrote:

> if I lock a buffer and try to exit Emacs, I only get a message:
>
>  "Buffer %S is locked and cannot be killed"

Really? I get "Emacs cannot exit because buffer %S is locked".

> This is IMHO not enough.  If the user tries to exit Emacs while there
> are locked buffers, he obviously has forgotten about these locks. So,
> there should be a (ding) to attract the user's attention.

A ding is obnoxious to many people. It could be added as an option,
but it is not really necessary IMHO. You can use

(defadvice emacs-lock--kill-emacs-query-functions (around do-ding activate)
  ad-do-it
  (unless ad-return-value (ding)))

(defadvice emacs-lock--kill-emacs-hook (around do-ding activate)
  (condition-case err
      ad-do-it
    (error
     (ding)
     (signal (car err) (cdr err)))))

> Without this, the user will possibly continue saying "yes" to the
> expected questions Emacs typically asks, and accidentally modify some
> buffer, which is annoying.

Getting into the habit of typing without reading what Emac is saying
is dangerous because you can end typing Y to a question you would've
rather said N...

    Juanma

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Fri, 16 Mar 2012 02:11:22 +0100

Juanma Barranquero <lekktu <at> gmail.com> writes:

> > "Buffer %S is locked and cannot be killed"
>
> Really? I get "Emacs cannot exit because buffer %S is locked".

Sorry - I copied the wrong string.


>> [...] So, there should be a (ding) to attract the user's attention.
>
> A ding is obnoxious to many people.

That's why I think it's appropriate here ;-)


> It could be added as an option, but it is not really necessary IMHO.

I would appreciate such an option (what do others think?).


> Getting into the habit of typing without reading what Emac is saying
> is dangerous because you can end typing Y to a question you would've
> rather said N...

Right, no doubt.  Nevertheless, it may happen if you lack in
concentration at the end of your work...  I don't want to argue, we
obviously disagree.  I wrote this report because I thought others could
have the same wish.  Dunno if that's the case.


BTW: I wrote this some time ago:

   http://www.emacswiki.org/emacs/emacs-lock+.el

(Didn't adopt it for Emacs 24 yet.)

I wrote it mainly because of these two features:

  - when exiting Emacs, and there is a locked buffer, pop it up (because
    it's very likely that the user will want to see it next)

  - Optionally, let the user enter a short note of why he has locked the
    buffer.  Print this when the user tries to kill the buffer/ Emacs.
    Helpful as reminder for people who run Emacs for several days.

Maybe you find these useful, dunno - I don't mind if not.


Regards,

Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Thu, 15 Mar 2012 22:26:49 -0400

>> A ding is obnoxious to many people.

Those who don't like dings can customize it with visible-bell and
ring-bell-function, so I wouldn't worry too much about it.

> That's why I think it's appropriate here ;-)

I'm not sure I understand what the current behavior is, from what you
say, the situation is rather unusual and warrants trying to get the
user's attention, so maybe a ding is warranted.
But is the message actually visible or does it get immediately
overwritten by some other message?


        Stefan

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Fri, 16 Mar 2012 03:26:38 +0100

severity 11017 wishlist
found 11017 24.2
quit


On Fri, Mar 16, 2012 at 02:11, Michael Heerdegen
<michael_heerdegen <at> web.de> wrote:

> That's why I think it's appropriate here ;-)

Making an obnoxious feature the default wouldn't get much goodwill, I think.

> I would appreciate such an option (what do others think?).

IMO, instead of adding an option to call `ding', it would make more
sense to add a hook and let the user decide what do to with it. That's
post 24.1 anyway.

>  - when exiting Emacs, and there is a locked buffer, pop it up (because
>    it's very likely that the user will want to see it next)

Well, I suppose it makes sense as an optional feature, because you
will want to unlock it. In my case, I have bs-show customized to
display the (un)?locked state of buffers and can toggle it from there,
so no need to pop the buffer.

>  - Optionally, let the user enter a short note of why he has locked the
>    buffer.  Print this when the user tries to kill the buffer/ Emacs.
>    Helpful as reminder for people who run Emacs for several days.

Again, it seems useful, post-24.1.

I'm going to turn this into a wishlist, and we can revisit it after the release.

    Juanma

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Fri, 16 Mar 2012 03:30:45 +0100

> Those who don't like dings can customize it with visible-bell and
> ring-bell-function, so I wouldn't worry too much about it.

There's a difference between not wanting a ding *ever*, and not
wanting it in that specific case.

> But is the message actually visible or does it get immediately
> overwritten by some other message?

No, the message is visible. Try

  emacs -Q etc\NEWS -f emacs-lock-mode -f save-buffers-kill-terminal

    Juanma

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Sun, 18 Mar 2012 22:20:10 -0400

>> Those who don't like dings can customize it with visible-bell and
>> ring-bell-function, so I wouldn't worry too much about it.
> There's a difference between not wanting a ding *ever*, and not
> wanting it in that specific case.
>> But is the message actually visible or does it get immediately
>> overwritten by some other message?
> No, the message is visible.  Try
>   emacs -Q etc\NEWS -f emacs-lock-mode -f save-buffers-kill-terminal

Oh, I see.  Yes, the message is seen OK.  And I don't think emacs-lock
should ding in this case.  Maybe the code running
kill-emacs-query-functions should ding, on the other hand,


        Stefan

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Mon, 19 Mar 2012 10:04:10 +0100

On Mon, Mar 19, 2012 at 03:20, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> Oh, I see.  Yes, the message is seen OK.  And I don't think emacs-lock
> should ding in this case.

Agreed. I have a patch to add a hook, so the user can add ding, or
pop-to-buffer, or do whatever s/he wants. I think that suffices. I'll
send it to this bug's thread.

>  Maybe the code running
> kill-emacs-query-functions should ding, on the other hand,

Perhaps, but again, k-e-q-f has been as it is for a long time with no
complains, and the user can always use a before advice. But I'm not
opposed to it.

    Juanma

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Tue, 10 Apr 2012 16:33:47 +0200

On Mon, Mar 19, 2012 at 10:04, Juanma Barranquero <lekktu <at> gmail.com> wrote:

> Agreed. I have a patch to add a hook, so the user can add ding, or
> pop-to-buffer, or do whatever s/he wants. I think that suffices. I'll
> send it to this bug's thread.

Michael, this patch adds the hook described above. Could you please
test it and see whether it works for you use case?

As for the note option, I'm thinking about unobtrusive ways to add it.

    Juanma


=== modified file 'lisp/emacs-lock.el'
--- lisp/emacs-lock.el	2012-01-11 07:48:55 +0000
+++ lisp/emacs-lock.el	2012-04-10 14:28:22 +0000
@@ -81,6 +81,13 @@
   :group 'emacs-lock
   :version "24.1")

+(defcustom emacs-lock-locked-buffer-hook nil
+  "Abnormal hook run when Emacs Lock prevents exiting Emacs, or
killing a buffer.
+The functions get one argument, the first locked buffer found."
+  :type 'hook
+  :group 'emacs-lock
+  :version "24.2")
+
 (defvar emacs-lock-mode nil
   "If non-nil, the current buffer is locked.
 It can be one of the following values:
@@ -119,40 +126,45 @@
              (or (eq unlock 'all) (eq unlock action))))))

 (defun emacs-lock--exit-locked-buffer ()
-  "Return the name of the first exit-locked buffer found."
+  "Return the first exit-locked buffer found."
   (save-current-buffer
     (catch :found
       (dolist (buffer (buffer-list))
         (set-buffer buffer)
         (unless (or (emacs-lock--can-auto-unlock 'exit)
                     (memq emacs-lock-mode '(nil kill)))
-          (throw :found (buffer-name))))
+          (throw :found buffer)))
       nil)))

 (defun emacs-lock--kill-emacs-hook ()
   "Signal an error if any buffer is exit-locked.
 Used from `kill-emacs-hook' (which see)."
-  (let ((buffer-name (emacs-lock--exit-locked-buffer)))
-    (when buffer-name
-      (error "Emacs cannot exit because buffer %S is locked" buffer-name))))
+  (let ((locked (emacs-lock--exit-locked-buffer)))
+    (when locked
+      (run-hook-with-args 'emacs-lock-locked-buffer-hook locked)
+      (error "Emacs cannot exit because buffer %S is locked"
+             (buffer-name locked)))))

 (defun emacs-lock--kill-emacs-query-functions ()
   "Display a message if any buffer is exit-locked.
 Return a value appropriate for `kill-emacs-query-functions' (which see)."
   (let ((locked (emacs-lock--exit-locked-buffer)))
-    (or (not locked)
-        (progn
-          (message "Emacs cannot exit because buffer %S is locked" locked)
-          nil))))
+    (if (not locked)
+        t
+      (run-hook-with-args 'emacs-lock-locked-buffer-hook locked)
+      (message "Emacs cannot exit because buffer %S is locked"
+               (buffer-name locked))
+      nil)))

 (defun emacs-lock--kill-buffer-query-functions ()
   "Display a message if the current buffer is kill-locked.
 Return a value appropriate for `kill-buffer-query-functions' (which see)."
-  (or (emacs-lock--can-auto-unlock 'kill)
-      (memq emacs-lock-mode '(nil exit))
-      (progn
-        (message "Buffer %S is locked and cannot be killed" (buffer-name))
-        nil)))
+  (if (or (emacs-lock--can-auto-unlock 'kill)
+          (memq emacs-lock-mode '(nil exit)))
+      t
+    (run-hook-with-args 'emacs-lock-locked-buffer-hook (current-buffer))
+    (message "Buffer %S is locked and cannot be killed" (buffer-name))
+    nil))

 (defun emacs-lock--set-mode (mode arg)
   "Setter function for `emacs-lock-mode'."

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Juanma Barranquero <lekktu <at> gmail.com>
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Sat, 14 Apr 2012 02:36:38 +0200

Hello Juanma,

> Michael, this patch adds the hook described above. Could you please
> test it and see whether it works for you use case?

Yes, this looks really good.  With

(add-hook 'emacs-lock-locked-buffer-hook
          (lambda (buffer) (ding) (pop-to-buffer buffer)))

I get all I want.  So, I'm happy with your patch.

However, should `emacs-lock-locked-buffer-hook' not better be named
`...-functions' or so?  Because, from the manual:

|    By convention, abnormal hook names end in `-functions' or `-hooks'.
| If the variable's name ends in `-function', then its value is just a
| single function, not a list of functions.


> As for the note option, I'm thinking about unobtrusive ways to add it.

Mmh, the prefix arg of `emacs-lock-mode' is already used for the locking
mode.  So we'll probably need a separate command that reads the note
text and saves it to a buffer local variable, and maybe a user option
that controls if this command is run automatically by emacs-lock-mode.

Then I would just change the standard messages:

(message "Emacs cannot exit because buffer %S is locked"
               (buffer-name locked))

(message "Buffer %S is locked and cannot be killed" (buffer-name))

to include the note - Just a proposal.

Anyway, if you have a patch, please send it to the bug's address again.


Regards,

Michael.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94;
	emacs-lock--kill-emacs-query-functions should ding
Date: Sat, 14 Apr 2012 03:48:10 +0200

On Sat, Apr 14, 2012 at 02:36, Michael Heerdegen
<michael_heerdegen <at> web.de> wrote:

> However, should `emacs-lock-locked-buffer-hook' not better be named
> `...-functions' or so?

Yes, indeed. My mistake.

> Mmh, the prefix arg of `emacs-lock-mode' is already used for the locking
> mode.  So we'll probably need a separate command that reads the note
> text and saves it to a buffer local variable and maybe a user option
> that controls if this command is run automatically by emacs-lock-mode.

Yes. I initially thought that the separate command was unnecessary
(just e-l-m asking whenever the user option is t), but then it
wouldn't be possible to reset or modify the note.

> Anyway, if you have a patch, please send it to the bug's address again.

I'm going to commit the first patch (after -hook -> -functions), and
then I'll work on the note patch.

    Juanma

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions
 should ding
Date: Sat, 19 Sep 2020 17:00:37 +0200

Juanma Barranquero <lekktu <at> gmail.com> writes:

>> Anyway, if you have a patch, please send it to the bug's address again.
>
> I'm going to commit the first patch (after -hook -> -functions), and
> then I'll work on the note patch.

This was eight years ago -- it looks like the patch was applied, but I'm
not sure about the note thing?

  > - Optionally, let the user enter a short note of why he has locked the
  >   buffer.  Print this when the user tries to kill the buffer/ Emacs.
  >   Helpful as reminder for people who run Emacs for several days.

It doesn't look like this was implemented?  But it does sound kinda
useful...  would `M-x lock-buffer' just prompt for a reason?

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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions
 should ding
Date: Sun, 20 Sep 2020 00:36:21 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>   > - Optionally, let the user enter a short note of why he has locked the
>   >   buffer.  Print this when the user tries to kill the buffer/ Emacs.
>   >   Helpful as reminder for people who run Emacs for several days.
>
> It doesn't look like this was implemented?  But it does sound kinda
> useful...  would `M-x lock-buffer' just prompt for a reason?

I would say it would do that when called interactively with a prefix
arg.

Michael.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions
 should ding
Date: Sun, 20 Sep 2020 11:38:45 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>>   > - Optionally, let the user enter a short note of why he has locked the
>>   >   buffer.  Print this when the user tries to kill the buffer/ Emacs.
>>   >   Helpful as reminder for people who run Emacs for several days.
>>
>> It doesn't look like this was implemented?  But it does sound kinda
>> useful...  would `M-x lock-buffer' just prompt for a reason?
>
> I would say it would do that when called interactively with a prefix
> arg.

Sure; makes sense.

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions
 should ding
Date: Mon, 21 Mar 2022 22:47:13 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>>>   > - Optionally, let the user enter a short note of why he has locked the
>>>   >   buffer.  Print this when the user tries to kill the buffer/ Emacs.
>>>   >   Helpful as reminder for people who run Emacs for several days.
>>>
>>> It doesn't look like this was implemented?  But it does sound kinda
>>> useful...  would `M-x lock-buffer' just prompt for a reason?
>>
>> I would say it would do that when called interactively with a prefix
>> arg.
>
> Sure; makes sense.

Looking at this again -- this is really `emacs-lock-mode'?
`lock-buffer' does something completely unrelated.

But this is a minor mode, so the prefix arg is taken.  We could add a
`emacs-lock-set-reason' command, but...  would anybody use that?

I've never used `emacs-lock-mode', so I don't know what people er would
use it for.

Any opinions?

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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions
 should ding
Date: Tue, 22 Mar 2022 00:02:59 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Looking at this again -- this is really `emacs-lock-mode'?
> `lock-buffer' does something completely unrelated.

Indeed.  We were never discussing `lock-buffer', this is all about
`emacs-lock-mode'.

> But this is a minor mode, so the prefix arg is taken.

It is also already taken to set the "locking mode"... ;-)

> We could add a `emacs-lock-set-reason' command, but...  would anybody
> use that?

I would not, this would be too distracting.  Using the prefix arg of
the mode function, or a function in the mode hook that would
prompt automatically would be better.

But I still think the feature is useful in general.  When I'm getting
distracted by some other stuff, I want to know why I had locked that
buffer that prevents me from exiting.

> I've never used `emacs-lock-mode', so I don't know what people er would
> use it for.

I'm testing master for a long time now so I don't rely on locking
currently.  Locks don't survive crashes.

People don't use it because it's not really cool.

Michael.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions
 should ding
Date: Tue, 22 Mar 2022 15:07:47 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

>> But this is a minor mode, so the prefix arg is taken.
>
> It is also already taken to set the "locking mode"... ;-)
>
>> We could add a `emacs-lock-set-reason' command, but...  would anybody
>> use that?
>
> I would not, this would be too distracting.  Using the prefix arg of
> the mode function,

But the prefix arg is taken?

> or a function in the mode hook that would prompt automatically would
> be better.

I'm not sure I understand.  If we want to add prompting automatically,
we'd just do that in the mode function, surely?

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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11017 <at> debbugs.gnu.org
Subject: Re: bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions
 should ding
Date: Wed, 23 Mar 2022 00:37:30 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> > I would not, this would be too distracting.  Using the prefix arg of
> > the mode function,
>
> But the prefix arg is taken?

We could make it so that a plain prefix arg asks about the mode and the
reason string, instead of only about the mode as now.

> I'm not sure I understand.  If we want to add prompting automatically,
> we'd just do that in the mode function, surely?

My thinking was that with a hook function it would be the users choice
_if_ there was an automatic prompting or not.  But we could also use a
new user option for that choice and do it in the mode function, sure.

Michael.

Previous Next

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