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: Tue, 11 Feb 2020 23:28:10 +0100 Message-ID: <2c8419ae-723d-c7ae-a60e-59d1b1cbc2c1@gmx.de> 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> <8336bmg1o9.fsf@gnu.org> <2354821b-5c1e-f9e3-3a64-4ff978ded33b@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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="123682"; 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 Tue Feb 11 23:29:36 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 1j1e2B-000W1i-Eq for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Feb 2020 23:29:35 +0100 Original-Received: from localhost ([::1]:57902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1e29-0004Lc-Ts for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Feb 2020 17:29:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40158) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1e1g-0004KH-81 for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2020 17:29:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j1e1e-0004c7-1N for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2020 17:29:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51701) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j1e1d-0004bw-UG for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2020 17:29:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j1e1d-0002Am-PS for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2020 17:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Wolfgang Scherer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2020 22:29:01 +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.15814601018303 (code B ref 37189); Tue, 11 Feb 2020 22:29:01 +0000 Original-Received: (at 37189) by debbugs.gnu.org; 11 Feb 2020 22:28:21 +0000 Original-Received: from localhost ([127.0.0.1]:57674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1e0y-00029r-FN for submit@debbugs.gnu.org; Tue, 11 Feb 2020 17:28:21 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:54261) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1e0v-00029d-QN for 37189@debbugs.gnu.org; Tue, 11 Feb 2020 17:28:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581460091; bh=w7b9a1onwjxwR4AQWbyXnl/QpRrjUd/59RbzftsS+8E=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Exp9N+2QbtUy0orGe7b8P6Qxc5LHsqJagTRdqLQh74y4F6woCpCD/hRG9S4uhYb5s d2yy7q84HBiPxnNNkGxken+2qChWA0XAzcmF1k2uf0LWO5/+Qjgxk0V8GVz7BrZlsv IU48FhnGWmC9VLqrTDvKJee0x1hwN2IKHOtFAMHw= 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 1MNKlu-1iqAb30JP0-00Oqhs; Tue, 11 Feb 2020 23:28:11 +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 5A0241943196; Tue, 11 Feb 2020 23:28:10 +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: <83zhdpqbas.fsf@gnu.org> Content-Language: de-DE X-Provags-ID: V03:K1:FoB0JqbCOgx6AYRkUgdEC0w98+Vc2aYhdOM0FpKj+cxD/cuY7LX 4QX21BB6O6gx/KaIGiGZJc/MQDbq2e9Pcwa59mPaRJsTAZayuFgskudfWuJtuth/J2IkbPb hSxkx5gZ6P58vl6Cs5LKV1hnJ+lSceVRKIAA/4PW859B/FDoWloTevr3O0tbRPUNCtQgIpp n3mXD56WLAeZiiHbliryg== X-UI-Out-Filterresults: notjunk:1;V03:K0:JasEDOzoyC8=:kQPwQ1NPx8mIcqTRCFbB14 UJx671HvlCjVG80RZwSs2XWKWAMaT/GVG+dQC4x3UBf9YXQGfLilmiAQj67rLkHUOOs742l6r mr7qCv7Tx+RIl520xulrYu1zJY2IIBlvvfDjfwY8RcQwRZgnOizdwu+GFp/RH1Y8xh5d/QVnx cYl5LSOTw0hF5KRth9m/tL+7JIhJQ7na7/nbYcRqsmzixscCSQAP5uJ2QhKQni3hcchwVtXX/ EWe/HqAt8wPvXYgCgSleX+tZ2jALu7ssYN8DX7joiJy7xf5tUZv1hUGq06CWx2hsm0LOaDts3 pIt7xYbOMburW3+G1z6HmMlYccyvYk6H56B++uigS8988xOH0GW+CGpVePf3yfTjQ3k5hwOly noxruvdS1Q4fKglfybLgxNDqpJRKr2oxej1AocW8eKcN+XsMckRJvk0j1kg9CI0M6KnuPIqj5 8lucEZ0EgX0ZsN+Mml0x9WafInm06XIfSNOtze+qpJ9PmqRrKlzW0wJhR133LGg9DmhMeyLIa Nbnn0Aj0Heo0bEQmeFJYKXbdWo1IvUWhfMl8xes3uGFmmePm3vHEPFE6odOWbR9FrepeODQGX WnWznd318K1kwUdNQ7aD6Wab3cRsu2qC3wWN/nIfVh97NnFxxkitNQpNge5bHt78ECA9ZA92Q ut2AYNm8oi4ftGbveNTlerBxhkWjtwEUnZ3ziXGUEH4GPhixLFuralV/0YrWnIHkNmQ9pUY9T GCGrwX2oMaI5ieWId5QamK2JUaguAVxenh87CFCVC79FQ2odK7ropH+7UW16p/NLM6cabUho 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:175957 Archived-At: Am 11.02.20 um 18:32 schrieb Eli Zaretskii: >> Cc: dgutov@yandex.ru, 37189@debbugs.gnu.org >> From: Wolfgang Scherer >> Date: Tue, 11 Feb 2020 02:45:41 +0100 >> >> I suggest, we stop talking about the use case, where `vc-ignore` >> is called interactively, I will let you have your opinion, >> although I strongly disagree > If you strongly disagree, then why do you give up so easily on your > opinion? I didn't yet make up my mind, so maybe you will be able to > convince me. 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. In that case we are first talking about fixing the broken functionality, before deciding how to implement it exactly. Otherwise we will get lost in a "pattern" discussion, which has no point, since I don't oppose it. > >> and the unsolved problem of interactively locating the correct >> ignore file makes it ultimately hilarious: >> >> 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). With a "pattern only" implementation it will become an issue, when dealing with a recursive SVN repository in *vc-dir-mode*. Invoking *vc-ignore* in a *vc-dir-mode* buffer will always use the current root of the SVN tree. However, when a pattern shall be added to the ignore spec in a subdirectory, a new buffer must be opened with the subdirectory as root. 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 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .svn =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub/CVS =C2=A0=C2=A0 edited=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub/.c= vsignore =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub/sub2/CVS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub/sub2/RCS =C2=A0=C2=A0 edited=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub/su= b2/.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. ``` {.sourceCode .elisp} >>> (let ((default-directory "/the/top/")) (vc-responsible-backend "./")) SVN >>> (let ((default-directory "/the/top/sub/")) (vc-responsible-backend "./= ")) CVS >>> (let ((default-directory "/the/top/sub/sub2/")) (vc-responsible-backen= d "./")) RCS ``` It is obvious, that it is quicker and safer in that case to just open the ignore file directly and edit it. Ignoring a pattern in `sub` or `sub/sub2/` leaves only the command ``svn propset svn:ignore pattern dir``, which overwrites previous patterns making the whole operation complicated. This is a very good point for implementing the "file path" use case. With the "file path" algorithm none of these problems arise, because the VC is determined by the current directory (SVN in `/the/top/`) and the search for the ignore file starts in the appropriate subdirectory with the correct backend. ``` {.sourceCode .elisp} >>> (let ((default-directory "/the/top")) (vc-responsible-backend "./")) SVN >>> (let ((default-directory "/the/top")) (vc-responsible-backend "sub/")) SVN >>> (let ((default-directory "/the/top")) (vc-responsible-backend "sub/sub= 2/")) SVN ``` So, if the "file path" use case remains broken or is removed entirely, it will be a an issue which ultimately discourages users to apply the function at all. While I appreciate the added functionality of the "pattern" use case (which is most useful for modern VCs with a single ignore file at the root), I would most certainly not bother with it, should it be the only option. I have been using the command line and Emacs **vc** package for more than 25 years for almost all my VC needs, whenever support for a VC became available. However, ignoring files I always had to do with other packages, e.g. **pcl-cvs**, **dvc**, which all support the "file path" use case, none of them support the "pattern" use case. Sigh, it is finally really nice to phase out other vc packages. >> Since the escaping must also be correct, I'm probably better off >> locating and editing the ignore file manually. Inserting the output >> of "ls -1" and editing away - as I sometimes do - is much more >> convenient than calling `vc-ignore` multiple times and repeating >> more complex editing of an absolute file path each time in the >> minibuffer. > vc-ignore is not only for adding ignored files/patterns, it is also > for deleting entries in the ignore files. And that functionality > definitely needs the users to type the patterns exactly as they are in > the ignore file. I was making a case of editing the ignore file directly, so the REMOVE case is obviously also covered. But yes and no for the typing. The "file path" use case is covered, since the escaped file path is removed. If the file path was added automatically before, then that is exactly what is in the ignore file. No typing required. Since there are many ways to specify the same pattern, the manual approach is really less desirable than automatic escaping. This is where the completion list of active patterns comes in handy, as those are the actual patterns that can be removed. As I said, I do appreciate the "pattern" use case, it just needs a little bit of enhancement to become more useful. >> However, there is a use case that you keep avoiding to comment >> on, namely pressing "G" in `vc-dir-mode`, which calls >> `vc-dir-ignore`, which in turn calls `vc-ignore` >> **programmatically** with an absolute file path. It has been >> officially supported by Emacs since 2013. I did not invent it and >> I did not alter its API. >> >> Since there is no interactive prompt whatsoever for a user to >> >> 1. properly construct an escaped pattern and >> 2. specify the directory, where the search for the ignore file >> =C2=A0=C2=A0 should start, >> >> the function called to ignore the file must consequently escape >> and anchor it properly, just like any command that uses >> `shell-quote-args` because the use case requires it and the >> purpose of the argument is well-known. >> >> How do you plan to support this use case? > 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. So, please have a look at *vc-default-get-ignore-file-and-pattern*, which does exactly that, it returns the correct ignore file, and the escaped pattern. You want this function to be called from *vc-dir-ignore*, and then only use the pattern for *vc-ignore* and voila: **it is impossible for vc-ignore to find the correct ignore file** when it is in a subdirectory, as I have shown previously. Setting *default-directory* to the directory of the ignore file results in *vc-ignore* being unable to determine the correct backend, as shown above. Since *vc-dir-ignore* already knows the backend, it can call the backend function *vc-default-ignore* directly. And *vc-default-ignore* in turn will call *vc-default-get-ignore-file-and-pattern* **again**, since it must **again** find the ignore file. Don't you think, that this is a waste of resources and possible cause of many errors? My implementation uses a single path for both *vc-ignore-file* and *vc-ignore-pattern* eliminating that quite nicely. *vc-ignore-file* is used for both interactive specification of files as well as *vc-dir-mode* and *dired-mode* file sets, eliminating the function *vc-dir-ignore*. >> According to your opinion `vc-ignore` can only be used >> **interactively** by a learned expert user, who wants to make >> ignore file administration even more complicated by editing >> random ignore files without any feedback. > Given that vc-ignore can also delete a an entry from the ignore file, > and given that we supported patterns there (albeit with bugs) for some > time, I don't see how we can change that in a radical way like you > suggest. I think you misunderstand me. The pattern REMOVE functionality is supported exactly the same way as before. There is no change besides the missing bugs and the complete support of all backends (that *is* probably a bit radical). -=C2=A0=C2=A0 If you call *vc-ignore* programatically, you get the same re= sult =C2=A0=C2=A0=C2=A0 as before. -=C2=A0=C2=A0 If you invoke `C-x v G`, you get the same result as before. -=C2=A0=C2=A0 If you invoke `G` in *vc-dir-mode*, you get the same result =C2=A0=C2=A0=C2=A0 as before. -=C2=A0=C2=A0 **Only** if you invoke `M-x vc-ignore RET`, **you get an err= or**. =C2=A0=C2=A0=C2=A0 This is intended to provide the incentive for noticing = the =C2=A0=C2=A0=C2=A0 modifications and also to have better doc strings. =C2=A0=C2=A0=C2=A0 If you don't like it, **we can keep the old behavior** = and make =C2=A0=C2=A0=C2=A0 *vc-ignore-pattern* an alias for *vc-ignore*. In that c= ase there is =C2=A0=C2=A0=C2=A0 **no user visible change at all** for the "pattern" use= case. Just the previously broken functionality of ignoring "file pathes" (also including the REMOVE feature) is now properly supported. The only real API change is an additional flag AS-IS for *vc-ignore*. > >> So it is the wrong candidate for a noob user of `vc-dir-mode` >> who just wants to ignore the selected files literally without >> worrying about ignore files and escaping. > I agree with you wrt vc-dir-ignore. Good. > >> 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: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (vc-dir-resynch-file file) When ignoring files in vc-dir-mode, the status is now immediately checked = and updated to "ignored". >> If you are just worried, that somebody will use `vc-ignore` and >> expect the old broken behavior > 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 is **always** wrong.=C2=A0 The commands I fixed recently, now do no longer fully support the "pattern" case anymore. The whole point of the proposed implementation is, that both use cases, "pattern" and "file path" are supported correctly and to the full extent. >>> This concept is similar to what we do in commands such as "M-x grep", >>> where we expect the users to escape special characters in the >>> command-line arguments to be passed to Grep the program via the shell. >> That is not at all comparable, since there is no use case "search >> for file path in a bunch of files". > 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! There is no way, that the pattern argument for the *grep* command could be reliably parsed and quoted. If the pattern was read separately from the rest of the arguments, it would be quite alright to quote it for the shell. If the vc-ignore supplied pattern was to be passed on to a shell command, it would of course have to be properly quoted for the shell. But nobody expects the user to do that. In fact, I wrote myself a *grep-find* derived command to search for tags in files, which prompts the user for an unquoted regular expression of symbols. That expression is then augmented with the tag delimiters, it is further quoted for the shell and inserted at the proper location for the *grep-find* command which is then presented to the user for editing the options. And why? Because I know in advance what the exact structure of the pattern will be and that it has to be quoted for the shell ;-). Provided with a pattern of "LOG\|BGX", the command prompt looks like this (slightly edited): ``` {.sourceCode .sh} /usr/bin/find . -name '*' -type f -exec /bin/grep --color -nH --null -e \ =C2=A0=C2=A0=C2=A0 \\\(\\\(\\\(\\\(\\\)\|\:\\\)\\\(LOG\\\|BGX\\\)\\\)\:\|\= \\) \{\} + ```