[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comparison of tools to search for related files
From: |
Damien Cassou |
Subject: |
Re: Comparison of tools to search for related files |
Date: |
Thu, 13 Oct 2022 09:20:09 +0200 |
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