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

Previous Next

Package: emacs;

Reported by: dick.r.chiang <at> gmail.com

Date: Fri, 3 Jun 2022 08:19:02 UTC

Severity: normal

Found in version 29.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55778 <at> debbugs.gnu.org, dick.r.chiang <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: bug#55778: 29.0.50; [PATCH] M-. into a .gz; we've all been there.
Date: Tue, 07 Jun 2022 14:31:20 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dick.r.chiang <at> gmail.com,  55778 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Tue, 07 Jun 2022 11:13:31 +0200
> 
> Eli Zaretskii <eliz <at> 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.




This bug report was last modified 3 years and 63 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.