all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Organizing package.el a bit
@ 2015-03-28  9:52 Artur Malabarba
  2015-03-28 12:36 ` Stefan Monnier
  2015-03-29  9:04 ` Steinar Bang
  0 siblings, 2 replies; 9+ messages in thread
From: Artur Malabarba @ 2015-03-28  9:52 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-28  9:52 Organizing package.el a bit Artur Malabarba
@ 2015-03-28 12:36 ` Stefan Monnier
  2015-03-28 13:35   ` Artur Malabarba
  2015-03-29  9:04 ` Steinar Bang
  1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2015-03-28 12:36 UTC (permalink / raw)
  To: Artur Malabarba; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-28 12:36 ` Stefan Monnier
@ 2015-03-28 13:35   ` Artur Malabarba
  2015-03-28 14:52     ` Artur Malabarba
  0 siblings, 1 reply; 9+ messages in thread
From: Artur Malabarba @ 2015-03-28 13:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-28 13:35   ` Artur Malabarba
@ 2015-03-28 14:52     ` Artur Malabarba
  2015-03-28 14:55       ` Oleh Krehel
  0 siblings, 1 reply; 9+ messages in thread
From: Artur Malabarba @ 2015-03-28 14:52 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-28 14:52     ` Artur Malabarba
@ 2015-03-28 14:55       ` Oleh Krehel
  2015-03-28 17:50         ` Artur Malabarba
  0 siblings, 1 reply; 9+ messages in thread
From: Oleh Krehel @ 2015-03-28 14:55 UTC (permalink / raw)
  To: Artur Malabarba; +Cc: Stefan Monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-28 14:55       ` Oleh Krehel
@ 2015-03-28 17:50         ` Artur Malabarba
  0 siblings, 0 replies; 9+ messages in thread
From: Artur Malabarba @ 2015-03-28 17:50 UTC (permalink / raw)
  To: Oleh; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-28  9:52 Organizing package.el a bit Artur Malabarba
  2015-03-28 12:36 ` Stefan Monnier
@ 2015-03-29  9:04 ` Steinar Bang
  2015-03-29 11:06   ` Artur Malabarba
  1 sibling, 1 reply; 9+ messages in thread
From: Steinar Bang @ 2015-03-29  9:04 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-29  9:04 ` Steinar Bang
@ 2015-03-29 11:06   ` Artur Malabarba
  2015-03-29 12:56     ` Artur Malabarba
  0 siblings, 1 reply; 9+ messages in thread
From: Artur Malabarba @ 2015-03-29 11:06 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Organizing package.el a bit
  2015-03-29 11:06   ` Artur Malabarba
@ 2015-03-29 12:56     ` Artur Malabarba
  0 siblings, 0 replies; 9+ messages in thread
From: Artur Malabarba @ 2015-03-29 12:56 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-03-29 12:56 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-28  9:52 Organizing package.el a bit Artur Malabarba
2015-03-28 12:36 ` Stefan Monnier
2015-03-28 13:35   ` Artur Malabarba
2015-03-28 14:52     ` Artur Malabarba
2015-03-28 14:55       ` Oleh Krehel
2015-03-28 17:50         ` Artur Malabarba
2015-03-29  9:04 ` Steinar Bang
2015-03-29 11:06   ` Artur Malabarba
2015-03-29 12:56     ` Artur Malabarba

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.