* Re: new compile command brokeness
2004-03-17 20:45 ` Daniel Pfeiffer
@ 2004-03-17 21:40 ` Stefan Monnier
2004-03-17 23:12 ` Kim F. Storm
2004-03-17 22:42 ` Miles Bader
1 sibling, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2004-03-17 21:40 UTC (permalink / raw)
Cc: miles, emacs-devel, Miles Bader
>> When I do `M-x compile RET', type make, and get a bunch of errors, and
>> then try `M-x next-error', it doesn't work, and instead just says
>> `Moved past last error'.
> Aha, that's a consequence of scrolling along with the output as it pours in,
> unless you move the cursor. The (point) in the *compilation* buffer serves as
> the indication where the 'current' error is. The next one will be found from
> there onwards. Four possibilities:
> - not scroll along but stay at the beginning (not so nice)
> - keep a marker to the next position (strange to not find the next error where
> the cursor is, though)
> - remember (or check) that we haven't visited an error from this buffer, and
> only in that case jump to the beginning
> - generally wrap around to the begining if any errors were skipped, and only
> signal this error if none are left (seems the most useful and consistent
> solution :-)
I'd vote for reproducing the old behavior which seems to work fairly well.
See attached patch.
The reason why point is not sufficient is for things like TeX and other
comint modes: point will necessarily be at the end of buffer most of the
time and wrapping around to the beginning of the buffer doesn't make much
sense: you need to start from the last command rather than from point-min.
tex-mode (and sml-mode which faced the same issue) solved it by setting
compilation-parsing-end to point-max right before sending a new command to
the underlying process.
>> BTW another point I noticed is that while the old compile command
>> caused the `current error' (the error last selected by next-error)
>> to be the top-line in the *compilation* window, the new one doesn't,
>> making it something like the 3rd line or so.
> compilation-context-lines defaults to next-screen-context-lines, so as to
> be consistent with normal scrolling. For some messages a few preceding
> lines are helpful for understanding.
I think the idea is good (I've been annoyed at the lack of context with the
old compile.el). But I agree that we need to find a way to make the line
stand out more, (maybe by making the context-lines dimmer?).
>> This makes which error is current much harder to see; if it's desirable
>> to not use the top of the window (maybe to see more context?), then
>> I think the current error should be highlighted or something.
> That could be done, but not urgently. I suppose people will just get used
> to this, like they are to the scrolling overlap.
I find it's not just a question of habit. The cursor is an empty box, so
it's not too visible and it's all we have to find the relevant line.
> P.S.: gnu.org is bouncing my mails. If this doesn't show up on the list,
> could you please forward it?
I received it,
Stefan
--- orig/lisp/progmodes/compile.el
+++ mod/lisp/progmodes/compile.el
@@ -138,6 +138,9 @@
(setq minor-mode-alist (cons '(compilation-in-progress " Compiling")
minor-mode-alist)))
+(defvar compilation-parsing-end nil
+ "Marker position of end of buffer when last error messages were parsed.")
+
(defvar compilation-error "error"
"Stem of message to print when no matches are found.")
@@ -1083,6 +1086,7 @@
"Prepare the buffer for the compilation parsing commands to work."
(make-local-variable 'compilation-error-screen-columns)
(setq compilation-last-buffer (current-buffer))
+ (set (make-local-variable 'compilation-parsing-end) (point-min-marker))
(if minor
(if font-lock-defaults
(font-lock-add-keywords nil (compilation-mode-font-lock-keywords))
@@ -1202,12 +1206,13 @@
"Process filter for compilation buffers.
Just inserts the text, but uses `insert-before-markers'."
(if (buffer-name (process-buffer proc))
- (save-excursion
- (set-buffer (process-buffer proc))
- (let ((buffer-read-only nil))
+ (with-current-buffer (process-buffer proc)
+ (let ((inhibit-read-only t)
+ (end (marker-position compilation-parsing-end)))
(save-excursion
(goto-char (process-mark proc))
(insert-before-markers string)
+ (set-marker compilation-parsing-end end) ;Don't move it!
(run-hooks 'compilation-filter-hook))))))
(defsubst compilation-buffer-p (buffer)
@@ -1270,7 +1275,7 @@
"Moved past last %s"))
(compilation-loop < previous-single-property-change 1+
"Moved back before first %s"))
- (goto-char pt)
+ (set-marker compilation-parsing-end (goto-char pt))
(or msg
(error "No %s here" compilation-error))))
@@ -1388,6 +1393,7 @@
See variable `compilation-error-regexp-alist' for customization ideas."
(interactive "p")
(set-buffer (setq compilation-last-buffer (compilation-find-buffer)))
+ (goto-char compilation-parsing-end)
(let* ((columns compilation-error-screen-columns) ; buffer's local value
(last 1)
(loc (compilation-next-error n))
@@ -1592,6 +1598,18 @@
(overlays-in (point-min) (point-max)))
buffer)))
+
+;; Set compilation-error-list to nil, and unchain the markers that point to the
+;; error messages and their text, so that they no longer slow down gap motion.
+;; This would happen anyway at the next garbage collection, but it is better to
+;; do it right away.
+(defun compilation-forget-errors ()
+ ;; FIXME: should we do something more like throw away markers
+ ;; and/or force a font-lock refresh?
+ (set-marker compilation-parsing-end (point-min)))
+
+
+
(defun compilation-normalize-filename (filename)
"Convert a filename string found in an error message to make it usable."
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: new compile command brokeness
2004-03-17 20:45 ` Daniel Pfeiffer
2004-03-17 21:40 ` Stefan Monnier
@ 2004-03-17 22:42 ` Miles Bader
1 sibling, 0 replies; 5+ messages in thread
From: Miles Bader @ 2004-03-17 22:42 UTC (permalink / raw)
Cc: miles, emacs-devel, Miles Bader
On Wed, Mar 17, 2004 at 09:45:27PM +0100, Daniel Pfeiffer wrote:
> > If I go to the *compilation* buffer, and use `C-c C-c' on an error
> > line, then that succeeds, and subsequent uses of `next-error' also work
> > properly.
>
> Aha, that's a consequence of scrolling along with the output as it pours
> in, unless you move the cursor. The (point) in the *compilation* buffer
> serves as the indication where the 'current' error is.
>
> - remember (or check) that we haven't visited an error from this buffer,
> and only in that case jump to the beginning
Well I'm not sure about the other solutions, but if it's going to scroll the
output during execution, it certainly ought to do this.
> > BTW another point I noticed is that while the old compile command
> > caused the `current error' (the error last selected by next-error)
> > to be the top-line in the *compilation* window, the new one doesn't,
> > making it something like the 3rd line or so.
>
> compilation-context-lines defaults to next-screen-context-lines, so as to
> be consistent with normal scrolling. For some messages a few preceding
> lines are helpful for understanding.
Sure. But it needs to be indicated visually somehow; simply skipping
next-screen-context-lines from the top of the window is natural for the
computer, but extremely awkward for humans. I gather from your reply that
you sort of intended the cursor to serve this purpose, but in my case, I have
the cursor turned off in inactive windows, even the default hollowed-out
cursor is pretty hard to see.
> > This makes which error is current much harder to see; if it's desirable
> > to not use the top of the window (maybe to see more context?), then I
> > think the current error should be highlighted or something.
>
> That could be done, but not urgently. I suppose people will just get used to
> this, like they are to the scrolling overlap.
No. It's actually a big problem for me -- it's a major pain reorienting my
eye after each next-error -- even when I'm already looking at the previous
error in the *compile* buffer (and so am looking at about the right place).
-Miles
--
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.' [NYT]
^ permalink raw reply [flat|nested] 5+ messages in thread