unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Wolfgang Scherer <Wolfgang.Scherer@gmx.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 37189@debbugs.gnu.org, dgutov@yandex.ru
Subject: bug#37189: 25.4.1: vc-hg-ignore implementation is missing
Date: Sun, 9 Feb 2020 14:57:12 +0100	[thread overview]
Message-ID: <bd9a18c9-a1ce-9776-ec83-dbeeba26cf75@gmx.de> (raw)
In-Reply-To: <3fb73dbc-bf31-233b-4afc-2147c4ffd5b7@gmx.de>

Let me clarify this one last time.

> The "pattern" use case is not the "wildcard" use case. "pattern" is an unspecified string, while "wildcard" is backend specific. For SVN it is a glob(7) expression without subdirectories (otherwise it does not match anything).
>
"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, ...).

Citing from 4.2.1. file pathes are not patterns (http://sw-amt.ws/emacs/doc/_build/html/emacs-vc-ignore-feature.html#file-pathes-are-not-patterns):

    Assuming that a file path is always a pattern that matches the
    file path unambiguously is simply wrong.

    When ignoring a specific file path and nothing but that file
    path, a pattern must be constructed that matches the file path
    exactly. The syntax for this pattern is backend specific and the
    pattern is generally not the file path itself. In other words: it
    is an exception that a file path and the exactly matching pattern
    are identical strings. Specifically, if a file path contains a
    character with special meaning in the pattern syntax, then the
    matching pattern cannot be identical to the file path since the
    special character must be escaped.

    +-------------+-----------------+---------------+-----------------+--------------------+
    | `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  |               |                 |                    |
    +-------------+-----------------+---------------+-----------------+--------------------+

    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.

Therefore the API change request is specifically:

    (defun vc-ignore (file-or-pattern &optional directory remove as-is)
      "Ignore FILE-OR-PATTERN under VCS of DIRECTORY.

    DIRECTORY defaults to `default-directory' and is used to
    determine the responsible VC backend.

    When REMOVE is non-nil, remove FILE-OR-PATTERN from the list of
    ignored files.

    If AS-IS is nil, FILE-OR-PATTERN is considered a file path that
    must be escaped and anchored. The directory name of
    FILE-OR-PATTERN expanded against DIRECTORY is used to determine
    the ignore file.  The effective pattern consists of the file path
    relative to the directory of the ignore file, properly escaped
    and anchored by the VC backend.

    If AS-IS is non-nil, FILE-OR-PATTERN is considered a pattern that
    should not be modified.  DIRECTORY is used to determine the
    ignore file."






  reply	other threads:[~2020-02-09 13:57 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26  0:21 bug#37189: 25.4.1: vc-hg-ignore implementation is missing Wolfgang Scherer
     [not found] ` <handler.37189.B.15667808855126.ack@debbugs.gnu.org>
2019-08-26 23:25   ` bug#37189: Acknowledgement (25.4.1: vc-hg-ignore implementation is missing) Wolfgang Scherer
2019-08-27  7:45     ` Eli Zaretskii
2019-08-28  1:46       ` bug#37189: *** GMX Spamverdacht *** " Wolfgang Scherer
2019-08-28  6:16         ` Eli Zaretskii
2019-08-29  1:23           ` bug#37189: 25.4.1: vc-hg-ignore implementation is missing Wolfgang Scherer
2019-08-29  0:38         ` Wolfgang Scherer
2019-08-29 15:52           ` Wolfgang Scherer
2019-12-25  0:16             ` Dmitry Gutov
2020-01-05  3:46               ` Wolfgang Scherer
2020-01-05  8:58                 ` Andreas Schwab
2020-01-05 17:25                   ` Wolfgang Scherer
2020-01-14  1:14                 ` Dmitry Gutov
2020-02-01  1:20                   ` Wolfgang Scherer
2020-02-01  8:27                     ` Eli Zaretskii
2020-02-03  1:16                       ` Wolfgang Scherer
2020-02-04 18:55                         ` Eli Zaretskii
2020-02-05  5:18                           ` Wolfgang Scherer
2020-02-05 19:06                           ` Wolfgang Scherer
2020-02-07  9:57                             ` Eli Zaretskii
2020-02-08  9:57                               ` Dmitry Gutov
2020-02-08 19:45                                 ` Wolfgang Scherer
2020-02-08 20:05                                   ` Eli Zaretskii
2020-02-08 23:12                                     ` Wolfgang Scherer
2020-02-09 13:57                                       ` Wolfgang Scherer [this message]
2020-02-09 14:07                                         ` Wolfgang Scherer
2020-02-09 13:57                                       ` Wolfgang Scherer
2020-02-10 16:02                                         ` Eli Zaretskii
2020-02-11  1:45                                           ` Wolfgang Scherer
2020-02-11 17:32                                             ` Eli Zaretskii
2020-02-11 22:28                                               ` Wolfgang Scherer
2020-02-12 18:34                                                 ` Eli Zaretskii
     [not found]                                                   ` <6f3ba261-e1f9-cf19-cc22-ec8c24cf3298@gmx.de>
2020-02-12 23:20                                                     ` Wolfgang Scherer
2020-02-13  1:18                                                       ` Wolfgang Scherer
2020-02-13 15:09                                                         ` Eli Zaretskii
2020-02-13 16:30                                                           ` Wolfgang Scherer
2020-02-13 23:43                                                           ` Richard Stallman
2020-02-14  1:49                                                             ` Wolfgang Scherer
2020-02-16  2:29                                                               ` Richard Stallman
2020-02-13 15:21                                                         ` Eli Zaretskii
2020-02-13 23:40                                                           ` Dmitry Gutov
2020-02-14  9:23                                                             ` Eli Zaretskii
2020-02-21  0:05                                                               ` Dmitry Gutov
2020-02-21  8:10                                                                 ` Eli Zaretskii
2020-02-21 22:22                                                                 ` Wolfgang Scherer
2020-02-22  7:44                                                                   ` Eli Zaretskii
2020-02-22 13:46                                                                     ` Wolfgang Scherer
2020-02-22 14:30                                                                       ` Eli Zaretskii
2020-02-22 19:14                                                                         ` Dmitry Gutov
2020-02-22 22:04                                                                           ` Wolfgang Scherer
2020-02-22 23:32                                                                         ` Wolfgang Scherer
2020-02-23 15:20                                                                           ` Eli Zaretskii
2020-02-23 19:16                                                                             ` Wolfgang Scherer
2020-02-22 19:30                                                                   ` Dmitry Gutov
2020-02-22 22:00                                                                     ` Wolfgang Scherer
2020-02-22 23:58                                                                       ` Dmitry Gutov
2020-02-23  0:29                                                                         ` Wolfgang Scherer
2020-02-24 23:07                                                                           ` Dmitry Gutov
2020-02-25  2:22                                                                             ` Wolfgang Scherer
2020-03-19 23:42                                                                               ` Dmitry Gutov
2020-07-03 20:53                                                                                 ` Wolfgang Scherer
2020-07-03 21:49                                                                                   ` Dmitry Gutov
2020-02-12 17:23                                               ` Wolfgang Scherer
2020-02-09 13:57                                       ` Wolfgang Scherer
2020-02-08 23:59                                     ` Wolfgang Scherer
2020-02-09 21:06                               ` Wolfgang Scherer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd9a18c9-a1ce-9776-ec83-dbeeba26cf75@gmx.de \
    --to=wolfgang.scherer@gmx.de \
    --cc=37189@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).