From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#37189: 25.4.1: vc-hg-ignore implementation is missing Date: Fri, 20 Mar 2020 01:42:45 +0200 Message-ID: <4aea6148-9673-bb80-4904-2b75b9e1bef3@yandex.ru> References: <1ba53ae2-42a4-3ab3-d4f2-2ceae565d198@gmx.de> <83sgjkdev5.fsf@gnu.org> <3fb73dbc-bf31-233b-4afc-2147c4ffd5b7@gmx.de> <5622487d-a21f-49cf-5420-21f87415af4f@gmx.de> <83wo8ubfbo.fsf@gnu.org> <83zhdpqbas.fsf@gnu.org> <2c8419ae-723d-c7ae-a60e-59d1b1cbc2c1@gmx.de> <83o8u3r6wg.fsf@gnu.org> <6f3ba261-e1f9-cf19-cc22-ec8c24cf3298@gmx.de> <83blq2qzqp.fsf@gnu.org> <83ftfdplo8.fsf@gnu.org> <9929b44f-37da-23c8-16cc-c6ca89602149@yandex.ru> <2f84ddff-3275-6eb1-01ae-ff1d28b6e8da@gmx.de> <777563ca-b2c1-ab01-e1d5-6dc9c8f52415@gmx.de> <3220684c-b1d9-08a3-e34b-cc54e99d4754@yandex.ru> <6ade9293-7b1b-49f5-5348-582a131793bc@gmx.de> <1eb63b4b-d6db-81fb-20ab-bd1d46535d3e@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="113696"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: 37189@debbugs.gnu.org To: Wolfgang Scherer , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 20 00:43:19 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 1jF4op-000TWC-B0 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Mar 2020 00:43:19 +0100 Original-Received: from localhost ([::1]:44394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF4oo-0000L2-AO for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Mar 2020 19:43:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45859) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF4oZ-0000Ki-S1 for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 19:43:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jF4oY-0006ss-JP for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 19:43:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37800) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jF4oY-0006se-GQ for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 19:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jF4oY-0001SD-Bp for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 19:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Mar 2020 23:43: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.15846613765576 (code B ref 37189); Thu, 19 Mar 2020 23:43:02 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 19 Mar 2020 23:42:56 +0000 Original-Received: from localhost ([127.0.0.1]:43773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jF4oR-0001Rs-Kr for submit@debbugs.gnu.org; Thu, 19 Mar 2020 19:42:55 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:41689) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jF4oQ-0001Rf-IU for 37189@debbugs.gnu.org; Thu, 19 Mar 2020 19:42:54 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id h9so5421317wrc.8 for <37189@debbugs.gnu.org>; Thu, 19 Mar 2020 16:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=n4Jv6LiCOY+c9L/5ZXIhPpb/Gf+NsxlPqYN+zgaHHfI=; b=Z8SCm6eIvxSOWlQ9RQFYebcVg8MtHQuTasU7am9GaMWTL9JbKnl7db6MLwAAhO8MV3 krq/Pz7OjnWIdHBlpxStlUfzz1fxDycDHMuNUAs4PaOKBWWr+9qfGmTfNGv8mSUFDNmr j1OyFYdk2q6PlRYfBQe2lNXj1Fu4A9N/vt87LbddA6PEJWaKZSh0utQ/GnMBsGfSoyw8 CEBvKbRJl0NPVreey6oqSQZzRvWGE2jfAM438o3SE2yWPOn/BnJmhX/orOEQwIAM/l5Q ekuRyPgUnN+7CutrARwjmC1jilu504qMyMcX4g88cZO5uEiTun74GfthXxvMszeEDww+ erTg== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n4Jv6LiCOY+c9L/5ZXIhPpb/Gf+NsxlPqYN+zgaHHfI=; b=UGBFRtZEvOSiqS4l/sGSlntPRYrZksLfObh2h3PQ1f/b6yYYYAEHZR7SCIL80FRH6a SJA5Wd/kHjjF29eV5Z4C6Iypc7Lts2T0cypaXXHRYuUWUL31FdqnHQwQs8m7HX4t692R FEt9St8/IjW9ZVmAnpQIvzUI9OD2WbW4TcbaRRYVLqYULlW1UAE0wGrv0a+//3nRAexM u7NuR73z4eDIeSKV4PB9y+HTWRgu/M2LUQ7dLVKLEGBUdI3OI50OsHTqQf+/wfzEO0FJ r3T9G2owjRFpPitl+CY2x3Og0Gadwwjm2rj1P7HdqqME4RCNsS69XydWVE2D1+55dRuO z2NQ== X-Gm-Message-State: ANhLgQ0BExsDDzEmGjmTEqe9zU4xDvfkFUakU9x4U1engLNgPldVEoim DwT+VzPfbe0stJf02UZsxFruLT0v X-Google-Smtp-Source: ADFU+vsVs2zErXL1AahAxquoze4Mzl4CdTLAC1se5MhmKhDlyRU1Sj/8yYDGXnqtTtt8gJt6MWdbbQ== X-Received: by 2002:adf:9dc6:: with SMTP id q6mr7023732wre.70.1584661368173; Thu, 19 Mar 2020 16:42:48 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id f15sm5839290wrt.9.2020.03.19.16.42.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Mar 2020 16:42:47 -0700 (PDT) In-Reply-To: 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.io gmane.emacs.bugs:177553 Archived-At: Hi Wolfgang, On 25.02.2020 04:22, Wolfgang Scherer wrote: > I would like to discuss overall strategy first.  Since I have a fully > working implementation for all supported backends at > https://github.com/wolfmanx/vc-ign that does not interfere with the > current vc commands, it would be helpful, if you could load it and > evaluate the use cases 'z i' and 'z p' in 'vc-dir-mode', 'C-x v z i' > and 'C-x v z p' in 'dired-mode' and in a file buffer, just to see if > we can agree on a direction before discussing details. I've read the patch you posted to this discussion, and there are some definitely good things in there, but I wonder if we can make some progress first without redoing everything quite as much. The majority of backends don't support regexp ignores (AFAIK), so maybe it's not worth bringing that notion at the top of the API. If we can let individual backends handle this case in their implementations correctly, that would be better. Then the ignore-param-regexp and ignore-param generics might not be necessary. Though we could add some other(s). > I think a good point to start is the elimination of all > backend-specific 'vc-ignore' implementations ('vc-cvs-ignore', > 'vc-svn-ignore').  That is one goal which is easily achievable.  The > benefit is a uniform implementation across all backends with > 'vc-default-ignore' as the central implementation of algorithms, > without duplication of code in backends. First: the name of 'vc-default-ignore' itself implies that there have to be backend-specific implementations. That's what the -default- in the name is for. Likewise for vc-default-get-ignore-file-and-pattern. Some other thoughts: * Why go to this much indirection with 'ignore-param' when we could have a backend method that would escape and anchor file name? It doesn't look like that option would take more code. * Since when AS-IS is t vc-default-get-ignore-file-and-pattern is not doing much, maybe vc-ignore-file and vc-ignore-file shouldn't carry this distinction this long through the call stack. If vc-ignore-file calls a backend method that turns the file name into a pattern which doesn't need any further special handling, it even could call vc-ignore-pattern with the resulting value. * Shouldn't vc-ignore-fileset takes the fileset and loop through it calling vc-ignore-file with each value?