bug#44297: [Feature request] project.el: Additional utility functions

bug#44297: [Feature request] project.el: Additional utility functions

[Brian Leung via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#44297: [Feature request] project.el: Additional utility functions

[Juri Linkov]

> 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

bug#44297: [Feature request] project.el: Additional utility functions

[Dmitry Gutov]

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?

bug#44297: [Feature request] project.el: Additional utility functions

[Dmitry Gutov]

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.

bug#44297: [Feature request] project.el: Additional utility functions

[Basil L. Contovounesios]

Dmitry Gutov <dgutov@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

bug#44297: [Feature request] project.el: Additional utility functions

[Brian Leung via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> > 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@tcd.ie>
> Sent: Fri Oct 30 00:57:07 CET 2020
> To: Dmitry Gutov <dgutov@yandex.ru>
> Cc: Juri Linkov <juri@linkov.net>, <44297@debbugs.gnu.org>, <leungbk@mailfence.com>
> Subject: Re: bug#44297: [Feature request] project.el: Additional utility functions
> 
> 
> Dmitry Gutov <dgutov@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

bug#44297: [Feature request] project.el: Additional utility functions

[Juri Linkov]

> 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?

bug#44297: [Feature request] project.el: Additional utility functions

[Dmitry Gutov]

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?

bug#44297: [Feature request] project.el: Additional utility functions

[Dmitry Gutov]

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.

bug#44297: [Feature request] project.el: Additional utility functions

[Dmitry Gutov]

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.

bug#44297: [Feature request] project.el: Additional utility functions

[Juri Linkov]

>> 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.

bug#44297: [Feature request] project.el: Additional utility functions

[Dmitry Gutov]

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.