bug#37189: 25.4.1: vc-hg-ignore implementation is missing

[Eli Zaretskii <eliz@gnu.org>]

> From: Wolfgang Scherer <Wolfgang.Scherer@gmx.de>
> 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?