bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

[jidanni]

(info "(emacs) Single Shell") and
(describe-variable 'shell-command-default-error-buffer)
should mention that the errors accumulate in that buffer, and are not
wiped clean at each new command. Also mention they are separate by
form-feeds (^L).

Also the main reason I'm writing this bug report is currently
     `M-!' and `M-|' insert error output before point in that buffer.
But that often leads to jumbled output. They should always append to the
bottom! Like the view-echo-area-messages *Message* buffer.

Or have a variable for those who for some reason want output at a
different position, but bottom should be the default.
(emacs-snapshot package, version 1:20101120-1)

bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

[Lars Ingebrigtsen]

jidanni@jidanni.org writes:

> (info "(emacs) Single Shell") and
> (describe-variable 'shell-command-default-error-buffer)
> should mention that the errors accumulate in that buffer, and are not
> wiped clean at each new command. Also mention they are separate by
> form-feeds (^L).
>
> Also the main reason I'm writing this bug report is currently
>      `M-!' and `M-|' insert error output before point in that buffer.
> But that often leads to jumbled output. They should always append to the
> bottom! Like the view-echo-area-messages *Message* buffer.

Yes, the output in that buffer as it stands isn't very useful, I think.
However, great care has been taken to try to insert the error message
wherever point is, and restoring the buffer:

                (with-current-buffer (get-buffer-create error-buffer)
                  (let ((pos-from-end (- (point-max) (point))))
                    (or (bobp)
                        (insert "\f\n"))
                    ;; Do no formatting while reading error file,
                    ;; because that can run a shell command, and we
                    ;; don't want that to cause an infinite recursion.
                    (format-insert-file error-file nil)
                    ;; Put point after the inserted errors.
                    (goto-char (- (point-max) pos-from-end)))
                  (display-buffer (current-buffer))))

I looked at the commit history, and it doesn't seem to explain why we
don't just append:

commit cc039f78e544719115e277364378c217156c958f
Author: Karl Heuer <kwzh@gnu.org>
Date:   Mon Mar 1 03:19:32 1999 +0000

    (shell-command-default-error-buffer): Renamed from
    shell-command-on-region-default-error-buffer.
    (shell-command-on-region): Mention in echo area when there
    is some error output.  Mention success or failure, too.
    Accumulate multiple error outputs
    going forward, with formfeed in between.  Display the error buffer
    when we have put something in it.

Does anybody object to rewriting it to just append the error messages to
the end of the buffer?

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

bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 21 Aug 2019 15:05:36 -0700
> Cc: rfrancoise@debian.org, 7513@debbugs.gnu.org
> 
> I looked at the commit history, and it doesn't seem to explain why we
> don't just append:
> 
> commit cc039f78e544719115e277364378c217156c958f
> Author: Karl Heuer <kwzh@gnu.org>
> Date:   Mon Mar 1 03:19:32 1999 +0000
> 
>     (shell-command-default-error-buffer): Renamed from
>     shell-command-on-region-default-error-buffer.
>     (shell-command-on-region): Mention in echo area when there
>     is some error output.  Mention success or failure, too.
>     Accumulate multiple error outputs
>     going forward, with formfeed in between.  Display the error buffer
>     when we have put something in it.
> 
> Does anybody object to rewriting it to just append the error messages to
> the end of the buffer?

I'm not sure I understand: you want to lose the ^L separators?  Or
something else?

bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Does anybody object to rewriting it to just append the error messages to
>> the end of the buffer?

EZ> I'm not sure I understand: you want to lose the ^L separators?  Or
EZ> something else?

Keep the ^L separators,
just make sure to *append to the end*!

bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure I understand: you want to lose the ^L separators?  Or
> something else?

Keep the ^L separators, but add the output at end-of-buffer instead of
at point, which it currently does.

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

bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  rfrancoise@debian.org,  7513@debbugs.gnu.org
> Date: Fri, 23 Aug 2019 02:14:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure I understand: you want to lose the ^L separators?  Or
> > something else?
> 
> Keep the ^L separators, but add the output at end-of-buffer instead of
> at point, which it currently does.

So all you need to do is move point to EOB before adding the next
error?  If so, that's fine with me, and probably something that was
just missed, assuming point will never move from there anyway.

bug#7513: 24.0.50; shell-command-default-error-buffer should always append to the bottom

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So all you need to do is move point to EOB before adding the next
> error?  If so, that's fine with me, and probably something that was
> just missed, assuming point will never move from there anyway.

It doesn't seem like an oversight -- there's code to restore point
(approximately) after inserting, so I think it's more of a misfeature of
a kind.

But I've now made it put the output at the end of the buffer, because
that's way more logical.

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