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: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.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: Wed, 08 Jun 2022 13:39:59 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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\\'")))

That's not about extensions, but finding a related file in a different
directory.

> 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.

I understand your point, but I don't feel there's much to be gained
trying to merge these two things that have somewhat different use cases.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




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.