GNU bug report logs - #35523
26.1.92; Please add "PIN" to password-word-equivalents

Previous Next

Full log

View this message in rfc822 format

From: npostavs <at> gmail.com
To: 35523 <at> debbugs.gnu.org
Cc: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Subject: bug#35523: 26.1.92; Please add "PIN" to password-word-equivalents
Date: Wed, 01 May 2019 10:31:22 -0400

[Message part 1 (text/plain, inline)]

[forwarding to list, please use "Reply All" to keep 35523 <at> debbugs.gnu.org on Cc]

[Message part 2 (message/rfc822, inline)]

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#35523: 26.1.92; Please add "PIN" to password-word-equivalents
Date: Wed, 1 May 2019 09:06:02 -0400

> You could try loading your custom file earlier, or loading comint
> later.

I considered that, but rejected it; it's not blindingly obvious how or
when comint gets loaded, and thus unclear how early I'd need to load
my custom file (nor what else I might break by moving its loading
around).  I fear that juggling the timing like that would become an
endless game of whack-a-mole.

>  Otherwise, you can still avoid the extra load:
>
>     (when (boundp 'comint-password-prompt-regexp)
>       (setq password-word-equivalents
>             '("PIN" "password" "passcode" "passphrase" "pass phrase"))
>       ;; Reset to new standard value.
>       (setq comint-password-prompt-regexp
>             (eval (car (get 'comint-password-prompt-regexp 'standard-value)))))

Aha, that must be deep "defvar" magic.  I'd never heard of
'standard-value before.

I think I'll stick with reloading the whole library; it's clearer to me.

Thanks.

Previous Next

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