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: Fri, 03 Jul 2020 08:55:42 +0300 Message-ID: <83eeptw3a9.fsf@gnu.org> References: <87r1ulxk48.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> <831rluxcll.fsf@gnu.org> <83r1ttx196.fsf@gnu.org> <9c09977f-18c2-facd-c1e2-e7fe488ee92c@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32676"; 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 Fri Jul 03 07:56:10 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 1jrEgD-0008Nl-MA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Jul 2020 07:56:09 +0200 Original-Received: from localhost ([::1]:37540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrEgC-0001HD-M1 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Jul 2020 01:56:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46454) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jrEg6-0001H5-NV for bug-gnu-emacs@gnu.org; Fri, 03 Jul 2020 01:56:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44632) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jrEg6-0002kr-Du for bug-gnu-emacs@gnu.org; Fri, 03 Jul 2020 01:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jrEg6-0000Y3-Be for bug-gnu-emacs@gnu.org; Fri, 03 Jul 2020 01:56: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: Fri, 03 Jul 2020 05:56: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.15937557522089 (code B ref 41821); Fri, 03 Jul 2020 05:56:02 +0000 Original-Received: (at 41821) by debbugs.gnu.org; 3 Jul 2020 05:55:52 +0000 Original-Received: from localhost ([127.0.0.1]:56178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrEfw-0000Xd-3k for submit@debbugs.gnu.org; Fri, 03 Jul 2020 01:55:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrEfu-0000XR-03 for 41821@debbugs.gnu.org; Fri, 03 Jul 2020 01:55:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48570) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrEfn-0002YN-L1; Fri, 03 Jul 2020 01:55:43 -0400 Original-Received: from [176.228.60.248] (port=1569 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jrEfm-0004YJ-US; Fri, 03 Jul 2020 01:55:43 -0400 In-Reply-To: <9c09977f-18c2-facd-c1e2-e7fe488ee92c@yandex.ru> (message from Dmitry Gutov on Thu, 2 Jul 2020 22:37:36 +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:182655 Archived-At: > Cc: 41821@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Thu, 2 Jul 2020 22:37:36 +0300 > > > But Emacs is more than just an IDE, it can be and is used for many > > other jobs. For example, I customary take a break from my development > > work to read email, and when doing so I might issue some Grep command > > that I need for some email message I'm writing. I don't think it's > > right for Emacs to assume that every Grep I do is necessarily related > > to the last project I was working on (which could be days in the past, > > btw). This way, we would need a command to "get out of" (or "close") > > the project, which I think would be both a nuisance and absurd. > > But it's for a default value (one you can insert using M-n, or not). > Most users won't even notice this. You assume that most users don't know about or use M-n? I do it all the time, and would like to think others do as well. > >> The use case is 'M-x xref-find-refereces' and xref backends which don't > >> override xref-backend-references. In which case this command searches > >> the current project using general purpose tools (one of semantic symref > >> tools, or Grep). > >> > >> But xref backend != current project. They're technically and > >> theoretically independent. > > > > So you are saying that it might bring me the wrong references once in > > a while? That's not good, is it? > > If an xref backend doesn't define the xref-backend-references method, > the alternative is no references at all. The alternative could be to start with the current directory, or ask the user. But do we have xref backends that don't define the xref-backend-references method? If so, which ones don't? > Whether the current implementation will give wrong results, and how > often, is difficult for me to predict. It also depends on what we > consider a "wrong reference". etags and elisp backends don't always give > perfect results for "find definition" either. "Imperfect" and "completely wrong" is not the same at all. Searching the wrong directory hierarchy will get you the latter.