From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: el-search usage (doc, strings, pcase, etc.) Date: Sun, 28 Oct 2018 23:26:34 +0100 Message-ID: <87in1liu79.fsf@web.de> References: <87tvl7jvir.fsf@portable.galex-713.eu> <875zxne6pc.fsf@web.de> <87zhuzibvw.fsf@portable.galex-713.eu> <87zhuzkuqf.fsf@web.de> <87muqzggz5.fsf@portable.galex-713.eu> <875zxnkkgw.fsf@web.de> <87o9beesxv.fsf@portable.galex-713.eu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540765518 14614 195.159.176.226 (28 Oct 2018 22:25:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Oct 2018 22:25:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: help-gnu-emacs@gnu.org To: "Garreau\, Alexandre" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Oct 28 23:25:14 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGtUf-0003kI-OA for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Oct 2018 23:25:13 +0100 Original-Received: from localhost ([::1]:42319 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGtWm-0003aX-3h for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Oct 2018 18:27:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGtWH-0003aR-5t for help-gnu-emacs@gnu.org; Sun, 28 Oct 2018 18:26:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGtWB-0000ND-Ih for help-gnu-emacs@gnu.org; Sun, 28 Oct 2018 18:26:53 -0400 Original-Received: from mout.web.de ([212.227.17.12]:47245) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gGtW9-0000JX-Ll for help-gnu-emacs@gnu.org; Sun, 28 Oct 2018 18:26:47 -0400 Original-Received: from drachen.dragon ([94.218.210.177]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MNcIg-1gE8M20XVK-007F18; Sun, 28 Oct 2018 23:26:36 +0100 Original-Received: from drachen.dragon ([94.218.210.177]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MNcIg-1gE8M20XVK-007F18; Sun, 28 Oct 2018 23:26:36 +0100 In-Reply-To: <87o9beesxv.fsf@portable.galex-713.eu> (Alexandre Garreau's message of "Sun, 28 Oct 2018 02:55:08 +0100") X-Provags-ID: V03:K1:dfyatmbFqZ7W1FOJJwuYsif1uPUTzJLqSXMNh5J12+0YqLchgMf HQatPuHivF6LhXP7zUfKEVCqtl6Wao7eLzZQPgAoKlZBPscxIaHwqK2nFDdLkUaaUGdq387 oEEHSvaKB+6QqcTNMdL3j+xOc1ZXB+7PLkj7SwXU8GIa4SWemntKhdieXLa8oXmWVJaQjT1 PT/TmCxlgy6h0SLlnp8Nw== X-UI-Out-Filterresults: notjunk:1;V01:K0:bGO4znDBWvQ=:XHoe8rVfvvkiZu3jgLDExX hFm78evQ+ljGUzOwWSEG/hadQHk8nfXULEhyfCO5BIGfGlRKCGCRa8xRdrA77Z3Kd1keyloZ7 lOIFiCZ7nAZKZslC4eBw/K75eMDe5GdT8xHuNl5heTEMXUGr/LJyqEo8Nw+iSBY113UE7n92Y NNcTMZMIIUsC5vpTeRhU6XL/XBGgil/p9nvPxOLnk3vU6JjPD+xQPpz0lMHoJyrSq28EfWifK AI+bL/GJ6s6kMHdzykA/HwrHV3CejrBG3shBjZhcJZMLZVCrfUtSaPavGps1lg6OrnPcdNG9F f9B9kc8coUQpQivfTaGdMkfmxJMY/86fAwKxSc5RWB0B/mjZwWKmSJg54og+s9aIBTLmBgHvd TLdksMuIZXd3wC3/nRQVa7oNNtJarC/GUMyYkqUDG7+zSssSIFlfJxbsoSi+F8n3yu5MSlm3b BHzJ3shVXnzFrpwItFmED+Zju9N6fmXJCssp1+gQOuDsdXlJlW428GjDBBaLYb6H/2OQ+H+aA VQpTMJqsfKAFDP1Bw11a6umfMZlIR+T3zwH8aJe+EtJBcr79yA8Jeur9aUTetOu/4sUAe8Aii 7Sm0CQ+YOCNceLRRV5wsaVk7B2JZhQGIACpjvOfZSQCU2Ut7YbLKrq5q2Wt8+NcHTNaW+VeMy uYeeqSiapuVGqZ+GSDxFdF/0nARxpUO87gI58MdQXodG7qjxn9KyUlIsZZpkRaZ83tHKpiCyp OQtNsU8hi2PtEZspHnOxF3H6CZpksRi2DfBYyvq5KQaqglIFfVCHNG0Pp8Owqe/N/CCW/QR2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.12 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:118472 Archived-At: "Garreau, Alexandre" writes: > > I think it's easy enough to spell out. IMO the less different pattern > > types pcase has builtin, the better it is for its acceptance. > > Additional patterns should be limited to cases where it is really hard > > or impossible to express something. > > Mmmmh=E2=80=A6 Then maybe el-search should define it still as a pcase pa= ttern, > so that it might use it, and users might copy and use it until it=E2=80= =99s > accepted and widespread enough to be integrated in pcase? By the way, pcase has already a pattern type for matching strings: `rx', available after loading rx.el. > I don=E2=80=99t see how: regexp always match strings, and most of time are > strings. Though they may be lists=E2=80=A6 but then you could define it = as > such: > > #+BEGIN_SRC emacs-lisp > (pcase-defmacro re (pattern) > `(and (pred stringp) > string > (guard (string-match > ,(typecase pattern > (string pattern) > (list (rx . list))) > string)))) > #+END_SRC I would still prefer to use the `rx' pattern here. But I like the idea of supporting rx sexps in the el-search string-matching pattern, however it is called in the end. There is another reason it's called "string" btw: if you use it without any arguments, it matches strings. > >> #+BEGIN_SRC emacs-lisp > >> (pcase-defmacro string-match (pattern) > >> `(and (pred stringp) > >> string > >> (guard (cons (string-match ,sequence string) (match-end))))) > >> #+END_SRC > > > > Pattern matching is a boolean thing: a pattern can match or not. > > There is no return value. > > Any non-nil value is true, hence a boolean. Sure, but the cons you construct above is thrown away. > > You only have the body part of the clause. To deliver a value out of > > matching, you need to bind a variable and use that in the body of the > > clause. > > The fact pcase doesn=E2=80=99t offer a straightforward way to get the ret= urn > value of its patterns (or, rather, especially, of its guards) can be > worked around (we can locally bind a variable then setq this variable to > whatever the pattern is transformed into (hoping it=E2=80=99s something > eval=E2=80=99able)). A setq in the pattern is a side effect. Side effects in the patterns can behave unexpectedly AFAIR, due to optimizations pcase performs with the code. I hardly learned when composing el-search patterns that it is really not a good idea to try to make use of side effects. There was once a warning about this in the pcase docstring, but seems it has disappeared since the rewrite. > > In el-search, I can define patterns to do this implicitly, so this is > > not the hard part (the hard part is to find out if I want el-search to > > highlight parts of strings - I agree that it could be useful, but it > > would also complicate the semantics in a way that is not > > straightforward). > > What the purpose of matching 80% of the *whole*, enormous, docstrings, > please? I understand matching whole strings is useful, maybe even > matching whole strings given a substring can, but this is definitely > useful. But, if you think it to the end, el-search-query-replace would then also need to support replacing inside strings. Isearch is a better tool for this task I think. > no =C3=A6 nor =C5=93 nor =C3=BF (now this later one officially entered in= french > (because until then this letter only existed in capital because used > in some town names, but then one of them invented a wine and its name > entered the dictonary) That's funny. > > ((1)) > > > > and search for the pattern (pred consp). You have two matches: ((1)) > > and (1). The second match (1) is completely inside the first match > > ((1)), and it even ends before the first match. Something like that > > doesn't happen in isearch. Semantics of syntactical code search, and > > text search, differ. > > Mmmh, yes, that=E2=80=99s right, with normal isearch. But regexp-isearch= could > support that for regexps (so greediness could be varying), I guess it > could get very interesting, so that seems it could optionally be useful > to isearch. But because regexps are either greedy by default, and each > match can=E2=80=99t yet overrun the next (which I find sad: so if you sea= rch > from different positions, you may get completely different result sets > for =E2=80=9Ct.*?t=E2=80=9D for instance) Yeah, we would have to rethink what "match" means and how they are ordered. > Okay, that seems a good reason. It=E2=80=99s sad isearch is that complex. > Maybe it could (should?) be tidied? It's not poorly written. It just can do so many things. The task it solves is complex, and it has gotten more and more features over time. That makes it a great tool, but I would expect that changing very basic concepts would be not easy. > Cannot a transient-map works without a prefix or predefined keys, like > isearch does? wouldn=E2=80=99t it be possible to make it inherit the cur= rent > keymap then make it the current keymap, in some rsearch-mode > (recursive-search, or maybe nsearch, for nested-search, or something > alike)? I'm not sure I get your proposal. But I think your goal is that you start with M-x el-search-pattern RET PATTERN RET, you have available keys to proceed builtin. I guess you would want to use help key to see the meaningful keys? Michael.