Please reinstantiate the red unlock indicator for C-u

[xtaran]

Dear Michael,

from the upstream changelog of i3lock 2.10:

• Immediately hide the unlock indicator after ESC / C-u (Thanks Orestis)

Please revert that (IMHO annoying mis-) feature for at least C-u and the not documented change for Backspace.

At least for me the red clearing unlock indicator served for several purpose for me (and probably also for other users):

• To disable the screen blanking without entering any part of a password and still being able to immediately get feedback if the system is still responding to key presses.

• To have some indicator how many Backspace presses have been received by e.g. an heavily loaded system.

I do see a need for a key to quickly hide the unlock indicator, but IMHO the only sense-making (and natural) key for that is the Escape key.

So please revert the above mentioned behaviour for C-u and Backspace, but keep it for Esc.

(Initially reported by me in Debian as #882828.)

[stapelberg]

Please revert that (IMHO annoying mis-) feature for at least C-u and the not documented change for Backspace.

I don’t observe any change in backspace, and the code change in question didn’t touch backspace (https://github.com/i3/i3lock/pull/145/files) — what do you mean?

At least for me the red clearing unlock indicator served for several purpose for me (and probably also for other users):

To disable the screen blanking without entering any part of a password and still being able to immediately get feedback if the system is still responding to key presses.

To have some indicator how many Backspace presses have been received by e.g. an heavily loaded system.

You could use the spacebar for the same purpose, or just enter your password. I understand that it doesn’t have exactly the same semantics, but those semantics aren’t a feature we wanted to build into i3lock in the first place.

I do see a need for a key to quickly hide the unlock indicator, but IMHO the only sense-making (and natural) key for that is the Escape key.

That’s very subjective. i3lock always treated C-u and Escape as synonyms, so I’d like to keep it that way.

[xtaran]

Hi Michael,

On Mon, Nov 27, 2017 at 07:33:51AM +0000, Michael Stapelberg wrote:

Please revert that (IMHO annoying mis-) feature for at least C-u and the not documented change for Backspace.

I don’t observe any change in backspace, and the code change in question didn’t touch backspace (https://github.com/i3/i3lock/pull/145/files) — what do you mean?

Indeed. I just noticed that Backspace still shows the red indicator if there is something to delete.

But if I remember correctly, in the past it also showed the red indicator if it was pressed more often than characters had been typed in before. Now the red indicator immediately vanishes as soon as there's nothing more left to delete. (I may be wrong here as I think I remember that behaviour, but never checked it explicitly in the past.)

You could use the spacebar for the same purpose, or just enter your password. I understand that it doesn’t have exactly the same semantics,

Exactly.

but those semantics aren’t a feature we wanted to build into i3lock in the first place.

sigh

What I already (or actually even more) would be happy with, would be if there was an (maybe optional) indicator that any input event has been registered, including mouse movements or mouse key presses. (But I do see that mouse support is not needed all in i3lock and hence very likely doesn't exist so far.)

I do see a need for a key to quickly hide the unlock indicator, but IMHO the only sense-making (and natural) key for that is the Escape key.

That’s very subjective.

Indeed.

i3lock always treated C-u and Escape as synonyms, so I’d like to keep it that way.

And for me (as an readline emacs-mode user) C-u and Escape generally have completely different semantics. C-u deletes the contents of a line and Escape either aborts something or does just nothing.

But more generally: What I was used to (and very happy with) was that there was also an indicator shown if something was "deleted" from the password buffer independent of the fact that something had been typed before. (It might be even a security feature if the number of already entered characters can't be deduced from looking at the indicator and counting how often it shows up before it hides.)

Maybe you could add an according option to enable either the old behaviour again or to generally show an indicator regardless of the pressed key or what was already typed? (The difference between entering and deleting something should be still visible. Either use red for the generic no-op indicator or maybe a third color, e.g. yellow.)

Which again raises the question again how to handle backwards compatibility without having the actually parse the output of "i3lock --version". But I fear I don't get around that, if I want to use i3lock with (as much as possible, since -d doesn't work anymore) the same behaviour on multiple systems with the same setup, but different Debian releases.

    Kind regards, Axel

[orestisfl]

Just checked out the commit before 8eecef62fb4837d42a0e16124d35fce6fc2588ae, the backspace behaviour seems to be the same: When the whole line is deleted the red indicator does not get renewed but the last indicator is shown until it times out.

If you press backspace before typing anything, nothing is shown.

[xtaran]

Hi,

On Mon, Nov 27, 2017 at 05:31:32PM +0000, Orestis wrote:

Just checked out the commit before 8eecef62fb4837d42a0e16124d35fce6fc2588ae, the backspace behaviour seems to be the same: When the whole line is deleted the red indicator does not get renewed but the last indicator is shown until it times out.

Yes, I can confirm that. Just checked it on a Debian Stable (Stretch) with i3lock 2.8. I indeed seem to have remembered it wrongly.

If you press backspace before typing anything, nothing is shown.

Confirmed, too.

[stapelberg]

And for me (as an readline emacs-mode user) C-u and Escape generally have completely different semantics. C-u deletes the contents of a line and Escape either aborts something or does just nothing.

How are these two not synonyms in the context of a password buffer? Deleting a line maps to “delete the contents of the password buffer” and aborting the current action maps to “abort entering a password, i.e. delete the contents of the password buffer”.

But more generally: What I was used to (and very happy with) was that there was also an indicator shown if something was "deleted" from the password buffer independent of the fact that something had been typed before. (It might be even a security feature if the number of already

The purpose of the unlock indicator is to expose i3lock’s state to users. Indicating that something was deleted, even though there was nothing to be deleted, clearly strikes me as wrong.

entered characters can't be deduced from looking at the indicator and counting how often it shows up before it hides.)

This would only be relevant when a computer is left unattended with the correct password (or at least a password of equal length) already in the buffer, which defeats the purpose of using a screen locker in the first place. Or am I misunderstanding?

Maybe you could add an according option to enable either the old behaviour again or to generally show an indicator regardless of the pressed key or what was already typed?

We generally try to keep options at a minimum, see also https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/index.html. For this particular case, I’m not convinced that adding an option is worth the costs.

My suggestion is still to press spacebar to get feedback without revealing your password. Why does this not work for you?

[stapelberg]

I just did some more tests on i3lock 2.9. Turns out pressing backspace doesn’t result in the indicator showing up (I had previously assumed it would). This leaves me puzzled as to how you relied on the indicator to get feedback for key presses. Which keys specifically did you press?

One interesting fact was raised by a friend of mine: some software rings the bell (or visual bell) when there is nothing more to complete/delete. We could think about introducing that same behavior by lighting up the indicator all-red (similar to on a failed password validation) when pressing backspace at the beginning of the password buffer.

[xtaran]

Hi Michael,

On Wed, Nov 29, 2017 at 12:15:43PM +0000, Michael Stapelberg wrote:

I just did some more tests on i3lock 2.9. Turns out pressing backspace doesn’t result in the indicator showing up (I had previously assumed it would).

It does, but only if something had been typed before. I primarily relied on Ctrl-U anyway.

One more detail on why I'm so used to it and need a no-op indicator so often:

I do have a KVM switch which seems to temporarily disconnect the USB connection if the connected screen resets its HDMI connection. I have 3 screens connected and two wake up from sleep themselves, but the third one connected to the KVM turns off completely after a while and seems to reset itself once on startup as soon as it sees the HDMI input from the KVM.

So when I turn that screen connected to the KVM on and start typing the password, those keys typed during the reset of the screen get lost. So I usually type Ctrl-U until I see the red indicator re-appearing on the other screens and know that I then can start typing the password without losing single characters.

As mentioned before this worked very well and reliable thanks to the red indicator on Ctrl-U which is now gone.

[stapelberg]

So I usually type Ctrl-U until I see the red indicator re-appearing on the other screens and know that I then can start typing the password without losing single characters.

…but you could also just hit spacebar until the indicator flashes, then C-u, then enter your password, right?

[MichaelStergianis]

If I may weigh in,

I miss the feature in question as well. I formed the habit of beginning my login with escape, as it cleared the input buffer and gave me context for typing that the program was ready. In line with keeping C-u and ESC as synonyms, and keeping their behaviour as the developer desires, would C-g be a amicable solution to this issue? This is the emacs keybinding for escape.

For clarity, the proposed change is that C-g would behave as ESC has in the past.

edit: Introduce monospace

[stapelberg]

I sent PR https://github.com/i3/i3lock/pull/172 to address this by displaying an error message when pressing backspace despite there not being any input to delete.

Users can press backspace to ensure i3lock is ready.

[xtaran]

@stapelberg: Much appreciated, thanks! Backspace is totally fine for me, too.