unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <20190827194627.GB20676@ACM> (raw)
In-Reply-To: <jwv8srhq8mu.fsf-monnier+emacs@gnu.org>

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	other threads:[~2019-08-27 19:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190825102322.19558.22771@vcs0.savannah.gnu.org>
     [not found] ` <20190825102323.5080620CD5@vcs0.savannah.gnu.org>
2019-08-25 18:39   ` [Emacs-diffs] master 29d1c72: Introduce new value t for compilation-context-lines to eliminate scrolling Stefan Monnier
2019-08-25 19:06     ` Alan Mackenzie
2019-08-25 19:37       ` Eli Zaretskii
2019-08-26 16:26         ` Alan Mackenzie
2019-08-26 16:29           ` Eli Zaretskii
2019-08-27 20:05             ` Alan Mackenzie
2019-08-29 18:22               ` Eli Zaretskii
2019-08-31 10:53                 ` Alan Mackenzie
2019-08-31 11:06                   ` Eli Zaretskii
2019-09-02 19:34                     ` Alan Mackenzie
2019-09-03  2:25                       ` Eli Zaretskii
2019-09-08  9:41                     ` Margins example in the Elisp manual. [Was: [Emacs-diffs] master 29d1c72: Introduce new value t for compilation-context-lines to eliminate scrolling] Alan Mackenzie
2019-09-08 17:06                       ` Eli Zaretskii
2019-08-27 19:36         ` [Emacs-diffs] master 29d1c72: Introduce new value t for compilation-context-lines to eliminate scrolling Alan Mackenzie
2019-08-27 19:49           ` Eli Zaretskii
2019-08-27 20:07             ` Stefan Monnier
2019-08-27 19:59           ` Stefan Monnier
2019-08-31 11:31             ` Alan Mackenzie
2019-08-31 12:07               ` martin rudalics
2019-08-31 12:45                 ` Alan Mackenzie
2019-08-25 20:54       ` Stefan Monnier
2019-08-27 19:46         ` Alan Mackenzie [this message]
2019-08-27 20:05           ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190827194627.GB20676@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).