all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Tassilo Horn <tsdh@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [ELPA] New package proposal: visual-path-abbrev.el
Date: Mon, 04 Mar 2019 20:03:40 +0200	[thread overview]
Message-ID: <83h8ciecub.fsf@gnu.org> (raw)
In-Reply-To: <87k1hg6jl3.fsf@gnu.org> (message from Tassilo Horn on Sun, 03 Mar 2019 16:52:56 +0100)

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 03 Mar 2019 16:52:56 +0100
> 
> 1. emacs -Q
> 2. M-x load-file RET visual-file-name-abbrev.el RET
> 3. M-x rgrep RET (defsubst RET *.el RET ~/Repos/el/emacs
> 4. In the *grep* buffer: M-x visual-file-name-abbrev-mode
> 
> As a result, the file names are indeed abbreviated but when I move up
> and down using C-n/C-p, I'd expect the file name under point to be
> displayed normally (so not the 'display spec but the normal text).  With
> emacs -Q, the problem is even worse than with my usual config.  It seems
> the conditional display spec is almost never tested, except when the
> window is scrolled, but then usually after scrolling point is not on the
> file name anymore which is now shown unabbreviated.

Yes, this feature is somewhat tricky to use.  The basic problem here
is that CONDITION is only evaluated when redisplay examines the text
on which you put this display spec, because only then the display
engine bumps into this spec.  And redisplay is extremely conservative
in what portions of text it examines, because doing so is generally
expensive, and makes Emacs less responsive.  So redisplay is full of
shortcuts and optimizations meant to avoid examining portions of text
where no changes are expected.

For your feature to work reliably, you need one or more overlays
examined even if the user just moves point, something that triggers a
heavily optimized version of redisplay (because moving point is a very
frequent operation).  You need to disable some of these optimizations.

One way of disabling those optimizations is to make some immaterial
change in one or more overlays, because overlay changes cause a more
thorough redisplay of the buffer.  You can, for example, change some
overlay property that will have no effect on display.

Another possibility is to have a buffer-local variable that you add to
the list of variables which trigger thorough redisplay of its buffer,
see the end of frame.el for how this is done.  Then whenever you want
redisplay to re-evaluate one or more of your overlays, you change the
value of that variable.

Both of those techniques will need to use post-command-hook, I think.

Caveat: I didn't try any of my suggestions, so I cannot be sure they
will work, although they should, of course.  (I did add the above
caveats to the ELisp manual, so they are now documented.)



  parent reply	other threads:[~2019-03-04 18:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-02 11:05 [ELPA] New package proposal: visual-path-abbrev.el Tassilo Horn
2019-03-02 11:34 ` Eli Zaretskii
2019-03-02 14:59   ` Tassilo Horn
2019-03-03  9:46   ` Tassilo Horn
2019-03-03 13:48     ` Stefan Monnier
2019-03-03 15:11     ` Eli Zaretskii
2019-03-03 15:52       ` Tassilo Horn
2019-03-03 17:18         ` Eli Zaretskii
2019-03-03 17:55           ` Tassilo Horn
2019-03-04 18:03         ` Eli Zaretskii [this message]
2019-03-05 10:01           ` Tassilo Horn
2019-03-05 16:21             ` Eli Zaretskii
2019-03-05 18:32               ` Tassilo Horn
2019-03-08  5:49             ` Stefan Monnier
2019-03-08 14:02               ` Tassilo Horn
2019-03-08 17:34                 ` Tassilo Horn
2019-03-08 19:01                   ` Stefan Monnier
2019-03-08 22:18                     ` Stefan Monnier
2019-03-09  6:52                       ` Tassilo Horn
2019-03-08 18:52                 ` Stefan Monnier
2019-03-02 21:25 ` Leo Liu
2019-03-03  9:25   ` Tassilo Horn
2019-03-04  0:23     ` Leo Liu

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=83h8ciecub.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=tsdh@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.