all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#7041: comint seems to truncate from places other than the top
@ 2010-09-16 11:42 Reuben Thomas
  2020-12-08 16:42 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Reuben Thomas @ 2010-09-16 11:42 UTC (permalink / raw)
  To: 7041

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7041: comint seems to truncate from places other than the top
  2010-09-16 11:42 bug#7041: comint seems to truncate from places other than the top Reuben Thomas
@ 2020-12-08 16:42 ` Lars Ingebrigtsen
  2020-12-08 19:18   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-08 16:42 UTC (permalink / raw)
  To: Reuben Thomas; +Cc: 7041

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7041: comint seems to truncate from places other than the top
  2020-12-08 16:42 ` Lars Ingebrigtsen
@ 2020-12-08 19:18   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2020-12-08 22:31     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-12-08 19:18 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 7041

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7041: comint seems to truncate from places other than the top
  2020-12-08 19:18   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-12-08 22:31     ` Lars Ingebrigtsen
  2020-12-08 22:37       ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-08 22:31 UTC (permalink / raw)
  To: Reuben Thomas; +Cc: 7041

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7041: comint seems to truncate from places other than the top
  2020-12-08 22:31     ` Lars Ingebrigtsen
@ 2020-12-08 22:37       ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2020-12-08 22:42         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-12-08 22:37 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 7041

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7041: comint seems to truncate from places other than the top
  2020-12-08 22:37       ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-12-08 22:42         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-08 22:42 UTC (permalink / raw)
  To: Reuben Thomas; +Cc: 7041

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-12-08 22:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-16 11:42 bug#7041: comint seems to truncate from places other than the top Reuben Thomas
2020-12-08 16:42 ` Lars Ingebrigtsen
2020-12-08 19:18   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-08 22:31     ` Lars Ingebrigtsen
2020-12-08 22:37       ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-08 22:42         ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.