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>]

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

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?

Is there anything else I could do for you? Otherwise, I'd like to close
the bug report.

>> Thanks!

Best regards, Michael.