emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance degradation from long lines


From: Phil Sainty
Subject: Re: Performance degradation from long lines
Date: Sat, 27 Oct 2018 21:38:37 +1300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 27/10/18 1:48 AM, Stefan Monnier wrote:
> AFAIC putting it in "both" means adding it to emacs.git's master branch
> and using elpa.gnu.org's ability to distribute packages built from the
> their emacs.git source to also make a GNU ELPA package out of it.
> 
> So if it goes to emacs.git, there's no point putting it in elpa.git
> first (and I don't want to have it in both places).

I'm imagining that a version in core for Emacs 27+ might differ slightly
from the GNU ELPA package.

The first thing which springs to mind is `so-long-check-header-modes'
which is a verbatim copy of some code from `set-auto-mode' which I
wasn't able to access the results of otherwise:

http://git.savannah.nongnu.org/cgit/so-long.git/tree/so-long.el?h=641f8eaaa#n464

Adding so-long.el to core would mean we could potentially tweak things
in `set-auto-mode' such that so-long didn't need to duplicate any code;
but that improved version of so-long.el couldn't be used with earlier
versions of Emacs.

In addition to that, I'm uncertain where the current discussions are
going to lead to wrt core improvements, as there are a number of
different ideas being thrown around, and I'm wondering whether we'll
end up amalgamating several things together.

So my current feeling is that I should put the existing version into
elpa.git separate from a core version in emacs.git.  If it transpires
that the core version can also be used as the ELPA version, then it's
probably simple enough to change the ELPA recipe at that time to build
it from the emacs.git source instead?


-Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]