bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#44297: [Feature request] project.el: Additional utility functions
Date: Fri, 30 Oct 2020 19:47:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]