bug#49714: 28.0.50; TRAMP burns CPU and has insufficient user reporting when using xxxx-sk SSH keys

[Michael Albinus <michael.albinus@gmx.de>]

Dima Kogan <dima@secretsauce.net> writes:

Hi Dima,

>> Well, while you see the message, Tramp is looping with
>> accept-process-output in order to check, whether the yubikey has been
>> pressed. This is not different from everything else Tramp does, until
>> the remote shell prompt has been detected. So I don't see what we
>> could do otherwise ...
>
> I understand this argument. However, as a user, I would fully expect
> emacs to behave the same way while it's waiting for the passphrase as it
> does when waiting for me to touch the yubikey. Currently the passphrase
> input stage feels normal, while the wait-for-touch stage feels frozen.
> On a deeper level, in both cases we're waiting for some specific data to
> come from an OS file descriptor: either something ultimately connected
> to the keyboard, or the ssh process. Maybe this isn't worth the effort
> to fix, but it is a problem.

I couldn't resist, so I've played with my new yubikey. When it shows the
confirmation request

- I cannot reproduce that the mode line does not render. I've added a
  (redisplay) (due to another problem I've experienced locally), maybe
  this makes it better

- Yes, Emacs is kind of frozen while you see the message. Simply, you
  have to touch the yubikey. What other action do you expect from Emacs?
  It is the same behavior as you see when you have given the
  password/passphrase, and Tramp waits for the shell prompt. There's
  nothing to interact with Emacs during this time.

I've just pushed some cleanups to master, could you pls (re-)check? What
else do you expect from Tramp?

Best regards, Michael.