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#37189: 25.4.1: vc-hg-ignore implementation is missing Date: Wed, 12 Feb 2020 20:34:55 +0200 Message-ID: <83o8u3r6wg.fsf@gnu.org> References: <1ba53ae2-42a4-3ab3-d4f2-2ceae565d198@gmx.de> <52917e6f-2f00-25cf-4353-dfb40287d0ea@gmx.de> <83pnkrdpb3.fsf@gnu.org> <679942e8-abe9-b0fc-720d-75a54d8d0b5a@gmx.de> <95da41e8-7a55-a15c-cfa7-d70366f9ee6b@gmx.de> <412195c1-e196-12af-933b-0312f5075847@yandex.ru> <57825d73-27a4-d5f5-8198-a172796a558a@gmx.de> <1ebc6077-9175-65ba-4996-282bb2c8eca5@yandex.ru> <6145d6f6-37a8-7166-731b-57669086b145@gmx.de> <838slmk90j.fsf@gnu.org> <83h806gp2w.fsf@gnu.org> <8336bmg1o9.fsf@gnu.org> <2354821b-5c1e-f9e3-3a64-4ff978ded33b@gmx.de> <83sgjkdev5.fsf@gnu.org> <3fb73dbc-bf31-233b-4afc-2147c4ffd5b7@gmx.de> <5622487d-a21f-49cf-5420-21f87415af4f@gmx.de> <83wo8ubfbo.fsf@gnu.org> <83zhdpqbas.fsf@gnu.org> <2c8419ae-723d-c7ae-a60e-59d1b1cbc2c1@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="47472"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 37189@debbugs.gnu.org, dgutov@yandex.ru To: Wolfgang Scherer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 12 19:36:20 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 1j1wrx-000CB4-MQ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Feb 2020 19:36:17 +0100 Original-Received: from localhost ([::1]:41876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1wrw-0005l8-OT for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Feb 2020 13:36:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54312) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1wrj-0005ko-C5 for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 13:36:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j1wri-0007UE-0z for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 13:36:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53066) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j1wrh-0007U4-Tg for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 13:36:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j1wrh-0007k4-RI for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2020 13:36:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Feb 2020 18:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37189 X-GNU-PR-Package: emacs Original-Received: via spool by 37189-submit@debbugs.gnu.org id=B37189.158153250529691 (code B ref 37189); Wed, 12 Feb 2020 18:36:01 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 12 Feb 2020 18:35:05 +0000 Original-Received: from localhost ([127.0.0.1]:59039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1wqm-0007ip-HC for submit@debbugs.gnu.org; Wed, 12 Feb 2020 13:35:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39123) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1wql-0007iI-DI for 37189@debbugs.gnu.org; Wed, 12 Feb 2020 13:35:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j1wqg-0006W6-3r; Wed, 12 Feb 2020 13:34:58 -0500 Original-Received: from [176.228.60.248] (port=1417 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j1wqe-00089w-WA; Wed, 12 Feb 2020 13:34:57 -0500 In-reply-to: <2c8419ae-723d-c7ae-a60e-59d1b1cbc2c1@gmx.de> (message from Wolfgang Scherer on Tue, 11 Feb 2020 23:28:10 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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:175976 Archived-At: > Cc: dgutov@yandex.ru, 37189@debbugs.gnu.org > From: Wolfgang Scherer > Date: Tue, 11 Feb 2020 23:28:10 +0100 > > I do not actually give up:-). I just think it is easier to > convince you that the "file path" use case is already supposed to > be supported by Emacs. What is the "file path use case"? To what commands does it pertain? > >> A command that locates an ignore file, but can only do so, if the > >> default-directory is already the one containing the ignore > >> file (always true for SRC, CVS, SVN) > > Is locating the ignore file a separate issue? AFAICT, we currently > > always look for the ignore file in the repository root, is that right? > > If so, are you proposing a new feature here, where we would support > > ignore files in subdirectories? > > I am not (yet) talking about a new feature, but about the "file path" > use case in *vc-dir-mode* for per-directory VCSs (CVS, SVN, SRC). Do we support per-directory ignore files in the current codebase? I think we don't: I see that every backend simply looks in the root of the repository. If I'm right, then supporting per-directory ignore files is an enhancement, which should then be considered separately from fixing bugs in the current code. > E.g., in this *vc-dir-mode* buffer it is not possible to use *vc-ignore* > in "pattern" mode:for adding an ignore pattern for SVN to `sub/` > or for SVN or CVS in `sub/sub2/`: > > ``` {.sourceCode .text} > VC backend : SVN > Working dir: /the/top > >                   .svn >                   sub/CVS >    edited         sub/.cvsignore >                   sub/sub2/CVS >                   sub/sub2/RCS >    edited         sub/sub2/.cvsignore > ``` > > In case of nested repositories with different VC backends (e.g. in > directories `sub` and `sub/sub2` above), it may even become necessary to > invoke *vc-dir* with a prefix argument to specify the appropriate VC > manually. I don't think we support such nesting at this time, do we? > > Since vc-dir-ignore computes the file name(s) to add to the ignore > > file, it indeed will need to escape all the special characters in file > > names it will add, before it invokes vc-ignore. You are right here. > In order to know, what part of the filename must be used, it is > necessary to know the location of the ignore file, which is only known > by the backend. If I'm right in saying that we currently support only ignore files in the root of the repository, then this is not an issue. And even if it is an issue, we already have a backend method to find the ignore file, so we could use it (or modify it if needed). > >> They also expect a visual feedback, that the operation had the > >> desired effect, as they have come to expect from all the other > >> commands in `vc-dir-mode`. > > AFAICT, the command does provide feedback. Or maybe I misunderstand > > what feedback you had in mind. > > vc-dir-ignore currently does not provide the normal feedback, I only just now put it in: > >       (vc-dir-resynch-file file) OK, so you _did_ mean a different kind of feedback. What I meant is the "/foo/bar/.ignore written" feedback. > > The old behavior of vc-ignore was not broken for interactive > > invocations. It was broken (in rare cases) for invocations from > > vc-dir-ignore, and that can IMO be fixed without affecting user-facing > > behavior. So I see no backward-incompatible changes here. > Sorry, not *rare* but **all** cases! The invocation from vc-dir-ignore > placed an **absolute file path** into the ignore file. That's not what I see, at least not with Git as the backend. I see only the basename of the file being added to the ignore file. Can you show a use case where an absolute file name is written into the ignore file by vc-dir-ignore? > > My point is that Grep patterns can include characters special for the > > shell, but we never escape them ourselves, we rely on the user to > > escape them as needed. > > The pattern is not prompted for separately! True, but I don't think this detail matters for the purposes of the analogy. > There is no way, that the pattern argument for the *grep* command > could be reliably parsed and quoted. Of course it's possible. It's just very complex and tedious, and more importantly, requires the user to play by certain rules: e.g., the user must agree never to quote/escape the patterns he/she types. Instead, we give the user the freedom to decide when to quote and when not to quote. The same should be done with vc-ignore (but not with vc-dir-ignore).