From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Comparison of tools to search for related files Date: Tue, 06 Sep 2022 15:59:07 +0300 Message-ID: <837d2gk6as.fsf@gnu.org> References: <87tu5lv92m.fsf@cassou.me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5422"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, larsi@gnus.org To: Damien Cassou Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 06 16:33:59 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVZeH-00016A-Sv for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 16:33:58 +0200 Original-Received: from localhost ([::1]:36236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oVZeG-0008V4-On for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 10:33:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVYAq-00059R-WA for emacs-devel@gnu.org; Tue, 06 Sep 2022 08:59:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40540) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVYAp-0002wd-No; Tue, 06 Sep 2022 08:59:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=4LzIKiwJCO2UvvSqzo24DEeIQb4yHm5uWpR9Pi+XWrA=; b=A6thd/Q3JfyX5tZOmsQM viUK8uMBs6e6e8DHOf4x8GpDNb1B7oIa4NDW2l02h5KvIhVajRHd4l5Von+P0ioYoieyxRzQKSJz0 RYjMbeHSttkVsVuXqWTnEGR/RcEqkn2Jghh6wbV5LMUm5AzHxPlhBKj8vk93n+T2z/brDpjxa59vZ rwlR/tF6TgoI5RXVchyz7CLMnBqhTXOJio9qWIbKr0Zxn4Q2h6D8MhPKVyGRqUa1lAUh+ngfH4vOB SwORmz3shX9GwwC24KrXQqN72XCsakLpBFM6NedKsRB1VhkMXvwJBOoO1KCsS9lX8kdQU/eHiPvB6 /+faiCIVmcwRdg==; Original-Received: from [87.69.77.57] (port=4203 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVYAp-0003fT-63; Tue, 06 Sep 2022 08:59:27 -0400 In-Reply-To: <87tu5lv92m.fsf@cassou.me> (message from Damien Cassou on Mon, 05 Sep 2022 22:51:29 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:294787 Archived-At: > From: Damien Cassou > Cc: Eli Zaretskii , Lars Ingebrigtsen > Date: Mon, 05 Sep 2022 22:51:29 +0200 > > I'm implementing jumprel to jump from a file to related files (e.g., its > tests, its CSS, its .h header file…). During discussion for bug#57564, > Eli asked me > > How will this be different from what we already have: > > • the find-file.el package > • the new command 'find-sibling-file' > > I didn't know about these 2 packages so thank you very much for telling > me about them. Because I just learned about them, my description and > comparison below might be incomplete. > > In the following I will compare the packages according to my 2 use > cases: [...] Thank you for the details and the summaries. My point in mentioning the existing features is that from where I stand, it is much better to extend existing features rather than to introduce a completely separate package with a different implementation. I think having several different overlapping features in core is not good for maintenance. I was even unhappy when Lars introduced find-sibling-file, which IMO could have been implemented on top of find-file.el with some extensions. So the fact that neither of the 2 existing features fits your use case doesn't invalidate what I was trying to convey. I didn't claim that one or both of the existing features already support your needs, I wanted to urge you to consider how one of them could be extended to cover your use cases. AFAIU, the question whether such extensions are reasonably practical and will yield convenient solutions -- that question still stands. Thanks.