bug#38265: 26.3; lock file is too easy to steal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#38265: 26.3; lock file is too easy to steal

Allen Li-2
The default ask-user-about-lock is too easy to miss.

For example, if one were typing "asparagus", they would likely steal the
lock without even realizing that it happened (the "a" triggers the
prompt on buffer modification and the "s" steals the lock).

It would be nice to have the prompt be harder to hit accidentally, such
as making all of the keys uppercase or having to type them out like
yes/no (but the latter might be too heavyweight).  Or the prompt should
have a short timeout before allowing the user to respond (like how
yes-or-no-p does when you provide an invalid response).

In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Arch Linux



Reply | Threaded
Open this post in threaded view
|

bug#38265: 26.3; lock file is too easy to steal

Juri Linkov-2
> The default ask-user-about-lock is too easy to miss.
>
> For example, if one were typing "asparagus", they would likely steal the
> lock without even realizing that it happened (the "a" triggers the
> prompt on buffer modification and the "s" steals the lock).
>
> It would be nice to have the prompt be harder to hit accidentally, such
> as making all of the keys uppercase or having to type them out like
> yes/no (but the latter might be too heavyweight).  Or the prompt should
> have a short timeout before allowing the user to respond (like how
> yes-or-no-p does when you provide an invalid response).

On the request in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00517.html
recently ‘(discard-input)’ was removed from ‘read-char-from-minibuffer’.
Should it be put back?

ask-user-about-supersession-threat uses read-char-from-minibuffer, so if
it contained ‘(discard-input)’ it could benefit from discarding such
inadvertent input as "s".

But what about the case of keyboard macros like in the link above?
What if the user recorded a keyboard macro to input that "s" intentionally?