From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects Date: Thu, 25 Jun 2020 16:20:10 +0300 Message-ID: <83tuyzs2np.fsf@gnu.org> References: <87r1ulxk48.fsf@mail.linkov.net> <7164426e-8c37-8839-64da-563cfa829b53@yandex.ru> <87mu50j5cu.fsf@mail.linkov.net> <87y2oh8fdv.fsf@mail.linkov.net> <87366ohw5z.fsf@mail.linkov.net> <878sge7jls.fsf@mail.linkov.net> <7e136435-7123-fa42-e4a8-66b82e6595da@yandex.ru> <87pn9pxris.fsf@mail.linkov.net> <83d05ottnw.fsf@gnu.org> <0b42f540-f779-446b-4411-8dae3a50d09d@yandex.ru> <837dvwtrv1.fsf@gnu.org> <835zbgtqps.fsf@gnu.org> <625de669-0715-1467-0bd1-84328b4bee5f@yandex.ru> <83wo3ws4g8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="63173"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41821@debbugs.gnu.org, juri@linkov.net To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 25 15:21:09 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1joRoT-000GHt-Hv for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 15:21:09 +0200 Original-Received: from localhost ([::1]:59928 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1joRoS-0001NP-Hx for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 09:21:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1joRoM-0001NH-RQ for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 09:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56619) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1joRoM-0002IJ-IH for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 09:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1joRoM-0004UF-Bk for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 09:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Jun 2020 13:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41821 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 41821-submit@debbugs.gnu.org id=B41821.159309124217200 (code B ref 41821); Thu, 25 Jun 2020 13:21:02 +0000 Original-Received: (at 41821) by debbugs.gnu.org; 25 Jun 2020 13:20:42 +0000 Original-Received: from localhost ([127.0.0.1]:39932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joRo2-0004TM-E2 for submit@debbugs.gnu.org; Thu, 25 Jun 2020 09:20:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joRo0-0004T6-Bm for 41821@debbugs.gnu.org; Thu, 25 Jun 2020 09:20:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39486) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1joRnu-00026n-J0; Thu, 25 Jun 2020 09:20:34 -0400 Original-Received: from [176.228.60.248] (port=1652 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1joRnt-0006RN-Bu; Thu, 25 Jun 2020 09:20:34 -0400 In-Reply-To: (message from Dmitry Gutov on Wed, 24 Jun 2020 21:44:01 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182366 Archived-At: > Cc: 41821@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Wed, 24 Jun 2020 21:44:01 +0300 > > >> Okay, but that new function delegates to code in project.el anyway, what > >> would be the practical difference? > > > > It would be somewhat cleaner, I think. > > That's the whole reason? Well, the whole issue at hand is a rather minor one. > I mean, I'm not going to protest against an > extra wrapper, but that doesn't sound like it would solve any practical > problems. "Cleaner" solutions often have those. In general, code that doesn't _have_ to be preloaded, shouldn't be. If nothing else, it keeps the memory footprint of a bare Emacs smaller, and thus prevents us from slipping down the slippery slope of memory bloat. > > Actually, I have a question: isn't project.el conceptually a > > higher-level feature than VC? If so, how come VC wants to call > > project.el? > > VC doesn't serve project.el only. project.el doesn't solely use VC. Yes, but that's not what I asked. I have the impression that project.el builds on VC as one project back-end, so it sounds strange to me that VC turns around and calls project.el for something. > Apparently Juri wants to use certain data collected and saved by > project.el UI, for convenience. After reading the original complaint that Juri says he wanted to resolve, I still don't understand why we use project.el for that. No one says that every relevant VC repository must have been visited as a project as part of the current Emacs session. Why not have some relevant history in VC itself? > The alternative would be to introduce some separate history-keeping > feature for the cases when VC code needs to ask the user to point to a > VC repository. Exactly. Why not? Juri answers: > It wouldn't be rational to duplicate this feature. > Rather I think the project-list should be updated > even on using vc commands such as 'C-x v d', i.e. > project and vc should be more tightly integrated. I don't think I agree. First, I don't see any duplication here: people could (and do) use VC directly, not through project.el, in which case project.el history wouldn't help. Moreover, using a command such as "C-x v d" doesn't mean I want project.el record that, again because I might be using project.el commands for projects that aren't based on VC. And if the history is collected by VC, it could be made available to project.el commands that call into VC, right? Anyway, if you-two feel strongly about keeping the current solution, i.e. having VC commands use project.el-collected history, I'd appreciate if that function could be moved to vc.el from vc-hooks.el, thanks in advance.