bug#55778: 29.0.50; [PATCH] M-. into a .gz; we've all been there.

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dick.r.chiang@gmail.com,  55778@debbugs.gnu.org,  monnier@iro.umontreal.ca
> Date: Tue, 07 Jun 2022 11:13:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe I'm missing something, but isn't ff-other-file-alist equivalent
> > to your find-sibling-rules?
> 
> No?  "Alist of extensions to find given the current file's extension."
> `find-sibling-rules' isn't about extensions.

It isn't?  Then why did you show these examples:

> So I've now added a new command `find-sibling-file' to Emacs 29.  This
> setting does what the latter:
> 
> (setq find-sibling-rules
>       '(("\\(/usr/share/emacs.*/\\(lisp/.*.el\\).gz\\)"
>        "/home/larsi/src/emacs/trunk/\\2\\'")))
> 
> Something like this does the Emacs development sibling dance:
> 
> (setq find-sibling-rules
>       '(("src/emacs/trunk/[^/]+/\\(.*\\)\\'" "src/emacs/emacs-28/.*/\\1\\'")
>       ("emacs/trunk/\\(.*\\)\\.\\(c\\|el\\)\\'"
>        "emacs/trunk/test/\\1-tests.el\\'")))
> 
> And this is foo.c -> foo.h:
> 
> (setq find-sibling-rules
>       '(("\\([^/]+\\)\\.c\\'" "\\1.h")))

AFAIU, almost all of them are about extensions.  find-file.el
separates the directory search from the file-name search, while you
keep them together, but the approaches are equivalent, and each one
has its advantages.

Anyway, I'm not saying that find-file.el can support everything you
wanted to support OOTB.  But it can support most of it, and it can be
extended to support the rest.  So it sounds strange to me to come up
with an entirely new feature, implemented from scratch and with an
incompatible API, when these two have such a significant functionality
overlap.