bug#32537: 26.1.50; Tramp: Cursor jumps when typing during asynchronous find-file

[Eli Zaretskii <eliz@gnu.org>]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: 32537@debbugs.gnu.org
> Date: Tue, 28 Aug 2018 12:48:28 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I guess some code in the background thread calls a yielding function
> > inside save-excursion or something?  I'd try running with a breakpoint
> > in set_point_both and temp_set_point_both, with commands that show the
> > backtrace and immediately continue the program.  Then you might see
> > the culprit.
> 
> Here is an excerpt from my gdb output from following your instructions.
> (I made the breakpoints conditional on the buffer being *scratch*.)

Thanks.

> It looks like your guess is correct, since there is a save-excursion
> in tramp-sh-handle-file-attributes wrapping code that executes
> commands on the remote machine.

Hmm... does that mean tramp-sh-handle-file-attributes runs with
*scratch* is its current buffer?  It was *scratch* that you were
typing into when this point jumps happened, right?  It's strange that
Tramp uses the current buffer for its processing, but Michael should
know.

If tramp-sh-handle-file-attributes is not using *scratch*, then we'll
need to find some other code in the functions run in backtrace that
does.

> Thread 1 "find-file /scp:" hit Breakpoint 4, set_point_both (charpos=195, 
>     bytepos=195) at intervals.c:1826
> 1826	{
> "electric-indent-post-self-insert-function" (0xf9420)
> "self-insert-command" (0xf9620)
> "funcall-interactively" (0xf9618)
> "call-interactively" (0xf98f0)
> "command-execute" (0xf9c08)

Wait a minute, why does self-insert-command run in a non-main thread?
Could it be that somehow a non-main thread started receiving and
interpreting your keyboard input?  (The "find-file /scp:" thread is
not the main thread, right?)