* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
@ 2009-02-17 0:20 Eric Hanchrow
2009-02-17 16:42 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Eric Hanchrow @ 2009-02-17 0:20 UTC (permalink / raw
To: emacs-pretest-bug
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...
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
2009-02-17 0:20 bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Eric Hanchrow
@ 2009-02-17 16:42 ` Stefan Monnier
2009-02-18 12:09 ` Richard M Stallman
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2009-02-17 16:42 UTC (permalink / raw
To: Eric Hanchrow; +Cc: 2350, emacs-pretest-bug
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
2009-02-17 16:42 ` Stefan Monnier
@ 2009-02-18 12:09 ` Richard M Stallman
2009-02-18 14:25 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Richard M Stallman @ 2009-02-18 12:09 UTC (permalink / raw
To: Stefan Monnier, 2350; +Cc: 2350, emacs-pretest-bug, erich
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).
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
2009-02-18 12:09 ` Richard M Stallman
@ 2009-02-18 14:25 ` Stefan Monnier
2009-02-18 23:05 ` Richard M Stallman
2009-02-18 23:05 ` Richard M Stallman
0 siblings, 2 replies; 8+ messages in thread
From: Stefan Monnier @ 2009-02-18 14:25 UTC (permalink / raw
To: rms; +Cc: 2350, emacs-pretest-bug, erich
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
2009-02-18 14:25 ` Stefan Monnier
@ 2009-02-18 23:05 ` Richard M Stallman
2009-02-18 23:52 ` Stefan Monnier
2009-02-18 23:05 ` Richard M Stallman
1 sibling, 1 reply; 8+ messages in thread
From: Richard M Stallman @ 2009-02-18 23:05 UTC (permalink / raw
To: Stefan Monnier; +Cc: 2350, emacs-pretest-bug, erich
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
2009-02-18 14:25 ` Stefan Monnier
2009-02-18 23:05 ` Richard M Stallman
@ 2009-02-18 23:05 ` Richard M Stallman
2016-01-21 19:54 ` Alan Third
1 sibling, 1 reply; 8+ messages in thread
From: Richard M Stallman @ 2009-02-18 23:05 UTC (permalink / raw
To: Stefan Monnier; +Cc: 2350, emacs-pretest-bug, erich
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
2009-02-18 23:05 ` Richard M Stallman
@ 2009-02-18 23:52 ` Stefan Monnier
0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2009-02-18 23:52 UTC (permalink / raw
To: rms; +Cc: 2350, emacs-pretest-bug, erich
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#2350: 23.0.90; compilation-mode inserts output in the wrong location
2009-02-18 23:05 ` Richard M Stallman
@ 2016-01-21 19:54 ` Alan Third
0 siblings, 0 replies; 8+ messages in thread
From: Alan Third @ 2016-01-21 19:54 UTC (permalink / raw
To: Richard M Stallman; +Cc: 2350, erich, Stefan Monnier
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-01-21 19:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-17 0:20 bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Eric Hanchrow
2009-02-17 16:42 ` Stefan Monnier
2009-02-18 12:09 ` Richard M Stallman
2009-02-18 14:25 ` Stefan Monnier
2009-02-18 23:05 ` Richard M Stallman
2009-02-18 23:52 ` Stefan Monnier
2009-02-18 23:05 ` Richard M Stallman
2016-01-21 19:54 ` Alan Third
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.