GNU bug report logs - #2350
23.0.90; compilation-mode inserts output in the wrong location

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2350 in the body.
You can then email your comments to 2350 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eric Hanchrow <erich <at> cozi.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.90; compilation-mode inserts output in the wrong location
Date: Mon, 16 Feb 2009 16:20:25 -0800

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I started a long-running "compilation" that simply emmitted the time every two seconds:

        M-x compile RET C-a C-k while sleep 2; do date; done RET

I then narrowed the *compilation* buffer to the first few lines:

        C-@ C-u C-n C-u C-n C-x n n

I then sat and watched as the current date got inserted at the end of my
narrowed region.  I'd expected it to be inserted instead at the end of
the buffer, even though that happened to be invisible.

This is arguably not a bug, but the behavior I'd expected is indeed
useful: sometimes when a compilation is running, I want to study just
part of the output, and it's convenient to narrow to just the part I
want.  With the current behavior, though, in order to avoid getting the
*compilation* buffer's lines all mixed up, I must copy the interesting
region to another buffer.

In GNU Emacs 23.0.90.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2009-02-04 on ubuntu-erich
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Compilation

Minor modes in effect:
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-netsplit-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-autojoin-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-services-mode: t
  erc-networks-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-readonly-mode: t
  desktop-save-mode: t
  display-time-mode: t
  global-auto-revert-mode: t
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-e RET ESC p C-b C-b C-b C-b C-b \ n C-f C-f \ n C-e 
RET C-u C-p C-@ ESC C-n ESC w C-x o C-n ESC m ESC C-o 
C-y , C-p C-a C-k C-x C-o C-x C-s C-p ESC m ESC . C-n 
C-n C-n ESC C-f ESC f ESC . C-x o ESC > q ( ) . RET 
C-x k RET ESC x m a k e RET y e s RET C-x o C-u C-@ 
C-x 0 ESC > C-x [ ESC > C-h v C-x [ C-g C-h v C-x [ 
C-g C-g C-h c C-x [ C-x [ C-x ] C-u C-x $ C-x [ C-x 
$ C-x [ C-x ] C-n ESC 0 C-l C-x ] C-p C-x n p ESC < 
C-x 2 C-x o C-v C-u C-x $ C-x 0 C-s n o t SPC t C-n 
C-a C-p C-x $ C-u C-x $ C-n C-n C-n C-n C-n C-n C-n 
C-n C-s k i C-w C-r C-r C-r C-s C-s C-s C-s C-s C-s 
C-s C-s C-s C-a C-u C-@ C-x n p ESC < C-v C-x n w C-x 
n p C-x n w C-c C-k ESC > C-c C-k ESC x w o m a n RET 
y e s RET q ESC x c o m p i l e RET C-a C-k w h i l 
e SPC s l e e p SPC 2 ; SPC d o SPC e c h o SPC ESC 
DEL d a t e ; SPC d o n e RET C-@ C-u C-n C-u C-n C-p 
C-x n n C-x n w ESC > C-g C-c C-k ESC x r e p o r t 
- TAB m e TAB DEL DEL e m TAB RET

Recent messages:
Mark saved where search started
Mark set [2 times]
Compilation interrupt
uncompressing yes.1.gz...done
WoMan formatting buffer...done in 0 seconds
(No files need saving)
Mark activated
Quit
Compilation interrupt
Making completion list...

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eric Hanchrow <erich <at> cozi.com>
Cc: 2350 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
Date: Tue, 17 Feb 2009 11:42:41 -0500

> This is arguably not a bug, but the behavior I'd expected is indeed
> useful: sometimes when a compilation is running, I want to study just
> part of the output, and it's convenient to narrow to just the part I
> want.  With the current behavior, though, in order to avoid getting the
> *compilation* buffer's lines all mixed up, I must copy the interesting
> region to another buffer.

This is a fundamental problem in `narrow': its meaning is ambiguous.
Sometimes it is used to pretend that the buffer is really smaller than
it is, and other times it's used just to "focus" on a subpart.
The implementation (i.e. most of the C and Elisp code) tend to take the
first point of view, but sometimes users intend the other.

Maybe a good way to provide what the user wants is to introduce
a notion of window-local narrowing, or a visual-narrowing.


        Stefan

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard M Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 2350 <at> debbugs.gnu.org
Cc: erich <at> cozi.com, 2350 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2350: 23.0.90;
	compilation-mode inserts output in the wrong location
Date: Wed, 18 Feb 2009 07:09:48 -0500

    This is a fundamental problem in `narrow': its meaning is ambiguous.
    Sometimes it is used to pretend that the buffer is really smaller than
    it is, and other times it's used just to "focus" on a subpart.
    The implementation (i.e. most of the C and Elisp code) tend to take the
    first point of view, but sometimes users intend the other.

While that is true, as a general statement, it is clear what we should
do to fix this problem: Compilation mode should widen temporarily and
insert at the end of the whole buffer.

Rather than using save-restriction, it should preserve point-max
as a count from the beginning (the value of (point-max) itself).

Message #30 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: rms <at> gnu.org
Cc: 2350 <at> debbugs.gnu.org, erich <at> cozi.com, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
Date: Wed, 18 Feb 2009 09:25:59 -0500

>     This is a fundamental problem in `narrow': its meaning is ambiguous.
>     Sometimes it is used to pretend that the buffer is really smaller than
>     it is, and other times it's used just to "focus" on a subpart.
>     The implementation (i.e. most of the C and Elisp code) tend to take the
>     first point of view, but sometimes users intend the other.

> While that is true, as a general statement, it is clear what we should
> do to fix this problem: Compilation mode should widen temporarily and
> insert at the end of the whole buffer.

But what isn't clear is whether it's always the right thing to do: it's
clear in this particular use of narrow, but there might be other uses of
narrow in conjunction with compilation buffers where it would be the
wrong thing to do.


        Stefan

Message #40 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard M Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2350 <at> debbugs.gnu.org, erich <at> cozi.com, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
Date: Wed, 18 Feb 2009 18:05:31 -0500

    But what isn't clear is whether it's always the right thing to do: it's
    clear in this particular use of narrow, but there might be other uses of
    narrow in conjunction with compilation buffers where it would be the
    wrong thing to do.

While I cannot prove a priori that is impossible, I doubt it will
happen.  Where as this case -- user narrowing to exclude some of the
buffer from view -- is clearly going to happen (and not just in this
one case).

So let's make it do the right thing for this kind of narrowing.
If it isn't perfect, it is at least better.


Unless and until we come across a real case

Message #45 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard M Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2350 <at> debbugs.gnu.org, erich <at> cozi.com, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
Date: Wed, 18 Feb 2009 18:05:32 -0500

    But what isn't clear is whether it's always the right thing to do: it's
    clear in this particular use of narrow, but there might be other uses of
    narrow in conjunction with compilation buffers where it would be the
    wrong thing to do.

I looked at the code, and I think it is clear what to do: make sure
that narrowing does not prevent insertion at the specified insertion point.

Does this change make it work?

*** compile.el.~1.486.~	2009-02-17 13:06:13.000000000 -0500
--- compile.el	2009-02-18 12:23:10.000000000 -0500
***************
*** 1733,1741 ****
      (with-current-buffer (process-buffer proc)
        (let ((inhibit-read-only t)
              ;; `save-excursion' doesn't use the right insertion-type for us.
!             (pos (copy-marker (point) t)))
          (unwind-protect
              (progn
                (goto-char (process-mark proc))
                ;; We used to use `insert-before-markers', so that windows with
                ;; point at `process-mark' scroll along with the output, but we
--- 1733,1747 ----
      (with-current-buffer (process-buffer proc)
        (let ((inhibit-read-only t)
              ;; `save-excursion' doesn't use the right insertion-type for us.
!             (pos (copy-marker (point) t))
! 	    (min (point-min-marker))
! 	    (max (point-max-marker)))
          (unwind-protect
              (progn
+ 	      ;; If we are inserting at the end of the visible region,
+ 	      ;; keep the inserted text visible.
+ 	      (set-marker-insertion-type max t)
+ 	      (widen)
                (goto-char (process-mark proc))
                ;; We used to use `insert-before-markers', so that windows with
                ;; point at `process-mark' scroll along with the output, but we
***************
*** 1745,1751 ****
                  (comint-carriage-motion (process-mark proc) (point)))
                (set-marker (process-mark proc) (point))
                (run-hooks 'compilation-filter-hook))
!           (goto-char pos))))))
  
  ;;; test if a buffer is a compilation buffer, assuming we're in the buffer
  (defsubst compilation-buffer-internal-p ()
--- 1751,1760 ----
                  (comint-carriage-motion (process-mark proc) (point)))
                (set-marker (process-mark proc) (point))
                (run-hooks 'compilation-filter-hook))
! 	  (goto-char pos)
!           (narrow-to-region min max)
! 	  (set-marker min nil)
! 	  (set-marker max nil))))))
  
  ;;; test if a buffer is a compilation buffer, assuming we're in the buffer
  (defsubst compilation-buffer-internal-p ()
Unless and until we come across a real case

Message #60 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: rms <at> gnu.org
Cc: 2350 <at> debbugs.gnu.org, erich <at> cozi.com, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
Date: Wed, 18 Feb 2009 18:52:17 -0500

> So let's make it do the right thing for this kind of narrowing.
> If it isn't perfect, it is at least better.

I think this will discourage implementation of a good solution to
this problem.


        Stefan

Message #70 received at 2350 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Richard M Stallman <rms <at> gnu.org>
Cc: 2350 <at> debbugs.gnu.org, erich <at> cozi.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#2350: 23.0.90;
 compilation-mode inserts output in the wrong location
Date: Thu, 21 Jan 2016 19:54:35 +0000

Richard M Stallman <rms <at> gnu.org> writes:

>     But what isn't clear is whether it's always the right thing to do: it's
>     clear in this particular use of narrow, but there might be other uses of
>     narrow in conjunction with compilation buffers where it would be the
>     wrong thing to do.
>
> I looked at the code, and I think it is clear what to do: make sure
> that narrowing does not prevent insertion at the specified insertion point.
>
> Does this change make it work?

<snip diff>

I can't replicate this behaviour in Emacs 25 and the patch provided in
this email was applied in 2009:


commit 0b508a27360a82763d4d7256b4cd526f9d3514aa
Author: Richard M. Stallman <rms <at> gnu.org>
Date:   Mon May 18 16:30:59 2009 +0000

    * progmodes/compile.el (compilation-filter): If inserting at end
    of accessible part of buffer, keep end of output visible.


I believe we can close this bug report.

-- 
Alan Third

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.