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