Re: [ELPA] New package proposal: visual-path-abbrev.el

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 05 Mar 2019 11:01:04 +0100
> 
> > 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.)
> 
> I'm now using option 1 and set the visual-file-name-abbrev overlay
> property which I'm using to know which overlays are mine to (random)
> instead of just t on the current and the last file name point was one in
> a post-command-hook function.
> 
> That seems to do the trick

I'm glad it worked for you.

> although it's a bit sluggish when, e.g., pressing and holding C-n in
> a *grep* buffer in column 1 (which is probably the worst case).
> 
> I haven't yet debugged what's the slow part but I guess it is the new
> predicate `visual-file-name-abbrev--abbrev-visually-shorter-p' which
> ensures that the abbreviation is only displayed if it is visually
> shorter than the normal file name, i.e., it takes into account the
> current font and the replacement ellipsis.  The standard one … is
> twice as wide as a "normal" character on a non-terminal frame.

It is, of course, best to make functions on post-command-hook as
speedy as possible.  But don't be surprised if you find out that is
not the main reason for the sluggishness: you've just disabled a very
important redisplay optimization, so you should expect some hit on the
responsiveness front.  These optimizations are there for a reason,
even in these days of super-fast CPUs.

> Other than that, do you think it's ok to add this package to ELPA?  If
> so, is the (C) FSF and "This file is part of GNU Emacs" correct for an
> ELPA(-only) package?

I'll let Stefan answer this.  And I believe we have recently started
asking contributors to say explicitly in email or in the file that
they contribute the package to Emacs, for legal purposes.  So please
do.

Thanks.