Re: Overlay arrow in *compilation* and *grep* buffers

[Nick Roberts]

 > I suggest adding a new option defining how to highlight lines
 > in compilation/grep buffers, similar to `next-error-highlight'
 > which defines highlighting in source buffers.  It will replace
 > `compilation-context-lines':
 > 
 > (defcustom compilation-message-highlight 0
 >   "*Highlighting of locations in the compilation buffer.
 > If number, display this many lines of leading context before message.
 > If t, use persistent overlays fontified in next-error face.
 > If nil, don't highlight the locus in the compilation buffer.
 > If `fringe-arrow', indicate the locus by the fringe arrow."
 >   :type '(choice (number :tag "Context lines")
 >                  (const :tag "Persistent overlay" t)
 >                  (const :tag "No highlighting" nil)
 >                  (const :tag "Fringe arrow" 'fringe-arrow))
 >   :group 'compilation
 >   :version "22.1")
 > 
 > Since the number of context lines and fringe arrow are mutually exclusive
 > values, there will be no problem with an arrow overlapping a file name
 > in the compilation buffer, because by default there will be no arrow at all.
 > Users wishing to use arrows can set `compilation-message-highlight' to
 > `fringe-arrow' in .emacs conditionally depending on the presence of fringes.

I don't like this change because its not the case that one user wants an arrow
and another doesn't but rather one context may benefit from an arrow
(graphical display) while another may not (text terminal).

Previously I have suggested a change that gives compilation-context-lines a
context dependent values so that the error scrolls to the top of the window on
a text terminal. This or a similar change could be generalised to the case of
no left-fringe which I think could be tested by:

(if (or (not (display-graphic-p))
        (equal fringe-mode 0)
        (equal (car fringe-mode) 0))...

 > BTW, I don't understand the reason of adding `(defvar
 > next-error-highlight-timer)' to compile.el on 2005-04-23.  There is already
 > the same defvar in simple.el.

I would guess this was to remove a compile error. I don't think Richard
realised that the next-error code was defined in simple.el.

Nick