Is it time to create more subdirs in lisp/?

Is it time to create more subdirs in lisp/?

[Deniz Dogan]

The lisp/ directory in trunk could use some more subdirectories.

Examples:


dired-aux.el
dired-x.el
dired.el
epa-dired.el
find-dired.el
image-dired.el

help-at-pt.el
help-fns.el
help-macro.el
help-mode.el
help.el

ps-bdf.el
ps-def.el
ps-mule.el
ps-print.el
ps-samp.el

Re: Is it time to create more subdirs in lisp/?

[Juri Linkov]

> The lisp/ directory in trunk could use some more subdirectories.
>
> Examples:
>
> dired-aux.el
> dired-x.el
> dired.el
> epa-dired.el
> find-dired.el
> image-dired.el

You forgot wdired.el.

> help-at-pt.el
> help-fns.el
> help-macro.el
> help-mode.el
> help.el

And ehelp.el.

> ps-bdf.el
> ps-def.el
> ps-mule.el
> ps-print.el
> ps-samp.el

And printing.el and htmlfontify.el.

Re: Is it time to create more subdirs in lisp/?

[Stefan Monnier]

> The lisp/ directory in trunk could use some more subdirectories.

The rule of thumb we've used until now is "20 .el files is enough for
a subdir".  But the examples you've shown don't add up to 20.
Note that subdirs can be for other things than "a multifile package"
(as seen in the case of `vc', `mail', `play').


        Stefan

Re: Is it time to create more subdirs in lisp/?

[Richard Stallman]

Each subdirectory has a cost, so I decided not to make lots of small ones.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Is it time to create more subdirs in lisp/?

[Alan Mackenzie]

Hi, Deniz.

On Thu, Sep 01, 2011 at 07:44:02AM +0200, Deniz Dogan wrote:
> The lisp/ directory in trunk could use some more subdirectories.

> Examples:


> dired-aux.el
> dired-x.el
> dired.el
> epa-dired.el
> find-dired.el
> image-dired.el

> help-at-pt.el
> help-fns.el
> help-macro.el
> help-mode.el
> help.el

> ps-bdf.el
> ps-def.el
> ps-mule.el
> ps-print.el
> ps-samp.el

I'd say no.  once you start making small directories they're going to
start stacking up in an increasingly tall tree.

I've been in proprietary projects with around 20,000 files in them, all
in directories with ~8-10 files in each.  Visiting a file in such a
hierarchy is a nightmare, as you have to enter, perhaps, 6 successive
directory names to get there.  That's a lot of names to have to navigate
through.

I've been told that small directories are optimal for selecting files
with dialog boxes, but that's not how Emacs works.  I sometimes find it
irritating even to have to go one level down from ../lisp to
../lisp/progmodes.

So my vote is for few large directories rather than many small ones.  I
would go further than Stefan, and say a new directory we create should
have at least 100 files, not 20.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Is it time to create more subdirs in lisp/?

[Richard Riley]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Deniz.
>
> On Thu, Sep 01, 2011 at 07:44:02AM +0200, Deniz Dogan wrote:
>> The lisp/ directory in trunk could use some more subdirectories.
>
>> Examples:
>
>> dired-aux.el
>> dired-x.el
>> dired.el
>> epa-dired.el
>> find-dired.el
>> image-dired.el
>
>> help-at-pt.el
>> help-fns.el
>> help-macro.el
>> help-mode.el
>> help.el
>
>> ps-bdf.el
>> ps-def.el
>> ps-mule.el
>> ps-print.el
>> ps-samp.el
>
> I'd say no.  once you start making small directories they're going to
> start stacking up in an increasingly tall tree.
>
> I've been in proprietary projects with around 20,000 files in them, all
> in directories with ~8-10 files in each.  Visiting a file in such a
> hierarchy is a nightmare, as you have to enter, perhaps, 6 successive
> directory names to get there.  That's a lot of names to have to navigate
> through.
>
> I've been told that small directories are optimal for selecting files
> with dialog boxes, but that's not how Emacs works.  I sometimes find it
> irritating even to have to go one level down from ../lisp to
> ../lisp/progmodes.
>
> So my vote is for few large directories rather than many small ones.  I
> would go further than Stefan, and say a new directory we create should
> have at least 100 files, not 20.

Fwiw, I would agree with that. Small dirs look nice on paper in
orgnisation charts but soon become a selection and maintenance
nightmare. Especially with built in smart file pickers/selects like
ido-mode there to ease the burden. Certainly my once hierarchical emacs
setup soon became a single .emacs.d ... Smart filenames are the key -
prefix is good.

Re: Is it time to create more subdirs in lisp/?

[Deniz Dogan]

