emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]