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.bugs Subject: bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects Date: Thu, 02 Jul 2020 16:36:54 +0300 Message-ID: <831rluxcll.fsf@gnu.org> References: <87r1ulxk48.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> <83tuyzs2np.fsf@gnu.org> <87h7uuj1v3.fsf@mail.linkov.net> <87h7utjx75.fsf@mail.linkov.net> <3f9e85ba-66a9-abd0-61bf-800ea8bb4ee3@yandex.ru> <87eepw5nlt.fsf@mail.linkov.net> <83v9j7xpoj.fsf@gnu.org> <990a9046-c4e6-efb2-01dd-60198994127b@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5665"; 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 Jul 02 15:43:11 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 1jqzUc-0001Ng-Tg for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jul 2020 15:43:10 +0200 Original-Received: from localhost ([::1]:45930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jqzUb-00033F-Uk for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jul 2020 09:43:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jqzPe-0002zR-Or for bug-gnu-emacs@gnu.org; Thu, 02 Jul 2020 09:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43049) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jqzPe-0004TQ-Da for bug-gnu-emacs@gnu.org; Thu, 02 Jul 2020 09:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jqzPe-0007R3-BL for bug-gnu-emacs@gnu.org; Thu, 02 Jul 2020 09:38: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, 02 Jul 2020 13:38: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.159369702828518 (code B ref 41821); Thu, 02 Jul 2020 13:38:02 +0000 Original-Received: (at 41821) by debbugs.gnu.org; 2 Jul 2020 13:37:08 +0000 Original-Received: from localhost ([127.0.0.1]:54595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jqzOm-0007Pu-8i for submit@debbugs.gnu.org; Thu, 02 Jul 2020 09:37:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jqzOi-0007PO-H3 for 41821@debbugs.gnu.org; Thu, 02 Jul 2020 09:37:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60876) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jqzOc-0004H3-9n; Thu, 02 Jul 2020 09:36:58 -0400 Original-Received: from [176.228.60.248] (port=4959 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jqzOb-0007uS-MS; Thu, 02 Jul 2020 09:36:58 -0400 In-Reply-To: <990a9046-c4e6-efb2-01dd-60198994127b@yandex.ru> (message from Dmitry Gutov on Wed, 1 Jul 2020 23:24:19 +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:182633 Archived-At: > Cc: 41821@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Wed, 1 Jul 2020 23:24:19 +0300 > > On 01.07.2020 17:42, Eli Zaretskii wrote: > > Like you, Dmitry, I'm a bit uneasy with mixing the two sets of > > features. We should decide on some concept and try to stick to it; > > right now, it seems to me that we prefer to have specialized commands > > in project.el rather than inject project.el-specific nits into > > commands outside project.el, which I think could be a slippery slope. > > In my previous message I drew a line, of sorts, where I think it's okay > to suggest directories to search in in rgrep from known project roots. I > do think it's okay. > > I'm not sure if I understand your position, because you say you agree, > but then make a one-directional statement. I agreed with your general doubt whether the proposal is TRT. My motivation is somewhat different. > > Why isn't that a better approach? I don't think it's wise to blur the > > difference between using project.el features and the VC back-end > > features that support them. If someone wants to use project.el in VC > > commands, let them use project.el commands, not VC commands. That > > way, Emacs will know that some kind of project is being worked on, and > > could offer more targeted support for such users. > > Not sure that's going to result in optimal user experience. After all, > simply having a copy of every command, but acting on a project, would > make it 2x the number of commands. > > And project-rgrep, on the other hand, would probably search the current > project root without prompting. Unlike the proposed change to rgrep, > which only makes it a suggestion. I just fear that this is a slippery slope: we will eventually need to inject this into many GP commands, "for consistency". > Another long-term violation of your idea is the default definition of > xref-backend-references. It uses the current project. You could say that > mixes up abstractions as well, but it's just too handy to implement this > way. I don't think I understand the issue and the use case, sorry.