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: Mon, 10 Feb 2020 18:02:51 +0200 Message-ID: <83wo8ubfbo.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> 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="25917"; 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 Mon Feb 10 17:04:16 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 1j1BXk-0006bm-BW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Feb 2020 17:04:16 +0100 Original-Received: from localhost ([::1]:35546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1BXj-0003EP-C6 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Feb 2020 11:04:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44315) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1BXa-0003Dx-VG for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 11:04:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j1BXV-00009O-Qr for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 11:04:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49314) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j1BXV-00009B-NY for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 11:04:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j1BXV-0002xu-Jz for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 11:04: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: Mon, 10 Feb 2020 16:04: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.158135059211310 (code B ref 37189); Mon, 10 Feb 2020 16:04:01 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 10 Feb 2020 16:03:12 +0000 Original-Received: from localhost ([127.0.0.1]:55287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1BWi-0002wM-Cb for submit@debbugs.gnu.org; Mon, 10 Feb 2020 11:03:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1BWg-0002w5-Lg for 37189@debbugs.gnu.org; Mon, 10 Feb 2020 11:03:11 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j1BWb-0007TQ-40; Mon, 10 Feb 2020 11:03:05 -0500 Original-Received: from [176.228.60.248] (port=3301 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j1BWZ-0002jO-CC; Mon, 10 Feb 2020 11:03:04 -0500 In-reply-to: <5622487d-a21f-49cf-5420-21f87415af4f@gmx.de> (message from Wolfgang Scherer on Sun, 9 Feb 2020 14:57:12 +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:175878 Archived-At: > From: Wolfgang Scherer > Cc: dgutov@yandex.ru, 37189@debbugs.gnu.org > Date: Sun, 9 Feb 2020 14:57:12 +0100 > > "pattern" is a generic term, which does not imply a specific syntax. > > "wildcard specification" is a pattern following the rules of a glob(7) > syntax variant. > > "regexp pattern" implies one of the regular expression syntaxes > (regex(7), Emacs, Perl, Python, ...). Got it, thanks. >     +-------------+-----------------+---------------+-----------------+--------------------+ >     | `file path` | glob(7)         | anchored glob | Hg `regex`      | Bzr `regex`        | >     +=============+=================+===============+=================+====================+ >     | test[56].xx |   test\[56].xx  | /test\[56].xx | ^test\[56]\.xx$ | RE:^test\[56]\.xx$ | >     |             |   test[[]56].xx |               |                 |                    | >     +-------------+-----------------+---------------+-----------------+--------------------+ >     | simple.txt  |   simple.txt    | /simple.txt   | ^simple\.txt$   | RE:^simple\.txt$   | >     |             |   simple[.]txt  |               |                 |                    | >     +-------------+-----------------+---------------+-----------------+--------------------+ Just a note: this table might be interpreted to mean that hg and bzr only support regexes in their ignore files, but that is of course false: they also support glob-style widlcards. >     The correct escaping of FILE can only be determined by the >     backend. Therefore neither vc-dir-ignore nor lisp code calling >     vc-ignore can escape the FILE parameter correctly without support >     from the backend. This makes pattern input for FILE only useful >     during interactive calls. > > Even, if it was magically possible to determine the correct > pattern in the frontend, submitting an anchored > glob "/some-sub/file.txt" to `vc-ignore` would be interpreted as > an absolute path. > > In other words, the API specificaton > >   [...] FILE is a wildcard specification, either relative to >   DIRECTORY or absolute. > > which asks for implementing the pattern use case inextricably > mixed with the file path use case, is nonsense. > > It also means, that all of the backend functions which currently > demand a pattern are absolutely useless. I don't think I agree. While the direction in which you propose to move -- which AFAIU is to offer 2 different commands, one to ignore a file name, the other to ignore a file pattern -- is definitely possible, I question its necessity. In the use cases I have in mind, the ignore file-or-pattern always comes from the user, because only the users can decide which files they want to ignore. And the users always know both which backend they are working with, and whether the file-or-pattern is a filename or a pattern. It follows that we can ask the users to escape and anchor the file-or-pattern argument they type, and that is not an unreasonable expectation. In fact, your approach expects the same from the users, because you are asking the users to decide which of the two commands to invoke in each case. If there are no flaws in my way of reasoning, then I think the resulting changes will be much less extensive, because the same vc-ignore command can then be used for both ignoring a specific file and for ignoring a pattern of any kind. We just need to document that if the argument is a pattern of any kind, the user will have to make sure it is escaped and anchored for the backend to DTRT. A further advantage of my proposal is that we don't need to write any backend-specific code to escape special characters in patterns, because we expect the users to do that. This concept is similar to what we do in commands such as "M-x grep", where we expect the users to escape special characters in the command-line arguments to be passed to Grep the program via the shell. Am I missing something?