all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 29d1c72: Introduce new value t for compilation-context-lines to eliminate scrolling
Date: Sun, 25 Aug 2019 16:54:27 -0400	[thread overview]
Message-ID: <jwv8srhq8mu.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20190825190637.GE4724@ACM> (Alan Mackenzie's message of "Sun, 25 Aug 2019 19:06:37 +0000")

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

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

>> 3- Why link the choice of inserted-arrow vs regular-overwriting-arrow to
>>    compilation-context-lines specifically?
> Simplicity: mainly confusion on my part as just to where all the bits of
> the new code would have to go if the "insertion" arrow were to be made a
> general feature.  If the new mechanism is a success, it should be easier
> then to make it more general.

Fair enough.

>> -- 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?

If so another option might be to replace the scrolling-or-overlayarrow
with some kind of transient highlighting.  Can be annoying as well, tho.


        Stefan




  parent reply	other threads:[~2019-08-25 20:54 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 [this message]
2019-08-27 19:46         ` Alan Mackenzie
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

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

  git send-email \
    --in-reply-to=jwv8srhq8mu.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.