bug#7041: comint seems to truncate from places other than the top

bug#7041: comint seems to truncate from places other than the top

[Reuben Thomas]

If I add comint-truncate-buffer to comint-output-filter-functions, and
set comint-buffer-maximum-size to 1024, then when a term buffer
reaches about that size, and I run a command that produces a lot of
output, then scroll back, some of the output is missing. In other
words, rather than truncate from the top of the buffer, some of the
truncation at least seems to happen much nearer the bottom.

If I remove comint-truncate-buffer from
comint-output-filter-functions, or run a command that produces a lot
of output in a fresh window (so that the number of lines of output
does not exceed comint-buffer-maximum-size) then I do not see this
behaviour, which is why I suspect it is to do with truncation.

-- 
http://rrt.sc3d.org

bug#7041: comint seems to truncate from places other than the top

[Lars Ingebrigtsen]

Reuben Thomas <rrt@sc3d.org> writes:

> If I add comint-truncate-buffer to comint-output-filter-functions, and
> set comint-buffer-maximum-size to 1024, then when a term buffer
> reaches about that size, and I run a command that produces a lot of
> output, then scroll back, some of the output is missing. In other
> words, rather than truncate from the top of the buffer, some of the
> truncation at least seems to happen much nearer the bottom.

(This bug report unfortunately got no response at the time.)

Do you have a step-by-step recipe to reproduce this error, starting from
"emacs -Q"?

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

bug#7041: comint seems to truncate from places other than the top

[Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

On Tue, 8 Dec 2020 at 16:43, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Reuben Thomas <rrt@sc3d.org> writes:
>
> > If I add comint-truncate-buffer to comint-output-filter-functions, and
> > set comint-buffer-maximum-size to 1024, then when a term buffer
> > reaches about that size, and I run a command that produces a lot of
> > output, then scroll back, some of the output is missing. In other
> > words, rather than truncate from the top of the buffer, some of the
> > truncation at least seems to happen much nearer the bottom.
>
> (This bug report unfortunately got no response at the time.)
>
> Do you have a step-by-step recipe to reproduce this error, starting from
> "emacs -Q"?
>

If I try it now, it doesn't seem to truncate the buffer as expected: for
example

emacs -Q
M-: (add-to-list 'comint-output-filter-functions 'comint-truncate-buffer)
M-x term
C-c M-x set-variable comint-buffer-maximum-size 256 ; do this after M-x
term because before comint-buffer-maximum-size is not defined
$ seq 1 1024

The entire output is retained, and not truncated. Truncation seems to
happen at 2048 lines. This does not even correspond to the original value
of the variable (1024).

However, I cannot detect any truncation at the bottom of the output.

If I run C-c M-x comint-truncate-buffer, the buffer is truncated as
expected, to 256 lines.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3425 bytes --]

bug#7041: comint seems to truncate from places other than the top

[Lars Ingebrigtsen]

Reuben Thomas <rrt@sc3d.org> writes:

> If I try it now, it doesn't seem to truncate the buffer as expected: for example
>
> emacs -Q
> M-: (add-to-list 'comint-output-filter-functions 'comint-truncate-buffer)
> M-x term
> C-c M-x set-variable comint-buffer-maximum-size 256 ; do this after M-x term
> because before comint-buffer-maximum-size is not defined
> $ seq 1 1024
>
> The entire output is retained, and not truncated. Truncation seems to happen at
> 2048 lines. This does not even correspond to the original value of the variable
> (1024).

I'm not getting any truncation...  but that variable is about comint
buffers, like in `M-x shell' and the like.  Is term-mode a comint
buffer?  It's not derived from comint-mode, so I'm not sure whether this
is supposed to work there?

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

bug#7041: comint seems to truncate from places other than the top

[Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

On Tue, 8 Dec 2020 at 22:31, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Reuben Thomas <rrt@sc3d.org> writes:
>
> > If I try it now, it doesn't seem to truncate the buffer as expected: for
> example
> >
> > emacs -Q
> > M-: (add-to-list 'comint-output-filter-functions 'comint-truncate-buffer)
> > M-x term
> > C-c M-x set-variable comint-buffer-maximum-size 256 ; do this after M-x
> term
> > because before comint-buffer-maximum-size is not defined
> > $ seq 1 1024
> >
> > The entire output is retained, and not truncated. Truncation seems to
> happen at
> > 2048 lines. This does not even correspond to the original value of the
> variable
> > (1024).
>
> I'm not getting any truncation...  but that variable is about comint
> buffers, like in `M-x shell' and the like.  Is term-mode a comint
> buffer?  It's not derived from comint-mode, so I'm not sure whether this
> is supposed to work there?
>

Ah, that would seem to explain it! Indeed, `term-buffer-maximum-size`
defaults to 2048.

So this bug report is based on a misunderstanding, and you can close it,
sorry!

In investigating, I noticed that the following text in term.el appears to
be out of date:

;; Brief Command Documentation:
… for example:
;; M-s     comint-next-matching-input    Next input that matches ← This is
not true! It is bound to term-next-matching-input.

Is there any point retaining this documentation at the top of the file
where it doesn't appear in the manual or any docstring?

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3215 bytes --]

bug#7041: comint seems to truncate from places other than the top

[Lars Ingebrigtsen]

Reuben Thomas <rrt@sc3d.org> writes:

> So this bug report is based on a misunderstanding, and you can close
> it, sorry!

No problem; I often get confused by which modes are comint modes and
which aren't myself.

> In investigating, I noticed that the following text in term.el appears to be out of
> date:
>
> ;; Brief Command Documentation:
> … for example:
> ;; M-s     comint-next-matching-input    Next input that matches ← This is not true!
> It is bound to term-next-matching-input.
>
> Is there any point retaining this documentation at the top of the file
> where it doesn't appear in the manual or any docstring?

Nope; I've now pushed a fix for this to Emacs 28.

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