GNU bug report logs -
#44297
[Feature request] project.el: Additional utility functions
Previous Next
To reply to this bug, email your comments to 44297 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Thu, 29 Oct 2020 02:53:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Brian Leung <leungbk <at> mailfence.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 29 Oct 2020 02:53:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
It would be nice if project.el had the following interactive functions:
project-find-other-file: Find a file with the same basename as the current file but a different extension
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
project-recentf: completing-read recently-accessed files in the project
project-find-directory: completing-read for a directory within the project
project-gdb: GDB in project root directory
--
Sent with https://mailfence.com
Secure and private email
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Thu, 29 Oct 2020 09:14:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
> It would be nice if project.el had the following interactive functions:
>
> project-find-other-file: Find a file with the same basename as the current 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).
Another question: how it should work? Maybe running this command
should completing-read on all files with the same basename
ignoring the extension?
> 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
> project-find-directory: completing-read for a directory within the project
Another useful command would be:
project-find-file-only using completing-read to match on file names only,
not on directory parts.
> project-recentf: completing-read recently-accessed files in the project
All project file-reading commands could provide a list of recent files
as the default values available via M-n key presses.
> project-gdb: GDB in project root directory
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Thu, 29 Oct 2020 09:14:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Thu, 29 Oct 2020 23:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 44297 <at> debbugs.gnu.org (full text, mbox):
On 29.10.2020 11:03, Juri Linkov wrote:
>> It would be nice if project.el had the following interactive functions:
>>
>> project-find-other-file: Find a file with the same basename as the current 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, but I suppose it's useful enough.
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 notion 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?
> Another question: how it should work? Maybe running this command
> should completing-read on all files with the same basename
> ignoring the extension?
Projectile has projectile-other-file-alist. A similar defcustom should
narrow the search somewhat.
>> 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
>> project-find-directory: completing-read for a directory within the project
>
> Another useful command would be:
> project-find-file-only using completing-read to match on file names only,
> not on directory parts.
And then... disambiguate files with the same base name with another prompt?
IME, having multiple files with the same name in the project is very
common. Your experience can vary, though.
A fuzzy search across full names works best for me, personally. We could
also try some differently weighted, fuzzy matching styles.
>> project-recentf: completing-read recently-accessed files in the project
>
> All project file-reading commands could provide a list of recent files
> as the default values available via M-n key presses.
Perhaps a flat, immediately visible list will have its own value, though?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Thu, 29 Oct 2020 23:32:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 44297 <at> debbugs.gnu.org (full text, mbox):
On 29.10.2020 04:52, Brian Leung via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> project-find-directory: completing-read for a directory within the project
This is bug#43153.
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Thu, 29 Oct 2020 23:58:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44297 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 29.10.2020 11:03, Juri Linkov wrote:
>>> It would be nice if project.el had the following interactive functions:
>>>
>>> project-find-other-file: Find a file with the same basename as the current 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
Not if it's customised via ff-other-file-alist or similar.
> , but I suppose it's useful enough.
> 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 notion 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.
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Fri, 30 Oct 2020 00:48:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 44297 <at> debbugs.gnu.org (full text, mbox):
> > 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 notion 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 <contovob <at> tcd.ie>
> Sent: Fri Oct 30 00:57:07 CET 2020
> To: Dmitry Gutov <dgutov <at> yandex.ru>
> Cc: Juri Linkov <juri <at> linkov.net>, <44297 <at> debbugs.gnu.org>, <leungbk <at> mailfence.com>
> Subject: Re: bug#44297: [Feature request] project.el: Additional utility functions
>
>
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
> > On 29.10.2020 11:03, Juri Linkov wrote:
> >>> It would be nice if project.el had the following interactive functions:
> >>>
> >>> project-find-other-file: Find a file with the same basename as the current 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
>
> Not if it's customised via ff-other-file-alist or similar.
>
> > , but I suppose it's useful enough.
>
> > 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 notion 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.
>
> --
> Basil
--
Sent with https://mailfence.com
Secure and private email
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Fri, 30 Oct 2020 07:29:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 44297 <at> debbugs.gnu.org (full text, mbox):
> I think the term is pretty much established:
> https://www.emacswiki.org/emacs/FindOtherFile
>
> Projectile also has a command with a similar name.
Then the name 'other-file' is fine.
> The feature will be pretty C/C++-centric, but I suppose it's useful enough.
It's also useful with Web development: while VueJS can keep parts of
components in one file .vue, other frameworks require 3 different files:
file.html, file.js and file.css.
>> Another useful command would be:
>> project-find-file-only using completing-read to match on file names only,
>> not on directory parts.
>
> And then... disambiguate files with the same base name with another prompt?
>
> IME, having multiple files with the same name in the project is very
> common. Your experience can vary, though.
>
> A fuzzy search across full names works best for me, personally. We could
> also try some differently weighted, fuzzy matching styles.
I don't know if the required completion can be part of a fuzzy search,
but it should show exactly the same completions as the current command
(with directory and file names), but should match only on file name parts,
not on directory name parts, e.g. with files:
dirname/filename1 dirname/file2
typing "name" for completions should show only "dirname/filename1",
because most of the time, project directory names get in the way
when searching for a file by its name, and part of file name matches
directory names with many other unrelated files.
>>> project-recentf: completing-read recently-accessed files in the project
>> All project file-reading commands could provide a list of recent files
>> as the default values available via M-n key presses.
>
> Perhaps a flat, immediately visible list will have its own value, though?
Sorted by recency?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Fri, 30 Oct 2020 17:41:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 44297 <at> debbugs.gnu.org (full text, mbox):
On 30.10.2020 01:57, Basil L. Contovounesios wrote:
>> 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 notion 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?
All right then.
> I don't know whether that's already supported by find-file.el.
Apparently it's done using the ff-search-directories variable.
I'm not sure about usefulness of this, given the default value lists
system directories. Was the user always supposed to customize it to list
the source dirs in the current project?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Fri, 30 Oct 2020 17:44:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 44297 <at> debbugs.gnu.org (full text, mbox):
On 30.10.2020 09:23, Juri Linkov wrote:
>> I think the term is pretty much established:
>> https://www.emacswiki.org/emacs/FindOtherFile
>>
>> Projectile also has a command with a similar name.
>
> Then the name 'other-file' is fine.
>
>> The feature will be pretty C/C++-centric, but I suppose it's useful enough.
>
> It's also useful with Web development: while VueJS can keep parts of
> components in one file .vue, other frameworks require 3 different files:
> file.html, file.js and file.css.
OK.
How will we choose among multiple files when there are more than 2?
Completing read on the file extension? Or just rotate among the files in
a pre-defined order?
>> A fuzzy search across full names works best for me, personally. We could
>> also try some differently weighted, fuzzy matching styles.
>
> I don't know if the required completion can be part of a fuzzy search,
> but it should show exactly the same completions as the current command
> (with directory and file names), but should match only on file name parts,
> not on directory name parts, e.g. with files:
>
> dirname/filename1 dirname/file2
>
> typing "name" for completions should show only "dirname/filename1",
> because most of the time, project directory names get in the way
> when searching for a file by its name, and part of file name matches
> directory names with many other unrelated files.
So... suppose the user types out a file name in full and sees several
matches (in different directories). What happens then?
>>>> project-recentf: completing-read recently-accessed files in the project
>>> All project file-reading commands could provide a list of recent files
>>> as the default values available via M-n key presses.
>>
>> Perhaps a flat, immediately visible list will have its own value, though?
>
> Sorted by recency?
Yup.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Fri, 30 Oct 2020 17:48:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 44297 <at> debbugs.gnu.org (full text, mbox):
On 30.10.2020 02:47, Brian Leung wrote:
>>> 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).
What do you mean by "forget"? You still use the command, but never type
out words to match against the directory?
> 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.
Perhaps we could come up with a completion style that uses special
indicators, e.g. some sigil to mean "input that comes after this should
only be matched against the base file name".
Just spitballing. I'm not sure what the implementation would look like.
>>> 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.
Very good.
>>> 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 notion 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.
Yes, OK.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Sat, 31 Oct 2020 19:46:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 44297 <at> debbugs.gnu.org (full text, mbox):
>> file.html, file.js and file.css.
>
> OK.
>
> How will we choose among multiple files when there are more than 2?
> Completing read on the file extension? Or just rotate among the files in
> a pre-defined order?
The convenience of rotating will degrade with increase of the number of found files.
But maybe rotating among 3 files would be fine.
>>> A fuzzy search across full names works best for me, personally. We could
>>> also try some differently weighted, fuzzy matching styles.
>> I don't know if the required completion can be part of a fuzzy search,
>> but it should show exactly the same completions as the current command
>> (with directory and file names), but should match only on file name parts,
>> not on directory name parts, e.g. with files:
>> dirname/filename1 dirname/file2
>> typing "name" for completions should show only "dirname/filename1",
>> because most of the time, project directory names get in the way
>> when searching for a file by its name, and part of file name matches
>> directory names with many other unrelated files.
>
> So... suppose the user types out a file name in full and sees several
> matches (in different directories). What happens then?
The user then selects one of them to visit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44297; Package
emacs.
(Mon, 02 Nov 2020 00:29:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 44297 <at> debbugs.gnu.org (full text, mbox):
On 31.10.2020 21:18, Juri Linkov wrote:
>>> file.html, file.js and file.css.
>>
>> OK.
>>
>> How will we choose among multiple files when there are more than 2?
>> Completing read on the file extension? Or just rotate among the files in
>> a pre-defined order?
>
> The convenience of rotating will degrade with increase of the number of found files.
> But maybe rotating among 3 files would be fine.
With more files, the user might want to opt for the "normal"
project-find-file completion, rather than this command.
I mean, we could add an option for a threshold, after which we pop up
extension completion, but at this stage it sounds probably unnecessary.
And if the user sets up hydra integration, they could easily swish
through many more files, very quickly.
Projectile uses completion here, though.
>>>> A fuzzy search across full names works best for me, personally. We could
>>>> also try some differently weighted, fuzzy matching styles.
>>> I don't know if the required completion can be part of a fuzzy search,
>>> but it should show exactly the same completions as the current command
>>> (with directory and file names), but should match only on file name parts,
>>> not on directory name parts, e.g. with files:
>>> dirname/filename1 dirname/file2
>>> typing "name" for completions should show only "dirname/filename1",
>>> because most of the time, project directory names get in the way
>>> when searching for a file by its name, and part of file name matches
>>> directory names with many other unrelated files.
>>
>> So... suppose the user types out a file name in full and sees several
>> matches (in different directories). What happens then?
>
> The user then selects one of them to visit.
From *Compleitons* buffer, with a mouse? I don't know of another way to
"select one of them" using the default completion UI.
This bug report was last modified 4 years and 231 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.