new compile command brokeness

new compile command brokeness

[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'.

The actual *Messages* output looks like:

Fontifying *compilation*... (regexps........................................)
compilation-next-error: Moved past last error

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.

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

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: new compile command brokeness

[Daniel Pfeiffer]

Saluton,

Miles Bader <miles@lsi.nec.co.jp> skribis:

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

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

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

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

P.S.: gnu.org is bouncing my mails.  If this doesn't show up on the list,
could you please forward it?

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command brokeness

[Stefan Monnier]

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

Re: new compile command brokeness

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

Re: new compile command brokeness

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Maybe we could use an overlay arrow to make it stand out.

This could be done with the new overlay-arrow-variable-list functionality.