* Is it time to create more subdirs in lisp/? @ 2011-09-01 5:44 Deniz Dogan 2011-09-01 8:35 ` Juri Linkov ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Deniz Dogan @ 2011-09-01 5:44 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-01 5:44 Is it time to create more subdirs in lisp/? Deniz Dogan @ 2011-09-01 8:35 ` Juri Linkov 2011-09-02 2:17 ` Richard Stallman 2011-09-02 1:59 ` Stefan Monnier 2011-09-02 9:11 ` Alan Mackenzie 2 siblings, 1 reply; 15+ messages in thread From: Juri Linkov @ 2011-09-01 8:35 UTC (permalink / raw) To: Deniz Dogan; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-01 8:35 ` Juri Linkov @ 2011-09-02 2:17 ` Richard Stallman 0 siblings, 0 replies; 15+ messages in thread From: Richard Stallman @ 2011-09-02 2:17 UTC (permalink / raw) To: Juri Linkov; +Cc: deniz, emacs-devel 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/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-01 5:44 Is it time to create more subdirs in lisp/? Deniz Dogan 2011-09-01 8:35 ` Juri Linkov @ 2011-09-02 1:59 ` Stefan Monnier 2011-09-02 9:11 ` Alan Mackenzie 2 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2011-09-02 1:59 UTC (permalink / raw) To: Deniz Dogan; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-01 5:44 Is it time to create more subdirs in lisp/? Deniz Dogan 2011-09-01 8:35 ` Juri Linkov 2011-09-02 1:59 ` Stefan Monnier @ 2011-09-02 9:11 ` Alan Mackenzie 2011-09-02 9:39 ` Richard Riley ` (2 more replies) 2 siblings, 3 replies; 15+ messages in thread From: Alan Mackenzie @ 2011-09-02 9:11 UTC (permalink / raw) To: Deniz Dogan; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-02 9:11 ` Alan Mackenzie @ 2011-09-02 9:39 ` Richard Riley 2011-09-02 10:13 ` Deniz Dogan 2011-09-02 13:01 ` Stefan Monnier 2011-09-02 16:26 ` Bill Wohler 2 siblings, 1 reply; 15+ messages in thread From: Richard Riley @ 2011-09-02 9:39 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-02 9:39 ` Richard Riley @ 2011-09-02 10:13 ` Deniz Dogan 0 siblings, 0 replies; 15+ messages in thread From: Deniz Dogan @ 2011-09-02 10:13 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-02 9:11 ` Alan Mackenzie 2011-09-02 9:39 ` Richard Riley @ 2011-09-02 13:01 ` Stefan Monnier 2011-09-02 17:52 ` chad 2011-09-02 16:26 ` Bill Wohler 2 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2011-09-02 13:01 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Deniz Dogan, emacs-devel > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-02 13:01 ` Stefan Monnier @ 2011-09-02 17:52 ` chad 2011-09-04 15:30 ` Kan-Ru Chen 2011-09-06 18:13 ` Stefan Monnier 0 siblings, 2 replies; 15+ messages in thread From: chad @ 2011-09-02 17:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alan Mackenzie, Deniz Dogan, emacs-devel 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-02 17:52 ` chad @ 2011-09-04 15:30 ` Kan-Ru Chen 2011-09-06 18:13 ` Stefan Monnier 1 sibling, 0 replies; 15+ messages in thread From: Kan-Ru Chen @ 2011-09-04 15:30 UTC (permalink / raw) To: chad; +Cc: Alan Mackenzie, emacs-devel, Stefan Monnier, Deniz Dogan 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-02 17:52 ` chad 2011-09-04 15:30 ` Kan-Ru Chen @ 2011-09-06 18:13 ` Stefan Monnier 2011-09-20 13:58 ` Nix 1 sibling, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2011-09-06 18:13 UTC (permalink / raw) To: chad; +Cc: Alan Mackenzie, Deniz Dogan, emacs-devel >> […] 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-06 18:13 ` Stefan Monnier @ 2011-09-20 13:58 ` Nix 2011-09-21 1:24 ` Stephen J. Turnbull 2011-09-21 9:40 ` chad 0 siblings, 2 replies; 15+ messages in thread From: Nix @ 2011-09-20 13:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alan Mackenzie, chad, Deniz Dogan, emacs-devel 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) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-20 13:58 ` Nix @ 2011-09-21 1:24 ` Stephen J. Turnbull 2011-09-21 9:40 ` chad 1 sibling, 0 replies; 15+ messages in thread From: Stephen J. Turnbull @ 2011-09-21 1:24 UTC (permalink / raw) To: Nix; +Cc: Alan Mackenzie, chad, emacs-devel, Stefan Monnier, Deniz Dogan 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-20 13:58 ` Nix 2011-09-21 1:24 ` Stephen J. Turnbull @ 2011-09-21 9:40 ` chad 1 sibling, 0 replies; 15+ messages in thread From: chad @ 2011-09-21 9:40 UTC (permalink / raw) To: Emacs devel; +Cc: Nix, Stefan Monnier 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). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Is it time to create more subdirs in lisp/? 2011-09-02 9:11 ` Alan Mackenzie 2011-09-02 9:39 ` Richard Riley 2011-09-02 13:01 ` Stefan Monnier @ 2011-09-02 16:26 ` Bill Wohler 2 siblings, 0 replies; 15+ messages in thread From: Bill Wohler @ 2011-09-02 16:26 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-09-21 9:40 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-01 5:44 Is it time to create more subdirs in lisp/? Deniz Dogan 2011-09-01 8:35 ` Juri Linkov 2011-09-02 2:17 ` Richard Stallman 2011-09-02 1:59 ` Stefan Monnier 2011-09-02 9:11 ` Alan Mackenzie 2011-09-02 9:39 ` Richard Riley 2011-09-02 10:13 ` Deniz Dogan 2011-09-02 13:01 ` Stefan Monnier 2011-09-02 17:52 ` chad 2011-09-04 15:30 ` Kan-Ru Chen 2011-09-06 18:13 ` Stefan Monnier 2011-09-20 13:58 ` Nix 2011-09-21 1:24 ` Stephen J. Turnbull 2011-09-21 9:40 ` chad 2011-09-02 16:26 ` Bill Wohler
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.