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

[Tassilo Horn]

Eli Zaretskii <address@hidden> writes:

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

Right.  In my case, I just need that for the optional (but
default-enabled) "display normally if point is on the overlay" feature.
So the post-command-hook function could check if it is enabled and do
nothing if it's not.  Or it could even remove itself from p-c-h.  (But
then, it wouldn't start working in that buffer if the feature was later
enabled (which is just adding a function to a list)).

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

Ok, great.  Then let's hear what he has to say.

Bye,
Tassilo