bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#69237: 30.0.50; Toggle password visibility


From: Kévin Le Gouguec
Subject: bug#69237: 30.0.50; Toggle password visibility
Date: Sun, 25 Feb 2024 13:34:26 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

Michael Albinus <michael.albinus@gmx.de> writes:

>> * Should we keep the double hyphen in "read-passwd--toggle-visibility"?
>> Feeling like it connotes "Emacs internals" somewhat, and wondering if
>> it's appropriate for interactive commands since they are "user-facing",
>> and users might feel discouraged from remapping "internal-looking"
>> commands.
>
> It is not intended that users call 'M-x read-passwd--toggle-visibility'.
> It makes sense only when you are already editing the minibuffer, typing
> the password.

Right, I don't expect many users to run this command via M-x.  My
thinking went more toward users who might want to do…

  (keymap-unset read-passwd-map "\t" 'remove)
  (keymap-set read-passwd-map "C-c \t" 'read-passwd--toggle-visibility)

… and who might feel uneasy about that "--" in their personal config.

>> * For the 'text icon variants, should we follow outline.el's example and
>> use full verbs, like " reveal " and " conceal "?
>
> Hmm. It would be too much space of the mode-line, I fear. See the other
> examples, for example in tab-bar.el or tab-line.el.

Yep, those tab bar & line examples work very well because the symbols
("+", "x") ought to be familiar to users working with tabs in other UIs.
For read-passwd, I'd argue it's a taller order to expect users to intuit
what "o" and "x" mean.

I'd also argue the extra mode-line space should not matter that much,
since it's a transient situation that will last only until the user is
done typing their password, and the displaced mode-line content might
not be that relevant to the user in that exact moment anyway.  Maybe we
can bike-shed some shorter ASCII art, e.g.

  <o> (reveal)
  <\> (conceal)

(All those nits are pretty academic, admittedly, at least as far as I am
concerned, as I do not expect to rebind the command, nor to rely on the
'text icon form)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]