bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Michael Heerdegen]

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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Juanma Barranquero]

On Thu, Mar 15, 2012 at 05:48, Michael Heerdegen
<michael_heerdegen@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Michael Heerdegen]

Juanma Barranquero <lekktu@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.

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Juanma Barranquero]

severity 11017 wishlist
found 11017 24.2
quit


On Fri, Mar 16, 2012 at 02:11, Michael Heerdegen
<michael_heerdegen@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Stefan Monnier]

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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Juanma Barranquero]

> 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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Stefan Monnier]

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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Juanma Barranquero]

On Mon, Mar 19, 2012 at 03:20, Stefan Monnier <monnier@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Juanma Barranquero]

On Mon, Mar 19, 2012 at 10:04, Juanma Barranquero <lekktu@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'."

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Michael Heerdegen]

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.

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Juanma Barranquero]

On Sat, Apr 14, 2012 at 02:36, Michael Heerdegen
<michael_heerdegen@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Lars Ingebrigtsen]

Juanma Barranquero <lekktu@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@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.

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Lars Ingebrigtsen <larsi@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@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.

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@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

bug#11017: 24.0.94; emacs-lock--kill-emacs-query-functions should ding

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@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.