From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Brian Leung via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#44297: [Feature request] project.el: Additional utility functions Date: Fri, 30 Oct 2020 01:47:41 +0100 (CET) Message-ID: <2110324612.148355.1604018860967@ichabod.co-bxl> References: <1785587458.69035.1603939939547@ichabod.co-bxl> <871rhhv4q8.fsf@mail.linkov.net> <64182b62-dad4-08db-379b-acfddea26327@yandex.ru> <87wnz8io18.fsf@tcd.ie> Reply-To: Brian Leung , Brian Leung Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2889"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44297@debbugs.gnu.org, Juri Linkov To: "Basil L. Contovounesios" , Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 30 02:13:46 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kYIzC-0000fj-4b for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Oct 2020 02:13:46 +0100 Original-Received: from localhost ([::1]:34808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYIzB-0000AU-4z for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Oct 2020 21:13:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYIaJ-0002RZ-UD for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 20:48:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43990) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYIaI-0001ko-FG for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 20:48:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kYIaI-00052U-E9 for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 20:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Brian Leung Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Oct 2020 00:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44297 X-GNU-PR-Package: emacs Original-Received: via spool by 44297-submit@debbugs.gnu.org id=B44297.160401887819360 (code B ref 44297); Fri, 30 Oct 2020 00:48:02 +0000 Original-Received: (at 44297) by debbugs.gnu.org; 30 Oct 2020 00:47:58 +0000 Original-Received: from localhost ([127.0.0.1]:55536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYIa9-000527-CS for submit@debbugs.gnu.org; Thu, 29 Oct 2020 20:47:57 -0400 Original-Received: from wilbur.contactoffice.com ([212.3.242.68]:56776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYIa6-00051t-P4 for 44297@debbugs.gnu.org; Thu, 29 Oct 2020 20:47:51 -0400 Original-Received: from ichabod.co-bxl (ichabod.co-bxl [10.2.0.36]) by wilbur.contactoffice.com (Postfix) with ESMTP id 14A3CE45; Fri, 30 Oct 2020 01:47:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1604018864; bh=4MKkp4oXZf8oEEWIh8uq9589dZWyFq/+FpRKDThuQuA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=jDFQ0fo1txFwALebNyn5WuCbZNTCl/kPMkkgkVZm3l5GmMOQsyXiu87YJnPfKkblL RI72f704KNDXlucGQ4p48zGPQthNjxvL+YnQG6ka3M8vXxne6CZUP2v+Jpl75o0+B/ PU65EhU/Q+Q9WrcM0doWMIy/UUC60ZJprADmTEZxcElKCEvGYdeze1gChLISn4LF/4 uIJw8nM3Ws+IjgK8H+wLo0Z1fzMukjF6kvbCAqK6zRMic4Ti6jMQ7AUOGzYPOk/YYn K2FdsUfGJz8JZu4QDm/PWRA41G6aB9JMovcWmML9J+6HTe5cbdgMwIAaRF2mwj0rqL L0lO/eD5G2+6w== In-Reply-To: <87wnz8io18.fsf@tcd.ie> X-Priority: 3 X-Mailer: ContactOffice Mail X-ContactOffice-Account: com:225491745 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192025 Archived-At: > > project-find-file-in-directory: completing-read for a directory within the project, and then within the selected directory, completing-read for a file within that directory > > Is that one really a frequent operation? > > I would imagine that project-find-file, with fuzzy search, would be a faster solution either way. It's something that seems good on paper but that I always forget to use (with Projectile). My rationale for its usefulness is that having to visually filter similar file names based on directory can be a mental burden sometimes when there are similarly-named files in different directories. I don't feel too strongly about this, though, and could live without this feature. > > https://www.emacswiki.org/emacs/FindOtherFile > > > > Projectile also has a command with a similar name. > > > > The feature will be pretty C/C++-centric > > Not if it's customised via ff-other-file-alist or similar. It's also useful with OCaml. > > What I don't understand, is why should it be in the project- namespace?= Looking > > for a file with the same name in the current dir doesn't execute the no= tion of > > the current project, even a little bit. > > > > Projectile does a project-wide search for a file with the same basename= (but a > > different extension). Is that actually useful? > > Maybe when e.g. headers and source files are in different directories? > I don't know whether that's already supported by find-file.el. I cannot figure out how to quickly retrieve the header with ff-find-other-file when the source and header are in different directories; it seems necessary to manually find the containing directory with completing-read during the ff-find-other-file execution, which is cumbersome. So I think this feature would make sense in project.el. > ---------------------------------------- > From: Basil L. Contovounesios > Sent: Fri Oct 30 00:57:07 CET 2020 > To: Dmitry Gutov > Cc: Juri Linkov , <44297@debbugs.gnu.org>, > Subject: Re: bug#44297: [Feature request] project.el: Additional utility = functions >=20 >=20 > Dmitry Gutov writes: >=20 > > On 29.10.2020 11:03, Juri Linkov wrote: > >>> It would be nice if project.el had the following interactive function= s: > >>> > >>> project-find-other-file: Find a file with the same basename as the cu= rrent file but a different extension > >> Maybe then it should be named project-find-other-extension? > >> Otherwise, project-find-other-file might imply a similarity > >> with find-alternate-file (C-x C-v). > > > > I think the term is pretty much established: > > https://www.emacswiki.org/emacs/FindOtherFile > > > > Projectile also has a command with a similar name. > > > > The feature will be pretty C/C++-centric >=20 > Not if it's customised via ff-other-file-alist or similar. >=20 > > , but I suppose it's useful enough. >=20 > > What I don't understand, is why should it be in the project- namespace?= Looking > > for a file with the same name in the current dir doesn't execute the no= tion of > > the current project, even a little bit. > > > > Projectile does a project-wide search for a file with the same basename= (but a > > different extension). Is that actually useful? >=20 > Maybe when e.g. headers and source files are in different directories? > I don't know whether that's already supported by find-file.el. >=20 > --=20 > Basil --=C2=A0 Sent with https://mailfence.com Secure and private email