bug#58071: 28.2; [PATCH] jumprel: A tool to find/create related files

[Damien Cassou <damien@cassou.me>]

Thank you very much Eli for your review. I appreciate the time you took
to have a look at my code. I imagine how busy you are and my package
isn't small.

Eli Zaretskii <eliz@gnu.org> writes:
> - "jumprel" is not the best name, IMO; something like "related-files"
> would be better

sure

> - what you call "recipes", i.e. descriptors of how to generate the
> name of related files from a given file name, should be documented in
> a single doc string, and the other places that use recipes should
> reference the symbol whose doc string documents them

do you have any suggestion for this? The only place I can find is
`jumprel-recipe--apply-filename-jumper' which is private. I could also
add it to the override of `jumprel-apply' but I'm not sure how to
reference an override from a docstring.

> - I find no documentation of how to describe alternatives -- several
> alternative file names produced from a single original file name

several alternatives can be produced with:

1. several jumpers produce several alternatives: all jumpers are
executed on the current file name and their results are merged into a
single list of candidates (see `jumprel--collect-existing-places' and
`jumprel--call-jumpers').

2. a function-based jumper returning a list (this is described in the
   docstring of `jumprel-apply')

3. a regexp-based jumper may also return a list of candidates if the
globs match several existing filenames

4. a recipe-based jumper may also return a list of candidates if
:add-directory is used and several matching directories exist

Does that answer your question or did I miss the point?

> - I wonder whether "recipes" like these are a convenient method of
>    customizing this facility: do people really find it easy to write
>    "ordered" property lists for this purpose?

I find the resulting syntax very easy to read:

(recipe :remove-suffix ".js" :add-suffix "-tests.js" :add-directory "tests" :case-transformer uncapitalize)
(recipe :remove-suffix ".js" :add-suffix ".spec.component.js" :filler (yasnippet :name "componentSpec"))
(recipe :remove-suffix ".js" :add-suffix ".less")
(recipe :remove-suffix ".js" :add-suffix ".stories.js" :filler (yasnippet :name "stories")))

I think this is much clearer than using regular expressions but this is
maybe only me? If you don't like the recipe syntax, we can leave this
one out of the patch and only include regexp-based jumpers.

What do you expect from me now? Send a new patch with the new package
name? Or do you plan to give more feedback first?

Lars Ingebrigtsen <larsi@gnus.org> writes:
> I think jumprel would probably be better suited as an ELPA
> package. Like completion frameworks, there's no one size fits all in
> this area -- the DWIM for one person isn't the DWIM for another
> person.

Thank you very much Lars for giving feedback on this package! I
appreciate your point of view because you've already written a similar
feature which probably means you are using it.

> jumprel is a different take on what find-file does, just like Helm is
> a different take how completion should look.

I'm not sure I understand what you mean. I agree that there is no point
in having 10 many different completion frameworks in Emacs core (even
though we might be close to this number already 😊).

Similarly, I wouldn't like to have 3 find-related-files packages. But I
think that, contrary to completion frameworks, these 3 packages provide
the same feature: namely "a command to find file(s) related to the
current one". Said differently, the user-visible behavior is the
same. As soon as the setup is done, there shouldn't any difference
between `find-sibling-file' and `jumprel'.

Is there anything in your process that would change if you would switch
from `find-sibling-file' to `jumprel'?

In my opinion, what differs between these packages is the extensibility
of the implementation. If regexps are a good solution to configure
relations between files, both packages support that thanks to your
work. But if users want something else, they could only get it in
`jumprel': either with functions, with recipes or with something else of
their creation.

Also, jumprel supports creation of related files and automatic filling
of new files through an extensible mechanism I called a "filler".

Best

-- 
Damien Cassou

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