Subject: bug#73768: 'read-passwd-mode' can clobber user defined mode lines

From: Michael Albinus <[email-masked]>
Date: Thu, 17 Oct 2024 09:58:08 +0200

martin rudalics <[email-masked]> writes:

Hi Martin,

> Hold your horses.  First try another recipe: With emacs -Q do C-x 5 2
> followed by C-x b to show *Messages* in either of the frames, read a
> password, do C-x 5 o and type C-g.  One of the two buffers has the eye
> icon the other has the botched mode line.  I'm using the more accurate
> patch attached now to hopefully fix that too.  Note that whenever one
> switches frames, the mode line showing the eye will always stay with the
> initially chosen buffer and not the one where the minibuffer window is.

Thanks for this. As said I'm a n00b wrt to Emacs window management, so
pls install your patch since it makes the situation better.

> But there are other scenarios that don't seem right.  While reading one
> password ask for reading another one.  You now should see two eye icons
> which, however, cannot be attributed to any of the two read operations.
> Clicking on either of them will toggle visibility of the password.  If
> you don't want to show the password for the first operation but you do
> want to show it for the second operation, then when the second operation
> terminates you will see the password for the first one.  Same for typing
> TAB in the minibuffer.  Resetting 'read-passwd--hide-password' when
> terminating any read password operation might fix that.
>
> Likely password visibility should be a property of the specific reading
> process (aka as buffer-local value of 'read-passwd--hide-password') and
> not something global.  But then we would also have to change the first
> icon of the mode line too and doing that is more tricky.  Currently, all
> eye icons are the same because 'read-passwd--mode-line-icon' has the
> same value for them.
>
> Probably it might be better to have only one eye icon on any mode line
> informing about the visibility of the innermost minibuffer's password
> status.  But this becomes tricky when terminating a password operation
> because we would have to internally (on the C-level) scan all
> minibuffers to find out whether there's another password operation in
> progress and remove the eye icon only if there's none.
>
> Otherwise we could try giving only the first eye icon the dynamic eval
> property and have all other icons statically have the hide password
> property.  Less tricky - we'd only have to hide a password when asking
> for another one.
>
> Obviously, we could also inhibit asking for a second password.  But I
> suppose this was always possible and would imply an incompatible change.

I haven't seen any application in the wild which offers cascaded
password input. What would be the use case for this? My feeling is, that
this is a misuse. We might not forbid it, but we might show a warning.

> If anyone has a good idea what to do here, please speak up.

Sigh.

> Thanks, martin

Best regards, Michael.