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

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

[Dima Kogan]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-TRAMP-processes-no-longer-delete-their-buffer-conten.patch --]
[-- Type: text/x-diff, Size: 1006 bytes --]

From 4af06390facb39fba2d150da296b6ede96c8cef4 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@secretsauce.net>
Date: Mon, 30 Sep 2013 00:30:28 -0700
Subject: [PATCH] TRAMP processes no longer delete their buffer contents after
 (point)

---
 lisp/net/tramp-sh.el | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
index 4bc836b..96cf9d2 100644
--- a/lisp/net/tramp-sh.el
+++ b/lisp/net/tramp-sh.el
@@ -2730,9 +2730,10 @@ the result will be a local, non-Tramp, filename."
 		  ;; We call `tramp-maybe-open-connection', in order
 		  ;; to cleanup the prompt afterwards.
 		  (catch 'suppress
-		    (tramp-maybe-open-connection v)
-		    (widen)
-		    (delete-region mark (point))
+		    (let ((point-prompt-start (point)))
+		      (tramp-maybe-open-connection v)
+		      (widen)
+		      (delete-region point-prompt-start (point)))
 		    (narrow-to-region (point-max) (point-max))
 		    ;; Now do it.
 		    (if command
-- 
1.8.3.2

bug#15494: Improved patch

[Dima Kogan]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

I'm attaching a smaller patch that solves this in a somewhat cleaner
way.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-TRAMP-processes-no-longer-delete-their-buffer-conten.patch --]
[-- Type: text/x-diff, Size: 1177 bytes --]

From 5fd5f6f5fed3d5736c7a4267d2487c2dd2861d08 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@secretsauce.net>
Date: Mon, 30 Sep 2013 00:30:28 -0700
Subject: [PATCH] TRAMP processes no longer delete their buffer contents after
 (point)

---
 lisp/net/tramp-sh.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
index 4bc836b..81f0c97 100644
--- a/lisp/net/tramp-sh.el
+++ b/lisp/net/tramp-sh.el
@@ -2724,7 +2724,7 @@ the result will be a local, non-Tramp, filename."
 		;; `verify-visited-file-modtime'.
 		(let ((buffer-undo-list t)
 		      (buffer-read-only nil)
-		      (mark (point)))
+		      (point-prompt-start (point-max)))
 		  (clear-visited-file-modtime)
 		  (narrow-to-region (point-max) (point-max))
 		  ;; We call `tramp-maybe-open-connection', in order
@@ -2732,7 +2732,7 @@ the result will be a local, non-Tramp, filename."
 		  (catch 'suppress
 		    (tramp-maybe-open-connection v)
 		    (widen)
-		    (delete-region mark (point))
+		    (delete-region point-prompt-start (point))
 		    (narrow-to-region (point-max) (point-max))
 		    ;; Now do it.
 		    (if command
-- 
1.8.3.2

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

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

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi,

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

I'm very sorry, but I've overlooked this bug report completely :-(

Fortunately, there was another bug report #16120, which speaks about the
same problem. And the solution is identical to what Dima proposed. It
was merged into the Emacs sources back in February 2014.

I'm closing this bug.

Best regards, Michael.