2:52 p.m.
Ok, I'm willing to start slowly splitting packages into smaller, more
closely-related chunks. I've seen many messages about this saying that
people have not had time to do it in the past.
The first ones in my list would be splitting python, perl and ruby stuff
out from prog-modes, since these involve multiple files in a single-file
package.
I'm thinking about the naming of this kind of packages, and suggest
foo-support as the template. Like this:
ruby-support: ruby-mode.el* inf-ruby.el* rubydb3x.el* (not in CVS yet)
python-support: python-mode.el* pydoc*
perl-support: cperl-mode.el perl-mode.el
Maybe old-c-mode.el from prog-modes should also be moved to c-support.
Thoughts?
--
\/ille Skyttä
ville.skytta at xemacs.org
2:57 p.m.
On Sat, 2002-08-31 at 16:52, Ville Skyttä wrote:
I'm thinking about the naming of this kind of packages, and
suggest
foo-support as the template. Like this:
After a 2nd look, maybe foo-modes would be better, for consistency with
existing packages...
--
\/ille Skyttä
ville.skytta at xemacs.org
3:10 p.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Sat, 2002-08-31 at 16:52, Ville Skyttä wrote:
> I'm thinking about the naming of this kind of packages, and
suggest
> foo-support as the template. Like this:
Ville> After a 2nd look, maybe foo-modes would be better, for consistency with
Ville> existing packages...
sounds good to me dude
i think i need to make that individual package release script i was
talking about, i think i will be needed if there are even more packages
are you think about doing the same to edit-utils as well ??
if so i suggest breaking them up into sections like this
web|net-modes
unix-modes
etc etc
--
XEmacs Advocate | Do not try the patience of Wizards,
FreeBSD Devote | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
3:50 p.m.
On Sat, 2002-08-31 at 17:10, Rendhalver [Peter Brown] wrote:
>>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Sat, 2002-08-31 at 16:52, Ville Skyttä wrote:
>> I'm thinking about the naming of this kind of packages, and suggest
>> foo-support as the template. Like this:
Ville> After a 2nd look, maybe foo-modes would be better, for consistency with
Ville> existing packages...
sounds good to me dude
i think i need to make that individual package release script i was
talking about, i think i will be needed if there are even more packages
:)
are you think about doing the same to edit-utils as well ??
if so i suggest breaking them up into sections like this
web|net-modes
unix-modes
etc etc
I think the ultimate goal would be to have stuff packaged so that one
package provides support for one thing. But maybe the pui is not ready
for fine-grained packaging. Categories would help, instead of the
currently provided flat list, even better if the categories would be
hierarchical. To illustrate:
Programming
|- C
| |- cc-mode
| |- c-support
| `- ...
|- Perl
| `- ...
|- Java
| |- jdee
| `- ...
WWW
|- MarkUp
| |- psgml
| | `- psgml-dtds
| `- hm--html-menus
|- css-mode
|- ...
Mail
|- gnus
|- vm
...
So, web-modes or unix-modes sound a bit too generic to me, but they
could be category names. For now, I suggest that when splitting
packages, the resulting ones should be ready to be put as leaves into
this kind of tree, ie. specific enough.
--
\/ille Skyttä
ville.skytta at xemacs.org
4:20 p.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Sat, 2002-08-31 at 17:10, Rendhalver [Peter Brown] wrote:
>> >>>> "Ville" == Ville
Skytt <Ville> writes:
>>
Ville> On Sat, 2002-08-31 at 16:52, Ville Skyttä wrote:
> >> I'm thinking about the naming of this kind of
packages, and suggest
> >> foo-support as the template. Like this:
>
Ville> After a 2nd look, maybe foo-modes would be better, for
consistency with
Ville> existing packages...
>
> sounds good to me dude
>
> i think i need to make that individual package release script i was
> talking about, i think i will be needed if there are even more packages
Ville> :)
> are you think about doing the same to edit-utils as well ??
> if so i suggest breaking them up into sections like this
>
> web|net-modes
> unix-modes
> etc etc
Ville> I think the ultimate goal would be to have stuff packaged so that one
Ville> package provides support for one thing. But maybe the pui is not ready
Ville> for fine-grained packaging. Categories would help, instead of the
Ville> currently provided flat list, even better if the categories would be
Ville> hierarchical. To illustrate:
this sounds really cool :)
will require some serious hacking to get it to go i think
but it is definatly needed :)
Ville> Programming
Ville> |- C
Ville> | |- cc-mode
Ville> | |- c-support
Ville> | `- ...
Ville> |- Perl
Ville> | `- ...
Ville> |- Java
Ville> | |- jdee
Ville> | `- ...
Ville> WWW
Ville> |- MarkUp
Ville> | |- psgml
Ville> | | `- psgml-dtds
Ville> | `- hm--html-menus
Ville> |- css-mode
Ville> |- ...
Ville> Mail
Ville> |- gnus
Ville> |- vm
Ville> ...
Ville> So, web-modes or unix-modes sound a bit too generic to me, but they
Ville> could be category names. For now, I suggest that when splitting
Ville> packages, the resulting ones should be ready to be put as leaves into
Ville> this kind of tree, ie. specific enough.
yep definatly
ponders wether adding categories to the packages tree would annoy anyone
was it split into categories before ??
and are there not categories defined already ??
maybe we could add more cetegories to the already defined ones
--
XEmacs Advocate | Do not try the patience of Wizards,
FreeBSD Devote | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
3:36 p.m.
|--==> "R" == rendhalver <rendhalver(a)xemacs.org> writes:
R> ponders wether adding categories to the packages tree would annoy
R> anyone
More than likely.
R> was it split into categories before ??
The source tree used to be, sorta kinda.
R> and are there not categories defined already ??
Not anymore, no.
R> maybe we could add more cetegories to the already defined ones
I would strongly advise against it.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:30 p.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> I think the ultimate goal would be to have stuff packaged so
VS> that one package provides support for one thing.
Apart from a few exceptions, this is pretty much what we have now.
VS> But maybe the pui is not ready for fine-grained packaging.
VS> Categories would help, instead of the currently provided flat
VS> list, even better if the categories would be hierarchical. To
VS> illustrate:
You're talking about an installed tree here aren't you, not a source
tree? Seems like a natural thing to do.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
6:58 a.m.
On Wed, 2002-09-18 at 17:30, Steve Youngs wrote:
VS> But maybe the pui is not ready for fine-grained packaging.
VS> Categories would help, instead of the currently provided flat
VS> list, even better if the categories would be hierarchical. To
VS> illustrate:
You're talking about an installed tree here aren't you, not a source
tree? Seems like a natural thing to do.
I'm talking about the way the packages are presented to the end user in
the package UI. So that the categories would be sort of meta
information, and would most likely have no effect on the layout of
source or installed trees. The current flat layout on disk is just fine
IMO.
The hierarchies could be described in package-index* or a new file that
would live in the packages download dir, automatically generated from
information gathered from packages' package-infos.
--
\/ille Skyttä
ville.skytta at xemacs.org
8:58 a.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> I'm talking about the way the packages are presented to the end
VS> user in the package UI. So that the categories would be sort of
VS> meta information, and would most likely have no effect on the
VS> layout of source or installed trees. The current flat layout on
VS> disk is just fine IMO.
Ah! Yep, I'm definitely cool with that!
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
10 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> |--==> "VS" == Ville Skytt <Ville> writes:
VS> I'm talking about the way the packages are presented to the end
VS> user in the package UI. So that the categories would be sort of
VS> meta information, and would most likely have no effect on the
VS> layout of source or installed trees. The current flat layout on
VS> disk is just fine IMO.
SY> Ah! Yep, I'm definitely cool with that!
excellent:)
once i release this Sumo we can start adding Categories and such to pui
i have some ideas on how we can store the info and possibly a new way
of doing the package-index. i will post my ideas about this very soon
and will welcome comments and such
--
XEmacs Advocate | Do not try the patience of Wizards,
FreeBSD Devote | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
3:08 p.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> Ok, I'm willing to start slowly splitting packages into smaller, more
VS> closely-related chunks. I've seen many messages about this saying that
VS> people have not had time to do it in the past.
VS> The first ones in my list would be splitting python, perl and ruby stuff
VS> out from prog-modes, since these involve multiple files in a single-file
VS> package.
VS> I'm thinking about the naming of this kind of packages, and suggest
VS> foo-support as the template. Like this:
VS> ruby-support: ruby-mode.el* inf-ruby.el* rubydb3x.el* (not in CVS yet)
VS> python-support: python-mode.el* pydoc*
VS> perl-support: cperl-mode.el perl-mode.el
This seems like a good plan to me. And I like your "foo-mode" naming
scheme better.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
7883
days inactive
7902
days old
10 comments
3 participants
participants (3)
-
Rendhalver [Peter Brown] -
Steve Youngs -
Ville Skyttä