[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39067: closed (shell-command-dont-erase-buffer strange behaviour)

From: GNU bug Tracking System
Subject: bug#39067: closed (shell-command-dont-erase-buffer strange behaviour)
Date: Sun, 19 Jan 2020 10:20:01 +0000

Your message dated Sun, 19 Jan 2020 11:19:19 +0100
with message-id <address@hidden>
and subject line Re: bug#39067: shell-command-dont-erase-buffer strange 
has caused the debbugs.gnu.org bug report #39067,
regarding shell-command-dont-erase-buffer strange behaviour
to be marked as done.

(If you believe you have received this mail in error, please contact

39067: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39067
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: shell-command-dont-erase-buffer strange behaviour Date: Fri, 10 Jan 2020 05:34:18 +0000
C-h v shell-command-dont-erase-buffer
C-h f shell-command

Cut to the chase with the test case:

(let ((shell-command-dont-erase-buffer 'beg-last-out))
  (with-current-buffer (get-buffer-create "OUT")
    (shell-command "/bin/echo FOO" t)
    (shell-command "/bin/echo FOO" t)))

The result (as expected) is a buffer named OUT with 2 lines FOO.
The same result is expected with the following code:

(let ((shell-command-dont-erase-buffer 'beg-last-out))
  (with-current-buffer (get-buffer-create "OUT")
    (shell-command "/bin/echo FOO" "OUT")
    (shell-command "/bin/echo FOO" "OUT")))

However in this case (and in some other cases) shell-command erases the
"OUT" buffer despite a non-NIL binding of

(at least since emacs 25.2)

--- End Message ---
--- Begin Message --- Subject: Re: bug#39067: shell-command-dont-erase-buffer strange behaviour Date: Sun, 19 Jan 2020 11:19:19 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Michael Albinus <address@hidden> writes:

Fixed the bug into emacs-27 branch with commit:
'Fix shell-command-dont-erase-buffer feature'

> I haven't tested yet, but some minor nits:
Thank Michael for the corrections!  I have added then but this one:

> ;; successive commands know the position where the new command starts.
>> +          ;; (unless (and pos (memq sym '(save-point beg-last-out)))
> This is superfluous, isn't it?
That is requred for a corner case: one of the new tests fails if I
remove that.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]