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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: dgutov@yandex.ru, 37189@debbugs.gnu.org
> From: Wolfgang Scherer <Wolfgang.Scherer@gmx.de>
> Date: Tue, 11 Feb 2020 02:45:41 +0100
> 
> I suggest, we stop talking about the use case, where `vc-ignore`
> is called interactively, I will let you have your opinion,
> although I strongly disagree

If you strongly disagree, then why do you give up so easily on your
opinion?  I didn't yet make up my mind, so maybe you will be able to
convince me.

> and the unsolved problem of interactively locating the correct
> ignore file makes it ultimately hilarious:
> 
> 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?

> Since the escaping must also be correct, I'm probably better off
> locating and editing the ignore file manually. Inserting the output
> of "ls -1" and editing away - as I sometimes do - is much more
> convenient than calling `vc-ignore` multiple times and repeating
> more complex editing of an absolute file path each time in the
> minibuffer.

vc-ignore is not only for adding ignored files/patterns, it is also
for deleting entries in the ignore files.  And that functionality
definitely needs the users to type the patterns exactly as they are in
the ignore file.

> However, there is a use case that you keep avoiding to comment
> on, namely pressing "G" in `vc-dir-mode`, which calls
> `vc-dir-ignore`, which in turn calls `vc-ignore`
> **programmatically** with an absolute file path. It has been
> officially supported by Emacs since 2013. I did not invent it and
> I did not alter its API.
> 
> Since there is no interactive prompt whatsoever for a user to
> 
> 1. properly construct an escaped pattern and
> 2. specify the directory, where the search for the ignore file
>    should start,
> 
> the function called to ignore the file must consequently escape
> and anchor it properly, just like any command that uses
> `shell-quote-args` because the use case requires it and the
> purpose of the argument is well-known.
> 
> How do you plan to support this use case?

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.

> According to your opinion `vc-ignore` can only be used
> **interactively** by a learned expert user, who wants to make
> ignore file administration even more complicated by editing
> random ignore files without any feedback.

Given that vc-ignore can also delete a an entry from the ignore file,
and given that we supported patterns there (albeit with bugs) for some
time, I don't see how we can change that in a radical way like you
suggest.

> So it is the wrong candidate for a noob user of `vc-dir-mode`
> who just wants to ignore the selected files literally without
> worrying about ignore files and escaping.

I agree with you wrt vc-dir-ignore.

> 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.

> If you are just worried, that somebody will use `vc-ignore` and
> expect the old broken behavior

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.

> > 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.
> That is not at all comparable, since there is no use case "search
> for file path in a bunch of files".

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.