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