Re: Comparison of tools to search for related files

[Damien Cassou]

Felician Nemeth <felician.nemeth@gmail.com> writes:
> As a developer of foo-mode, I'd like to implement a related file
> functionality for just one backend (find-file or related-file).


You mean the developer of c-mode would specify that .c and .h are
related? This makes sense.


> As a user, I'd like to bind just one (global) key to this
> functionality and be ignorant how foo-mode or bar-mode implements it.


Indeed.


> To paraphrase what Lars wrote earlier, we had
> completion-at-point-functions providing a clear completion API between
> backends and frontends.  Does a similar API exist for related files?


I'm not sure the comparison stands here because there are not several
frontends and backends with pros and cons. We just need 1 key binding to
jump to a related file and a configuration option to specify how to
compute related files from the current file.


> If I understand correctly find-sibling-file primarily solves a
> different problem: to easily switch among different versions of the same
> file when for example multiple branches of a project is checked out in
> parallel.


find-sibling-file goes beyond that. It allows for specifying a regexp
and an expansion so the user could also specify how to go from a .c file
to a .h file.

For related-files.el, the regexp way of specifying related files is just
one among others: the user can also specify related files through
functions and a recipe DSL or define another way. related-files also
allows creating related files through different mechanisms and users can
add more mechanisms.


> But maybe I misunderstand the purpose of related-files.el.  If it's the
> user who configures related-files because the user has a special naming
> convention, for example, to have files like page.html, page.css,
> page.js


This is indeed the use-case I had in mind and it seems similar to the
one of find-sibling-file.


>, then I don't think a common API is necessary.  Then users can
> choose to configure whatever package they like.


That is true. But I'm not sure we want the same feature implemented 3
times in 3 different ways.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill