From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#37189: 25.4.1: vc-hg-ignore implementation is missing Date: Tue, 14 Jan 2020 04:14:41 +0300 Message-ID: <1ebc6077-9175-65ba-4996-282bb2c8eca5@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="222143"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 To: Wolfgang Scherer , 37189@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 14 02:16:47 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1irAna-000n89-Rb for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Jan 2020 02:15:15 +0100 Original-Received: from localhost ([::1]:57814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irAnZ-0000rK-Al for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jan 2020 20:15:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40211) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irAnQ-0000qt-JY for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 20:15:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irAnO-0006uK-Uh for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 20:15:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54502) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irAnO-0006tp-PV for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 20:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1irAnO-000455-Ko for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2020 20:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jan 2020 01:15: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.157896449415657 (code B ref 37189); Tue, 14 Jan 2020 01:15:02 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 14 Jan 2020 01:14:54 +0000 Original-Received: from localhost ([127.0.0.1]:60475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irAnF-00044T-Jm for submit@debbugs.gnu.org; Mon, 13 Jan 2020 20:14:53 -0500 Original-Received: from mail-lj1-f182.google.com ([209.85.208.182]:41891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irAnB-00044C-SE for 37189@debbugs.gnu.org; Mon, 13 Jan 2020 20:14:51 -0500 Original-Received: by mail-lj1-f182.google.com with SMTP id h23so12341015ljc.8 for <37189@debbugs.gnu.org>; Mon, 13 Jan 2020 17:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mHfiIXhhz+4QDlugxME6oBbFqleiAzQ0XyGI0iO4FW0=; b=tsdpH2KXrVraa0mQkU7hd+bbVJ8eOy6QzR+096s8S/xAJVyBRb9ptrpVeNbOLLzNfj mpRXe6h7VhJfLSEasNXAawlvcXuYFg8UudCl1brYbpX1rn62wMYuy024ujqiCpMbzXQm SwCZgFupQysxvIupUubPPVE7obxQL7jvrN7qwjYgnbsI0EJC72NLv9DmYSftlpUOwLCw +sQAhNaDXUurIe8AucheyT0SgPy3Dq4HGncK24/np+Uu6Q0bmAnQZs1VueFuIdF2HvoL WUWusCDJ1tB17/ET87XtMemC3jADMAm2ovTKOf/EtsFNfwsMSK2sPSuwQ8Z+u5T2GTuc +dJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mHfiIXhhz+4QDlugxME6oBbFqleiAzQ0XyGI0iO4FW0=; b=MzndkrwLWZdb1il2KuuUaU7kBlRVSNz8PHzWXUpda9I+4qHqfWiQLMEUW30Ly1T8yt pLl8Xwq8sz5chJzjOnzX/8YLJBe9p8FQNmF+SsjLm6NhZnLyk389J/Uu2Zpgv5Rta3L4 wbI9vW9X8pu6G/O6qp/c8x0MnCbC/72iSJT4W2U3x9KAoQZANYE83J8ShrSQVp1AT9D+ FXKzyBfD/4uEesDKTe/FvXqNJkdBEe0Ga9+mOarqeRKr5pcPKlNuB0PZpDOsz13t+OIL PC0pE0ikVYJ0iKE4nBM+rjcHUNXjdyZf+gVwjJRqWpM8vX1vdQWrejjebAE3OZs5cVjT lAyQ== X-Gm-Message-State: APjAAAV3hGgF0wGrvqBhjs44QSebBTSl8bcNlhjht5s0AY6VkBzkGZfH +tMZwOy+oMOAEq6dLn8gUuw8qyXa X-Google-Smtp-Source: APXvYqyr7ks8WL7qIapOflWo+2wL+X5uBbwN/gST/9bzgDbydNfstDGl49mYwhxnfwB5nlhA88E63w== X-Received: by 2002:a2e:854b:: with SMTP id u11mr12763503ljj.90.1578964483224; Mon, 13 Jan 2020 17:14:43 -0800 (PST) Original-Received: from [192.168.1.142] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id x13sm6350726lfe.48.2020.01.13.17.14.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jan 2020 17:14:42 -0800 (PST) In-Reply-To: <57825d73-27a4-d5f5-8198-a172796a558a@gmx.de> Content-Language: en-US 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.org gmane.emacs.bugs:174556 Archived-At: Hi Wolfgang, Sorry for the wait. On 05.01.2020 6:46, Wolfgang Scherer wrote: >> On 29.08.2019 18:52, Wolfgang Scherer wrote: >>> +  "Ignore FILE of DIRECTORY (default is `default-directory'). >> >> IF this function needs a docstring at all (which is not obvious since it should be following vc-ignore), I think I'd rather this followed the latter's docstring. Where the clarification about the default is not in the first sentence. > > vc-hg-ignore needs a docstring, since it exhibits specific behavior for the backend (e.g. glob/regex syntax), which is not and cannot be covered by the rather generic vc-ignore docstring. OK, I'm fine with that. But user-facing one is vc-ignore, so it can have some generic language to that effect (saying something like "wildcard or other syntax supported by the backend"). > Most of the description in  vc-ignore is not even applicable to the backend specific functions, e.g. there is no interactive functionality in the backend function and no backend is determined. OK, true, but otherwise the description should be closer. And we also have the description of this backend command in the header commentary of vc.el. > If a backend does not provide a vc-BACKEND-ignore function, vc-default-ignore is invoked. This function has a docstring of its own (which contains the clarification about the default in the first sentence). According to your argument, this function should also have no docstring of its own. However, I cannot see how both docstrings are equivalent. Actually, I'd have more doubt in its necessity, yes. This one really should be covered by the docstring of vc-ignore, as well as the description of the 'ignore' VC command in the header commentary. I mean, it can have a docstring, but it would be a plain copy of the existing descriptions elsewhere. > vc-hg-ignore is modeled after vc-default-ignore, the docstring was copied from vc-default-ignore and modified to fit the implementation. I have modified the docstring further to match other backend specific ignore functions. Actually, let's talk about vc-default-ignore. In a recent patch you submitted in debbugs#37217 you changed its docstring to say "either relative to DIRECTORY or absolute" whereas it originally said "either relative to the root directory of DIRECTORY or absolute. That sounds like a change in documented behavior. And it could be a problem if it were in a docstring users are actually likely to see. In any case, I think the docstrings should really be in accord, and the "more private" functions shouldn't have crucial information about command's behavior that the users won't be able to see. >> Also, I think saying "Ignore FILE under DIRECTORY" would be better, if you intend to add this particular semantics to relative names. > All other ignore functions say "Ignore FILE under VCS". I have modified the docstring accordingly. >> >>> +Otherwise, FILE is either relative to DIRECTORY or absolute. FILE >>> +is converted to a path relative to the project root of DIRECTORY. >> >> Isn't it a bit odd that vc-ignore's docstring doesn't specify this distinction, and yet we're trying to implement it in vc-hg-ignore? > > No. vc-ignore's semantic roots stem from SCCS/RCS/CVS/subversion with single directory ignore files. The ignore files for those VCS only contain file patterns. vc-ignore is still the command the user calls, isn't it? Or are you using some other command? (This seems like the key question of this email at this point). If yes, I also wonder what are the cases when the DIRECTORY argument is important. I.e., when is it not the same as default-directory? vc-ignore, when called interactively, sets this argument to nil (so it is set to default-directory). vc-dir-ignore doesn't pass the second argument either. Importantly, when do we really expect FILE to be something other than absolute, relative to the repository root, or a simple glob (e.g. *.c) which is going to apply to files regardless of the directory? BTW, it seems to me like f144c87f92b broke the last case. Or at least made it work worse (calling vc-ignore with '*.c' somewhere deep inside the tree would prepend its subdirectory to it). There is some *valuable* code in this patch, but let's resolve this relative-names confusion first. From what I see, when vc-ignore receives the FILE argument interactively, it's either absolute (as a product of read-file-name when the user choose a file with completion), or a free-form glob when the user just went ahead and wrote one anyway. So instead of the current always-relativizing logic, I think we should choose what to do by calling file-name-absolute-p. And if it's not absolute, just take the value as-is, because there is no telling if the user meant "this file in the current dir" or "all files with that name". If it is absolute, on the other hand, yes, make it relative to the repository root. >>> +                (concat pattern (and (file-directory-p file-path) "*")))))) >> >> I think it needs to asterisks for the glob to become recursive. At least according to https://stackoverflow.com/a/255094/615245. > No, according to https://stackoverflow.com/a/255094/2127439, all of "bin/", "bin/*", "bin/**" are equivalent under glob syntax. I also tested this specifically and extensivlely. Very well.