On 2011-09-02 11:39, Richard Riley wrote:
> Alan Mackenzie<acm@muc.de>  writes:
>
>> Hi, Deniz.
>>
>> On Thu, Sep 01, 2011 at 07:44:02AM +0200, Deniz Dogan wrote:
>>> The lisp/ directory in trunk could use some more subdirectories.
>>
>>> Examples:
>>
>>> dired-aux.el
>>> dired-x.el
>>> dired.el
>>> epa-dired.el
>>> find-dired.el
>>> image-dired.el
>>
>>> help-at-pt.el
>>> help-fns.el
>>> help-macro.el
>>> help-mode.el
>>> help.el
>>
>>> ps-bdf.el
>>> ps-def.el
>>> ps-mule.el
>>> ps-print.el
>>> ps-samp.el
>>
>> I'd say no.  once you start making small directories they're going to
>> start stacking up in an increasingly tall tree.
>>
>> I've been in proprietary projects with around 20,000 files in them, all
>> in directories with ~8-10 files in each.  Visiting a file in such a
>> hierarchy is a nightmare, as you have to enter, perhaps, 6 successive
>> directory names to get there.  That's a lot of names to have to navigate
>> through.
>>
>> I've been told that small directories are optimal for selecting files
>> with dialog boxes, but that's not how Emacs works.  I sometimes find it
>> irritating even to have to go one level down from ../lisp to
>> ../lisp/progmodes.
>>
>> So my vote is for few large directories rather than many small ones.  I
>> would go further than Stefan, and say a new directory we create should
>> have at least 100 files, not 20.
>
> Fwiw, I would agree with that. Small dirs look nice on paper in
> orgnisation charts but soon become a selection and maintenance
> nightmare. Especially with built in smart file pickers/selects like
> ido-mode there to ease the burden. Certainly my once hierarchical emacs
> setup soon became a single .emacs.d ... Smart filenames are the key -
> prefix is good.
>

I see your point, and I could definitely agree.  I especially agree with 
you about smart filenames!  As you saw, I missed a few files in my examples.

Re: Is it time to create more subdirs in lisp/?

[Stefan Monnier]

> I've been in proprietary projects with around 20,000 files in them, all
> in directories with ~8-10 files in each.  Visiting a file in such a
> hierarchy is a nightmare, as you have to enter, perhaps, 6 successive
> directory names to get there.  That's a lot of names to have to navigate
> through.

I think we all agree on this, yes.  Luckily in Emacs we get to choose
"f(l)at" trees which work best with our default file-selector.  OTOH it
would also be good for Emacs to be able to better handle such
deep hierarchies.

Currently, the file-selector offers the possibility to type "~/e/e/e
TAB" or even "~/eee TAB" to mean "~/etc/emacs/emacs.el", but it'd be
good to be able to go further (maybe not as default, but via some new
completion-style).

E.g. to allow "**/fo TAB" to complete to some file starting with "fo" in
some subdirectory.  Or maybe even to let "a/fo TAB" to complete to
a file with prefix "fo" in a subdirectory of a subdirectory with prefix
"a" (e.g. "toto/apple/blabla/foo.el").

The difficult part is likely to be how to handle the performance issue,
e.g. make sure we only do recursive searches when the user intends to do
such a thing.  Also probably do the search breadth-first to avoid
spending too much time in some deep irrelevant subtree.


        Stefan

Re: Is it time to create more subdirs in lisp/?

[Bill Wohler]

Alan Mackenzie <acm@muc.de> writes:

> So my vote is for few large directories rather than many small ones.  I
> would go further than Stefan, and say a new directory we create should
> have at least 100 files, not 20.

As long as the rule allows for projects such as MH-E, which only has 28,
to have its own directory :-).

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Is it time to create more subdirs in lisp/?

[chad]

On Sep 2, 2011, at 6:01 AM, Stefan Monnier wrote:
> […] OTOH it would also be good for Emacs to be able to better
> handle such deep hierarchies.
> 
> Currently, the file-selector offers the possibility to type "~/e/e/e
> TAB" or even "~/eee TAB" to mean "~/etc/emacs/emacs.el", but it'd be
> good to be able to go further (maybe not as default, but via some new
> completion-style).

zsh has a completion system like this with pretty nice feature set and a fair bit of real-world experience, if anyone is looking for a model.

> 
> E.g. to allow "**/fo TAB" to complete to some file starting with "fo" in
> some subdirectory.  Or maybe even to let "a/fo TAB" to complete to
> a file with prefix "fo" in a subdirectory of a subdirectory with prefix
> "a" (e.g. "toto/apple/blabla/foo.el").
> 
> The difficult part is likely to be how to handle the performance issue,
> e.g. make sure we only do recursive searches when the user intends to do
> such a thing.  Also probably do the search breadth-first to avoid
> spending too much time in some deep irrelevant subtree.
> 
> 
>        Stefan
> 

Re: Is it time to create more subdirs in lisp/?

[Kan-Ru Chen]

chad <yandros@MIT.EDU> writes:

