From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Is it time to create more subdirs in lisp/? Date: Fri, 02 Sep 2011 09:01:25 -0400 Message-ID: References: <4E5F1BA2.8040506@dogan.se> <20110902091157.GA2770@acm.acm> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1314968499 22163 80.91.229.12 (2 Sep 2011 13:01:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Sep 2011 13:01:39 +0000 (UTC) Cc: Deniz Dogan , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 02 15:01:35 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QzTND-00073q-O6 for ged-emacs-devel@m.gmane.org; Fri, 02 Sep 2011 15:01:31 +0200 Original-Received: from localhost ([::1]:43161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzTNC-0006ci-PF for ged-emacs-devel@m.gmane.org; Fri, 02 Sep 2011 09:01:30 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:48594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzTNA-0006cd-Lu for emacs-devel@gnu.org; Fri, 02 Sep 2011 09:01:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzTN9-0005n7-Eo for emacs-devel@gnu.org; Fri, 02 Sep 2011 09:01:28 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:1175 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzTN9-0005n3-CB for emacs-devel@gnu.org; Fri, 02 Sep 2011 09:01:27 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALDSYE64rwMJ/2dsb2JhbABCqGV5gUYBAQQBViMFCwsOJhIUGA0kiAW3LYZlBKAVhEA X-IronPort-AV: E=Sophos;i="4.68,319,1312171200"; d="scan'208";a="134124042" Original-Received: from 184-175-3-9.dsl.teksavvy.com (HELO ceviche.home) ([184.175.3.9]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 02 Sep 2011 09:01:25 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 9308C6623F; Fri, 2 Sep 2011 09:01:25 -0400 (EDT) In-Reply-To: <20110902091157.GA2770@acm.acm> (Alan Mackenzie's message of "Fri, 2 Sep 2011 09:11:57 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143713 Archived-At: > 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