Organizing package.el a bit

Organizing package.el a bit

[Artur Malabarba]

Hi All,
Since last time that I worked a bit on package.el, I noticed it's a
little annoying to manage due to sheer size. I understand 2600 lines
is not the largest .el file we have (hell, it's not even top 10), but
it's enough to bother me a lot.

I'd like to know whether it's ok to split it into two files,
package.el and package-menu.el?

The distinction is very logic, there's a ton of stuff that goes on in
package.el which doesn't make any use of the package-menu.
The only downside of this refactoring would be to mess up things like
`git-blame`, and that's why I'm askinghere.

Is that a reason not to do it?

Cheers
Artur

Re: Organizing package.el a bit

[Stefan Monnier]

> Since last time that I worked a bit on package.el, I noticed it's a
> little annoying to manage due to sheer size. I understand 2600 lines
> is not the largest .el file we have (hell, it's not even top 10), but
> it's enough to bother me a lot.

100KB doesn't bother me: I find it easier to navigate in a single file
than to jump back&forth between two files.

> I'd like to know whether it's ok to split it into two files,
> package.el and package-menu.el?

I could live with it, I guess.  There's another potentially useful split:
package-init.el which would only contain what's needed for
package-initialize (i.e. whatever is needed for a "normal" use of Emacs
that does not involve installing/removing packages).

Could you give us an estimate of the resulting file size(s), to see if
the split would indeed be useful (splitting into 100KB package.el + 10KB
package-menu.el wouldn't be tremendously beneficial, for example).


        Stefan

Re: Organizing package.el a bit

[Artur Malabarba]

> Could you give us an estimate of the resulting file size(s), to see if
> the split would indeed be useful (splitting into 100KB package.el + 10KB
> package-menu.el wouldn't be tremendously beneficial, for example).

Sure. I'll, try tonight.

Re: Organizing package.el a bit

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On second thought. It would be much simpler and just as effective to move
some functions around a bit and divide the file with a few more page
breaks.
On Mar 28, 2015 1:35 PM, "Artur Malabarba" <bruce.connor.am@gmail.com>
wrote:

> > Could you give us an estimate of the resulting file size(s), to see if
> > the split would indeed be useful (splitting into 100KB package.el + 10KB
> > package-menu.el wouldn't be tremendously beneficial, for example).
>
> Sure. I'll, try tonight.
>

[-- Attachment #2: Type: text/html, Size: 766 bytes --]

Re: Organizing package.el a bit

[Oleh Krehel]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> On second thought. It would be much simpler and just as effective to
> move some functions around a bit and divide the file with a few more
> page breaks.

I agree on this one. 3000 lines ins't a lot, especially when you compare
it to 25000 lines of org.el. But org.el is organized nicely with
outlines, instead of page breaks. Maybe you should consider outlines for
package.el as well. Outlines are easy to navigate, fold and narrow into.

Oleh

Re: Organizing package.el a bit

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

> > On second thought. It would be much simpler and just as effective to
> > move some functions around a bit and divide the file with a few more
> > page breaks.
>
> I agree on this one. 3000 lines ins't a lot, especially when you compare
> it to 25000 lines of org.el. But org.el is organized nicely with
> outlines, instead of page breaks. Maybe you should consider outlines for
> package.el as well. Outlines are easy to navigate, fold and narrow into.

Yes, I'll add a comment outline to every page break (as is the usual
style), as well as a short description.

[-- Attachment #2: Type: text/html, Size: 679 bytes --]

Re: Organizing package.el a bit

[Steinar Bang]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com>:

> I'd like to know whether it's ok to split it into two files,
> package.el and package-menu.el?

> The distinction is very logic, there's a ton of stuff that goes on in
> package.el which doesn't make any use of the package-menu.
> The only downside of this refactoring would be to mess up things like
> `git-blame`, and that's why I'm askinghere.

If you do
 cp package.el package-menu.el
 git add package-menu.el
 git commit -m "Copying verbatim to preserve history"

before you start working, and then do your changes by removing stuff
from package-menu.el (and package.el) and not move things around
otherwise, then git-blame should show the correct history.

Re: Organizing package.el a bit

[Artur Malabarba]

I just pushed a proposal for this (using page-breaks, not separate
files) into scratch/organizing-package.el, but if people don't want me
to do the reorganization, I'll just delete the branch and forget about
it.

The branch is just a bunch of moving around. The only code change is
on the first commit, it moves `package-version-join' to subr.el (with
the other version-* functions) under the name `version-join'.

Oddly, it's causing the test `file-notify-test03-autorevert-remote' to fail.

2015-03-29 10:04 GMT+01:00 Steinar Bang <sb@dod.no>:
>>>>>> Artur Malabarba <bruce.connor.am@gmail.com>:
>
>> I'd like to know whether it's ok to split it into two files,
>> package.el and package-menu.el?
>
>> The distinction is very logic, there's a ton of stuff that goes on in
>> package.el which doesn't make any use of the package-menu.
>> The only downside of this refactoring would be to mess up things like
>> `git-blame`, and that's why I'm askinghere.
>
> If you do
>  cp package.el package-menu.el
>  git add package-menu.el
>  git commit -m "Copying verbatim to preserve history"
>
> before you start working, and then do your changes by removing stuff
> from package-menu.el (and package.el) and not move things around
> otherwise, then git-blame should show the correct history.
>
>

Re: Organizing package.el a bit

[Artur Malabarba]

Nevermind, the test fails on master for me as well.

2015-03-29 12:06 GMT+01:00 Artur Malabarba <bruce.connor.am@gmail.com>:
> I just pushed a proposal for this (using page-breaks, not separate
> files) into scratch/organizing-package.el, but if people don't want me
> to do the reorganization, I'll just delete the branch and forget about
> it.
>
> The branch is just a bunch of moving around. The only code change is
> on the first commit, it moves `package-version-join' to subr.el (with
> the other version-* functions) under the name `version-join'.
>
> Oddly, it's causing the test `file-notify-test03-autorevert-remote' to fail.
>
> 2015-03-29 10:04 GMT+01:00 Steinar Bang <sb@dod.no>:
>>>>>>> Artur Malabarba <bruce.connor.am@gmail.com>:
>>
>>> I'd like to know whether it's ok to split it into two files,
>>> package.el and package-menu.el?
>>
>>> The distinction is very logic, there's a ton of stuff that goes on in
>>> package.el which doesn't make any use of the package-menu.
>>> The only downside of this refactoring would be to mess up things like
>>> `git-blame`, and that's why I'm askinghere.
>>
>> If you do
>>  cp package.el package-menu.el
>>  git add package-menu.el
>>  git commit -m "Copying verbatim to preserve history"
>>
>> before you start working, and then do your changes by removing stuff
>> from package-menu.el (and package.el) and not move things around
>> otherwise, then git-blame should show the correct history.
>>
>>