> On Sep 2, 2011, at 6:01 AM, Stefan Monnier wrote:
>> […] OTOH it would also be good for Emacs to be able to better
>> handle such deep hierarchies.
>> 
>> Currently, the file-selector offers the possibility to type "~/e/e/e
>> TAB" or even "~/eee TAB" to mean "~/etc/emacs/emacs.el", but it'd be
>> good to be able to go further (maybe not as default, but via some new
>> completion-style).
>
> zsh has a completion system like this with pretty nice feature set and
> a fair bit of real-world experience, if anyone is looking for a model.
>
>> 
>> E.g. to allow "**/fo TAB" to complete to some file starting with "fo" in
>> some subdirectory.  Or maybe even to let "a/fo TAB" to complete to
>> a file with prefix "fo" in a subdirectory of a subdirectory with prefix
>> "a" (e.g. "toto/apple/blabla/foo.el").

FYI, eshell has implemented this extended globbing in em-glob.el

-- 
Kanru

Re: Is it time to create more subdirs in lisp/?

[Stefan Monnier]

>> […] OTOH it would also be good for Emacs to be able to better
>> handle such deep hierarchies.
>> Currently, the file-selector offers the possibility to type "~/e/e/e
>> TAB" or even "~/eee TAB" to mean "~/etc/emacs/emacs.el", but it'd be
>> good to be able to go further (maybe not as default, but via some new
>> completion-style).

> zsh has a completion system like this with pretty nice feature set
> and a fair bit of real-world experience, if anyone is looking for a model.

I'm a long time zsh user, but AFAIK zsh has fairly simple
completion support.  You can program the completion system à la
pcomplete (i.e. to instruct zsh which completion table to use for the
various args of the commands you use), but the completion itself is only
using prefix completion and/or cycling in my experience.

If there's more to it, I'd love to hear about it (admittedly, I haven't
looked at zsh's doc in recent years so I may have missed such new
features).


        Stefan

Re: Is it time to create more subdirs in lisp/?

[Nix]

On 6 Sep 2011, Stefan Monnier outgrape:

>>> […] OTOH it would also be good for Emacs to be able to better
>>> handle such deep hierarchies.
>>> Currently, the file-selector offers the possibility to type "~/e/e/e
>>> TAB" or even "~/eee TAB" to mean "~/etc/emacs/emacs.el", but it'd be
>>> good to be able to go further (maybe not as default, but via some new
>>> completion-style).
>
>> zsh has a completion system like this with pretty nice feature set
>> and a fair bit of real-world experience, if anyone is looking for a model.
>
> I'm a long time zsh user, but AFAIK zsh has fairly simple
> completion support.  You can program the completion system à la
> pcomplete (i.e. to instruct zsh which completion table to use for the
> various args of the commands you use), but the completion itself is only
> using prefix completion and/or cycling in my experience.

It's... grown (perhaps 'metastasized' would be a better term). ls
l/pcm*el can autocomplete to lisp/pcomplete.el easily. It does prefix,
suffix and infix completion, environment vbariable completion, fuzzy
spelling correction, automatic recursion, you name it. It can display
menus, even multilevel ones, grouped in various ways as well as using
prefix completion or cycling.

You may find 'compinstall' interesting to play with.

> If there's more to it, I'd love to hear about it (admittedly, I haven't
> looked at zsh's doc in recent years so I may have missed such new
> features).

Shall we say that the zsh autocompletion system is now largely written
*in* zsh, has multiple layers (high-level and low-level, with the high-
level layer providing the display frontends to the low-level potential-
completion-computation layer) and occupies more than half the 500-page
manual. It's the single most hilariously overdesigned completion system
I have ever heard of, knocking Emacs off the perch which should rightly
belong to it :)

-- 
NULL && (void)

Re: Is it time to create more subdirs in lisp/?

[Stephen J. Turnbull]

Nix writes:

 > [zsh has] the single most hilariously overdesigned completion
 > system I have ever heard of, knocking Emacs off the perch which
 > should rightly belong to it :)

Are you sure you don't mean that we have the most hilariously
underdesigned file systems, and zsh completion is symply the Newtonian
equal and opposite reaction?

Re: Is it time to create more subdirs in lisp/?

[chad]

Stefan asked me for details about zsh completion a while back, and I've
been remiss about replying. In truth, my experience with zsh is mostly
second-hand; when I switched from mostly-hacking to mostly-writing,
I reverted to my old standby tcsh.  The reference to zsh completion
comes mostly from the features that were borrowed from it into tcsh, 
and from a friend.  I glanced at the zsh man-page and saw that things
had evolved to the point where completion had been spread into three
separate sub-pages (one each for completion widgets, system, and 
control) and assumed that it still represented an elaborate completion
system with a bunch of real-world experience behind it.

My thanks to Nix for reminding me that I owed Stefan a reply, and 
also for talking knowledgeably about the actual details.

*Chad

> If there's more to it, I'd love to hear about it (admittedly, I haven't
> looked at zsh's doc in recent years so I may have missed such new
> features).