[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master 29d1c72: Introduce new value t for compilation-
From: |
Alan Mackenzie |
Subject: |
Re: [Emacs-diffs] master 29d1c72: Introduce new value t for compilation-context-lines to eliminate scrolling |
Date: |
Tue, 27 Aug 2019 19:46:27 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Stefan.
On Sun, Aug 25, 2019 at 16:54:27 -0400, Stefan Monnier wrote:
> >> 1- Why `overlay-arrow-overlay` without a `compilation-` prefix?
> > It goes together with overlay-arrow-string, and
> > overlay-arrow-position.
> I can see the logic of the name, but if it's in compile.el it should
> have a `compilation-` prefix, IMO. If you intend it to be a new
> generic feature, then it should not be in compile.el.
OK, I've changed its name to compilation-arrow-overlay (see the patch in
another post just posted).
> >> 2- Why insert a prefix string (an "inserted arrow") instead of using
> >> a "regular overwriting arrow"?
> > Because the overwriting arrow would obliterate the first two characters
> > of the file name. I actually tried this first, and it wasn't
> > satisfactory. This contrasts with another use of the overwriting arrow
> > in edebug, where (usually) only WS gets overwritten, and it is important
> > not to disturb the visible indentation.
> I see. Indeed, I guess most other uses of overlay-arrow will typically
> end up overwriting whitespace whereas in *compilation* the first two
> chars will usually not be whitespace.
> Maybe worth a comment in the code.
Now that I've implemented Eli's suggestion of putting "=>" into a 2
character margin, such a comment doesn't seem needed any more.
[ .... ]
> >> -- Stefan "maybe part of my confusion is that I'm not sufficiently
> >> familiar with the behavior when there's no left-fringe"
> > That behaviour involves scrolling the current line to the top of the
> > buffer, and several years of that had exceeded my irritation
> > threshold. I usually run on a Linux tty, where there's no
> > possibility of a fringe.
> IIUC previously, in the absence of a left-fringe the position of the
> error was indicated by the cursor, right? So your change is to offer
> an option "don't scroll" (or rather, let the redisplay scroll to keep
> point visible but only when needed), and you added to it the
> overlay-arrow-overlay because the cursor was not visible enough?
On emacs -nw in X, the cursor, although barely visible is actually
there. On other terminals, in particular a Linux tty, there is no
indication of the cursor position whatsoever in non-selected windows.
> If so another option might be to replace the scrolling-or-overlayarrow
> with some kind of transient highlighting. Can be annoying as well, tho.
s/w/h. ;-) The transient highlighting would be inadequate. I think
Eli was concerned that there was no durable indication of which error
message was "current". The "=>" in the margin now provides such a
durable indication.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
Re: [Emacs-diffs] master 29d1c72: Introduce new value t for compilation-context-lines to eliminate scrolling, Stefan Monnier, 2019/08/25