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

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: 32537@debbugs.gnu.org
> Date: Fri, 31 Aug 2018 09:52:45 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But I still am not sure whether this is our villain.
> > Does buffer position 146 sound correct wrt what you see in *scratch*,
> > i.e. is it the position where point jumps?  Also, please add to the
> > breakpoint commands the command to display the current buffer:
> >
> >    pp current_buffer->name_
> >
> > Thanks.
> 
> The case against our suspect keeps getting stronger.  The following is
> an excerpt from a gdb session where I added to the breakpoint commands
> printing the current buffer name and single-line C-level backtraces of
> the threads when the main thread is current.  I also verified that the
> position and distance that point jumped matched what I saw in *scratch*.
> [...]
> Thread 10 "find-file-nosel" hit Breakpoint 5, set_point_both (charpos=256, 
>     bytepos=256) at intervals.c:1826
> 1826  {
> $380 = (struct thread_state *) 0x38b3c80
> "*scratch*"
> "tramp-sh-handle-file-attributes" (0xd97f36e8)
> "apply" (0xd97f36e0)
> "tramp-sh-file-name-handler" (0xd97f3ac0)
> "apply" (0xd97f3ab8)
> "tramp-file-name-handler" (0xd97f49f8)
> "file-attributes" (0xd97f4b28)
> "tramp-handle-file-symlink-p" (0xd97f4e58)
> "apply" (0xd97f4e50)
> "tramp-sh-file-name-handler" (0xd97f5230)
> "apply" (0xd97f5228)
> "tramp-file-name-handler" (0xd97f6168)
> "file-symlink-p" (0xd97f6310)
> "tramp-sh-handle-file-truename" (0xd97f7be8)
> "apply" (0xd97f7be0)
> "tramp-sh-file-name-handler" (0xd97f7fc0)
> "apply" (0xd97f7fb8)
> "tramp-file-name-handler" (0xd97f8f28)
> "file-truename" (0xd97f9308)
> "find-file-noselect" (0xd97f9870)
> 0x38b0f10 PVEC_COMPILED
> 
> Thread 10 (Thread 0x7fffd97fa700 (LWP 15844)):
> #0  set_point_both (charpos=256, bytepos=256) at intervals.c:1826
> #1  0x0000000000631896 in set_point_from_marker (marker=...) at 
> intervals.c:1771
> #2  0x00000000005b82d5 in Fgoto_char (position=..., 
> position@entry=XIL(0x7fffc000f4f5)) at editfns.c:423
> #3  0x00000000005c2dc0 in save_excursion_restore (marker=XIL(0x7fffc000f4f5), 
> window=...) at editfns.c:1023
> #4  0x00000000005c9309 in unbind_to (count=<optimized out>, value=..., 
> value@entry=XIL(0)) at eval.c:3593

OK, but this sounds strange to me, since AFAICT Tramp switches to its
own buffer when it sends a script to the remote and waits for it to
return the results (which is most probably when the main thread gets
control and lets you type).

Michael, how come Tramp moves point in the *scratch* buffer in this
scenario?

Thanks.