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

[Michael Albinus]

Dima Kogan <dima@secretsauce.net> writes:

> Hi.

Hi Dima,

> From what I see, the rendering is dependent on what the window
> manager does. If you switch to another window to cover up emacs, and
> switch back, is there a redraw? I'm observing no redraw, and that's a
> problem: emacs is frozen, and I don't see the prompt text in the
> minibuffer. Sometimes due to WM quirks I never see the prompt. emacs
> should give control back to the main loop while it waits for user
> interaction (i.e. exactly what it does when asking for the passphrase).

It seems to depend on the window manager, indeed. Running "emacs -Q", I
always see the whole rendered Emacs, including the message in the echo
area. Whether I move another window on top on Emacs, and move it away
afterwards, doesn't matter.

I'm running Fedora 34 with gdm (GNOME) 40.1.

> I realize this might not be a simple thing to implement. Would it be
> simple to wait for keyboard input OR the yubikey touch, whichever comes
> first? If so, we can ask the user to "touch yubikey, or press enter to
> quit". Then the same console input code used for the passphrase input
> could be utilized here.

Not so simple to implement. We have the ssh security key message, which
must be displayed.

I've adapted the code slightly, so it doesn't wait 30 sec for the
confirmation message to appear from ssh. Instead there is a loop, which
waits for 0.1 sec, checks for the message, and calls (redisplay) if it
didn't appear.

Pushed to master. Does it make a difference for you?

> Thanks!

Best regards, Michael.