bug#15494: [PATCH] 24.3.50; Processes running under TRAMP can't cleanly write to the middle of a buffer

[Lars Ingebrigtsen]

Dima Kogan <dima@secretsauce.net> writes:

> Hi.
>
> I am observing that processes running over TRAMP overwrite all the
> buffer contents after (point). This is irrelevant in the usual case
> where the process output is going to the end of the buffer (there's
> nothing after the point in that case). This is also something that works
> fine with local (i.e. non-TRAMP) processes.
>
> To be clear, an example emacs invocation appears below. This populates
> the *scratch* buffer with
>
> a b c
> 1 2 3
>
> Then moves the point to the begging of the "1 2 3" line, and runs a
> TRAMP process to insert the text "inserted". I would expect the
> *scratch* buffer to end up with
>
> a b c
> inserted
> 1 2 3
>
> If the process runs without TRAMP, this is indeed what happens. With
> TRAMP, however, I get
>
> a b c
> inserted
>
> Note that with TRAMP the "1 2 3" line got deleted. The example invocation:
>
>  $ emacs -Q \
>    --eval \
>  '(defun test-filter(process output)
>          (with-current-buffer (process-buffer process) (insert output)))' \
>    --eval \
>  '(defun test-sentinel(process event)
>          )' \
>    --eval \
>  '(progn
>     (insert "a b c\n1 2 3\n")
>     (forward-line -1)
>     (cd "/sudo::/tmp")
>     (let ((process (start-file-process "echo" (get-buffer "*scratch*") "echo" 
> "inserted")))
>       (set-process-sentinel process `test-sentinel)
>       (set-process-filter   process `test-filter)))'
>
> This creates a process filter that simply inserts the process output,
> and a sentinel that does nothing. The (cd "/sudo::/tmp") form is there
> to force the process to run with TRAMP. Every TRAMP-based path I've
> tried tickles this bug for me. Removing that form makes the process run
> without TRAMP, and I do not see the buggy behavior then.
>
> I'm observing this issue with the latest emacs24 release and with the
> latest emacs built from the sources as of 2013/09/30. Emacs 23.4.1
> appears to NOT have this bug. This is on a machine running Debian.
>
> I'm attaching a patch that fixes this issue for me. The cause appears to
> be a bit of code that deletes the system prompt from the TRAMP output.
> There's a bug in that code that deletes more than just the prompt in the
> case described above.

The patch makes sense to me.  Michael?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no