From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Wolfgang Scherer Newsgroups: gmane.emacs.bugs Subject: bug#37189: 25.4.1: vc-hg-ignore implementation is missing Date: Wed, 5 Feb 2020 06:18:08 +0100 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="119441"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 Cc: 37189@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 05 06:19:34 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 1izD65-000Uvc-PU for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Feb 2020 06:19:33 +0100 Original-Received: from localhost ([::1]:41536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izD64-0003Ie-LK for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Feb 2020 00:19:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51503) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izD5c-0003IY-Kz for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 00:19:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izD5a-0003HV-EZ for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 00:19:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39067) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izD5a-0003Gq-A3 for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 00:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1izD5a-0007KI-5h for bug-gnu-emacs@gnu.org; Wed, 05 Feb 2020 00:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Wolfgang Scherer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Feb 2020 05:19:02 +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.158087989828110 (code B ref 37189); Wed, 05 Feb 2020 05:19:02 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 5 Feb 2020 05:18:18 +0000 Original-Received: from localhost ([127.0.0.1]:45040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1izD4s-0007JI-50 for submit@debbugs.gnu.org; Wed, 05 Feb 2020 00:18:18 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:42357) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1izD4q-0007J5-0i for 37189@debbugs.gnu.org; Wed, 05 Feb 2020 00:18:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580879889; bh=kIA8v8tqndzMunL7vnc9y/RoCSIMBdLGCWkU0bC5ZHE=; h=X-UI-Sender-Class:From:Subject:To:Cc:References:Date:In-Reply-To; b=SD7BtT5X6RRQ+14fCDQFzu+Ka20FEGz3+zbLtlsgVv9XerniBcnghl6c1bInuK2Za OTj9Rchp6DscKXB/p8vvP/+uW3Hj2vD3tGSiHVMGgy+nh4u0uMn2hXdG0tc4yvoK2j sRlZioRy5+HIJoyysId/7Jy7Kgt6dSla9kFUcI3c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from sheckley.simul.de ([87.160.210.52]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mqs0X-1jLdjM1pzd-00mtcK; Wed, 05 Feb 2020 06:18:09 +0100 Original-Received: from [127.0.0.1] (sheckley.simul.de [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sheckley.simul.de (Postfix) with ESMTPSA id 6344F19431C5; Wed, 5 Feb 2020 06:18:08 +0100 (CET) Openpgp: preference=signencrypt Autocrypt: addr=Wolfgang.Scherer@gmx.de; prefer-encrypt=mutual; keydata= xsDiBEb46IgRBACMHOAb1KNo1Ylk+ebri+4R+bG4tyKlqBlrpv8D9/ZwRdXSGt+0DyCHoaAd 7KW7noHapLe87DunABOjKG4nqTGv+dRiWuUBlp3I4aYRFDVa3Da+XnIYkMHKqhK59VEHQCdp Km42nuLS7TS+n99at9YwzTG6VBdOlBKTlRFngOjVLwCg1RGXJ6X3EjS1FKCQeXziURVpWlkD /2zY6Ayhxi62TS84VjikXrrmjXykAAaAmMVEyKKYb9L5pGlqiZz9g/K9xw1EUoZTYuaufquD v4rAGR58K/3V4CYfJLEeshMWiaXHvMmlxMznlG16/um4MvmR8B3r+cx0nOPK1JBdD2qrkNnF Mw8FB+zouLFB4Gt2IUC5IlOmZ8OQA/4qdU53CItzWsCr9Nux4L0qUlRweSmCnV8xGQ2wP5XI MawIQxxREvSrsYDG8cNnYETMg4iQFfIktwAoxCJvuFAwIB6ZxHGF4FcEZm64CXc2u7CmFLqt rVhXhIfMz9oEYC+HhGczGamn9ofbGTFd2hJEtPcQgWNR4f7+aKknmi2+OM0fV29sZmdhbmcg U2NoZXJlciA8d3NAc3ctYW10LndzPsJhBBMRAgAhBQJYmz3YAhsjBQsJCAcCBhUICQoLAgQW AgMBAh4BAheAAAoJEIUCr3Gr112VZZoAoLTBSTp1qGuNhLdXY04iaWCMYmHCAJ4kHPtQ6nTw kEq9qCHgVgXDaY7wjs7ATQRG+OiIEAQAhi0wjcxvA4tychg2NQuwBIf9LX/46l+74+QbewCn a4a+mw/9s5KY In-Reply-To: <83h806gp2w.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:KB0kaDQeV06PU4S1YOvumDI6LvyOacBF02husDOK4ifDeHQIH4V qlG+bafeL8z1/Uukn+ymYQko/FL9f3L61r/z5Jo+V/yqXnjWFqlRWo/outTdUJuBwE4zAo4 U+cQnPtwlXKiOleudqub4M4JBnXjgDA1hnzU3kIUGrPkpwW5ppV1m0ugD1/1TQIbahSgThM KyDZP0F2H7ja3aMsU+5/w== X-UI-Out-Filterresults: notjunk:1;V03:K0:VF6vXDTc+00=:3+aZK1e97pafjOgGl0pHhf bRNceWLXBcDOMjI+vPJvBZh4pXdnRS/20OoCKMK6br7QMWZYz9aRCPw/5g5KNQ9o8rtBkLb1O kozhbQMvwrE2xOwUXcBkYax88TMAOmzjeNLqfQXzrguE/vt5HrtnWi8v6KM1Rit6nO4n/r5wh QU+sv/LMDN4Z1SsToMJ1NWaDFDPkZrwRGYj1Felg3UElAeBZSLO0u/6Doq81Y4Noh7SwcWZjE Dbgq0YRtetBo7FuZpXrvvW5BA+Ym+TWeSw1U7VSmFkmpd/0sLHpy5Jte1wdgGt/Q4BotpMw8S 0yuIKFAK967jL8OW6pZ9hv6P7e1+eQSlOnC75N49R8K3kssy8BFWBzkb89Qkf2S83t+wdDj50 5wyVI0BOuuGcWIgut/3jD7GSoxaWPQUSy7xsJ84ExMBsl30Phl5xdk9OBjR5XYB/Z13OC/oqg DubRBYdVdfsz2PgUE4IeTGArla3dumV5uZ9ZB1U9EA98mC7zHLLki7yQgCcADkvlSbC+0qtmd p8qKdF+nByL73MqPPBO7cRXebtOQXiUcNb7HZnIFcetBJHdzOefZg2UcpBo80nlX3ctzHWM4n 6pMnuvEfDmtWjp7Chj4utB0rfsOGp3QxWUUafImaQLeh8P65XWIJbaoExfa62BaML8IHs/vnO ch0jrZDAyWd6nTDBHHwT/wj0bTOCAqTU5au7sjtWg6kKjmvQlKcM07Bpaz/Fd6bxe+0Vinpcj BdbOH+Ds8jzWiO9btDSIBe9914Ai4rGFFT8CiM7lCBpkisIYUNgiSuikNeS7ght7KMOSm+oJ 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:175686 Archived-At: >> Per-directory vs. per-tree >> ========================== > > ...I don't feel I understand better your view of what you describe as > fundamental design problems in this area. I'm saying that after > reading your description at least twice. You make many assertions and > tell what these features _should_ do, but there's little explanation > of _why_ these assertions are true or why the commands should do this > or that. Usually a design does not explain why things should be the way they are specified. Also, having extracted the initial code for `vc` ignore files in the previous post, I did not think it was necessary to do it again. I also assume familiarity with the code in question and the mechanisms of ignore files for at least CVS, Git and Hg. I think I have sufficiently shown that the original implemention of the ignore feature did not work correctly in a single case. If you disagree, just use emacs 26.3 and try to ignore files in `vc-dir-mode` or by calling `vc-ignore` interactively in some CVS, Git or Hg repositories. CVS will not work at all. As for Git, Hg, if you ignore anything below the root directory it will not work correctly. Even the entries on the root level are not properly anchored and/or escaped. I am just making this argument to show that an API change does not break anything, since it did not work to begin with. I have further tried to fix the problem with the minimum amount of effort, which worked for some of the accepted corrections, but it did not work for `vc-hg-ignore`, which is unfortunately my main use case. However, in order to fix `vc-hg-ignore` without a hack (recognition of regular expressions as implemented in the patch of this bug report), it is necessary to expand the API of `vc-ignore` and the corresponding backend functions by at least adding a flag that indicates, whether the file parameter should be treated as a filepath or a pattern. Other topics like per-subtree ignore files have not even been mentioned yet. But they do not need API changes and can therefore be implemented later as a change request for `vc-find-ignore-file`. Hint: the assumption that .gitignore or .hgignore are always relative to `vc-root-dir` is simply false. Since I cannot comfortably explain the matters in the Email text format, I have prepared a HTML version at http://sw-amt.ws/README-emacs-vc-ignore-feature.html#vc-ignore-api-change-request. The description contains a discussion of wildcard pattern escaping/anchoring and two detailed (non-exhaustive) tables with use cases showing the implementation to be incorrect (even with the latest changes). The tables show, that the function `vc-ignore` should be able to produce different output for the same FILE / DIRECTORY input (e.g. "fil?.ext" nil), when - submitted as filepath by `vc-dir-ignore` - submitted as a wildcard specification by an interactive invocation of `vc-ignore`. However, producing different output for the same input is inherently impossible for fully deterministic functions. Once that is understood, it becomes obvious, that the correct results can only be achieved, when the backend functions are supplied with additional information to determine whether a single file should be ignored (escaping the filepath properly) or whether a pattern should be added verbatim without escaping anything. Since the ignore file sub-system did not even work at all before the last series of changes and the current request for `vc-hg-ignore` cannot be fixed cleanly without API changes and also because the ignore sub-system would still be broken, my proposition is to fix the design. Hence the draft design with some identified use cases for your convenience. Feel free to ignore it and try to fix the problem another way. This is really all that is necessary to understand the problem. I have answered some further arguments, but they are really just repetitions. > Even the first step of your argument: that there's a > fundamental difference between per-directory and per-tree ignore specs > is left with almost no description of these fundamental differences. > I don't think I have a clear idea of why you think so. I am not sure, why such a description is needed. Although per-directory ignore files are simply a maximally reduced special case of per-tree ignore files, where all relative filepathes are identical to basenames, it is still not sufficient to implement only per-directory ignore files, since per-tree ignore files have additional requirements that are completely uncovered by the per-directory semantics of the original implementation. That is the same type of difference as for real numbers and complex numbers. Whether you want to call it "fundamental" or not, does not invalidate it. Real numbers are a limited subset of complex numbers and not the other way around. The full specification how per-directory and per-tree ignore files work can be found in the man pages. If necessary, I can summarize those, but I would rather not. Here is one fundamental difference between per-directory and per-tree ignore specs, which also shows that due to the conceptual lack of anchoring, per-directory algorithms cannot emulate per-tree algorithms. However, a per-tree algorithm with null anchors can perfectly well emulate per-directory algorithms. - Per-directory ignore specifications do not need to be anchored. - Per-tree ignore specifications must be properly anchored. >> Use cases >> >> 1. Ignore a file in `vc-dir-mode`. >> >> Write basename of absolute filepath into ignore file for directory. >> >> 2. Ignore marked files in `vc-dir-mode`. >> >> Write basename of relative filepath into ignore file for directory. >> >> 3. Ignore absolute/relative filepath with `vc-ignore`. >> >> Write basename of filepath into ignore file for directory. >> >> 4. Ignore pattern with `vc-ignore`. >> >> Write pattern unaltered into ignore file of directory. > > This enumerates use cases and states their requirements, but doesn't > explain those requirements. I don't think I understand why sometimes > the file specs need to be relative and sometimes absolute, because you > just say so without any explanations. Assuming familiarity with the code, it should be clear that `vc-dir-ignore` calls `vc-ignore` with the result from (vc-dir-current-file). In this case FILE is an absolute filepath. For a set of marked files `vc-dir-ignore` calls `vc-ignore` repeatedly with the result from (vc-dir-fileinfo->name filearg). In this case FILE is a filepath relative to default-directory. When calling `vc-ignore` interactively, the current directory is inserted at the prompt. In this case the FILE parameter is an absolute path unless the default directory is deleted first, then it becomes an undefined pattern. When calling `vc-ignore` from lisp code any combination of FILE/DIRECTORY can be specified and should be processed sensibly. >> The reference backend implementation is `vc-default-ignore`. Although >> the documentation already specifies what the function should do in a >> per-tree context, the original implementation strangely follows the >> description of `vc-ignore` which is still per-directory. > > See, I don't even understand why you say vc-ignore is per-directory. The **description** of `vc-ignore` is per-directory, while the **description** of `vc-default-ignore` is per-tree. That is obvious if you read both descriptions and do not confuse description and implementation. The **implementation** of `vc-ignore` is inherently neither per-directory nor per-tree, because it only calls the appropriate backend function. The original implementation of `vc-default-ignore` is per-directory only and therefore contradicts its description. The incorrect behavior is explained in bug #37217. While I partially corrected the implementation of `vc-default-ignore`, it is unsatisfactory in regard to a good abstraction of escaping and anchoring (incl. syntax detection), which would eliminate the need for specialized backend functions `vc-hg-ignore` and `vc-git-ignore`. > That it accepts a directory as its argument doesn't yet mean it cannot > support all of its subdirectories, recursively, which will make it > per-tree. The difference betwen per-directory and per-tree has nothing to do with a DIRECTORY parameter or recursion. Per-tree is not a recursive per-directory algorithm and cannot be implemented as such. However, per-directory is an automatic by-product of a per-tree algorithm (e.g. ignoring some file in the root directory). A search of the `vc` source files for `per-\(dir\|tree\)` gives a hint that the concept of per-directory and per-tree is VCS specific: vc-hooks.el\0110-(defcustom vc-handled-backends '(RCS CVS SVN SCCS SRC Bzr Git Hg Mtn) vc-hooks.el\0111: ;; RCS, CVS, SVN, SCCS, and SRC come first because they are per-dir vc-hooks.el\0112: ;; rather than per-tree. RCS comes first because of the multibackend In regard to ignore file specifications, per-directory means that the file specification is a plain basename without directory parts, the scope of the specification is only the corresponding directory, no anchoring is necessary. Per-tree means that the file specification may include directory pathes and unanchored file specifications are applied in all sub-directories, while anchored specs are only applied at the specified level. Again, this is much better described in the respective man pages. > I'm probably missing something, but what? The FILE parameter of `vc-ignore` is considered equivalent to a wildcard. This equivalence is false. The design change is an additional parameter to `vc-ignore` and optionally new functions `vc-ignore-file`, `vc-ignore-pattern` to clarify the intended use. Proposed shortcuts are: `C-x v F` => `vc-ignore-file` `C-x v G` => `vc-ignore-pattern` in `vc-dir-mode`: `F` => `vc-dir-ignore` => `vc-ignore-file` `G` => `vc-ignore-pattern`. > Once again, feel free to tell the discussion about the design is not > useful and should be abandoned. Are you saying that it is not useful to finally have a working ignore feature after more than 20 years? The `vc` ignore feature implementation has not worked and still does not work correctly. But before adding some more adhoc patches without a final resolution, it is usually better to consider all problems and specify a working design. Anyway, my contribution was not intended to be a final design but rather an incomplete collection of design criteria for the responsible maintainer. I also assumed, that the responsible maintainer has a general knowledge of the concepts for ignore files and specific knowledge of the `vc` ignore feature code. > I'm okay with discussing just the > specific bug you have. Unfortunately, the specific bug I encounter with `vc-hg-ignore` cannot be fixed without the API change. > But if we are to continue talking about design > aspects, may I suggest that you explain your opinions more than you > did until now? The rationale for the design changes can be found in previous posts and other bug reports, where the problems with the implementation of `vc-hg-ignore` become apparent. Among the differences between per-tree and per-directory semantics is the anchoring mechanism which is needed for per-tree and is unnecessary for per-directory ignore specifications. Try to understand that although ignore specifications are always wildcard specifications, a generic frontend function like `vc-ignore` cannot ask other generic functions like `vc-dir-ignore` for properly escaped wildcard specifications, since the correct escape and anchoring mechanisms are unknown to frontend functions. Asking interactively for a raw pattern is feasible, since a user probably knows the appropriate syntax. A frontend function should not be burdened with actually normalizing, escaping and anchoring filepath specifications. The high-level flag signaling either raw input or unescaped and unanchored filepath is sufficient and more readable.