bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Eric Hanchrow]

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@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...

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Stefan Monnier]

> 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

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Richard M Stallman]

    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).

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Stefan Monnier]

>     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

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Richard M Stallman]

    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

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Stefan Monnier]

> 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

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Richard M Stallman]

    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

bug#2350: 23.0.90; compilation-mode inserts output in the wrong location

[Alan Third]

Richard M Stallman <rms@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@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