From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Garreau\, Alexandre" Newsgroups: gmane.emacs.help Subject: Re: el-search usage (doc, strings, pcase, etc.) Date: Sun, 28 Oct 2018 00:30:38 +0200 Message-ID: <87muqzggz5.fsf@portable.galex-713.eu> References: <87tvl7jvir.fsf@portable.galex-713.eu> <875zxne6pc.fsf@web.de> <87zhuzibvw.fsf@portable.galex-713.eu> <87zhuzkuqf.fsf@web.de> 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 1540679351 2037 195.159.176.226 (27 Oct 2018 22:29:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2018 22:29:11 +0000 (UTC) User-Agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, modified by Debian Cc: help-gnu-emacs@gnu.org To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Oct 28 00:29:07 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 1gGX4s-0000P7-Ot for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Oct 2018 00:29:06 +0200 Original-Received: from localhost ([::1]:38031 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGX6z-0004zX-6l for geh-help-gnu-emacs@m.gmane.org; Sat, 27 Oct 2018 18:31:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGX6S-0004zS-BO for help-gnu-emacs@gnu.org; Sat, 27 Oct 2018 18:30:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGX6Q-0000Pk-K0 for help-gnu-emacs@gnu.org; Sat, 27 Oct 2018 18:30:44 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:54916) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gGX6Q-0000K1-41 for help-gnu-emacs@gnu.org; Sat, 27 Oct 2018 18:30:42 -0400 Original-Received: from localhost ([::1] helo=portable.galex-713.eu) by portable.galex-713.eu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gGX6M-0004Fx-ED; Sun, 28 Oct 2018 00:30:38 +0200 PGP-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F Accept-Language: fr, en, eo, it, br In-Reply-To: <87zhuzkuqf.fsf@web.de> (Michael Heerdegen's message of "Sat, 27 Oct 2018 22:19:52 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:5884:8305::1 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:118451 Archived-At: On 2018/10/27 at 22:19, Michael Heerdegen wrote: > "Garreau, Alexandre" writes: > >> It=E2=80=99s pretty quick=C2=A0: translate your markdown/rst (which one?) > > Currently I only have the comment in the file header. Yeah, and the package description in list-packages, and its related -readme.txt file, looks like rst or markdown, that=E2=80=99s what I meant: convert that comment to org-mode like structuration, so then you can use the commentary extracted by packaging tool, export to texinfo, which will convert to many other formats, including info. >> Oh, indeed it works. I would have expected C-p/C-n and arrow keys to >> work too, like in M-x. I only use M-p in real buffer such as with >> comint-mode modes, barely with minibuffer (as I never wrote more than >> two lines of text in it, and with a few lines M-p is only barely useful, >> and C-p still work). Normally using C-p with both `read-string' (which I >> last used) and `read-from-minibuffer' (which el-search-pattern seems to >> use) support it just as M-x=E2=80=A6 > > In emacs -Q, C-p and C-n don't browse the history for M-x. Okay now that=E2=80=99s strange: here, C-p and C-n browse the history with = M-x, in emacs -Q, -q, etc. Maybe debian modified it to do so? However, if M-x accepts something, el-search input should be compatible just the same, because both use read-* functions that behaves the same. So if in your configuration M-x doesn=E2=80=99t accept C-p and C-n, then it= =E2=80=99s normal elsearch neither, but if in mine M-x does, elsearch should too. > Also, in el-search, the pattern input buffer is in elisp-mode and > often contains multiline input, so I decided that up and down move by > lines. That's beneficial when you write more complex patterns. Yeah, like I regularely do with `eval-expression': wherever it is it or M-x, C-p and C-n already move by lines, but when you=E2=80=99re at the firs= t or last line, respectively, instead of erring out =E2=80=9C\(Beginning\|End\) = of buffer=E2=80=9D, they browse history: much more expressive and handy. >> Oh interesting, and it even support non-regexp patterns=E2=80=A6 but I f= ind it >> odd it use =E2=80=9Cstring=E2=80=9D. I would have expected string to de= structure in >> characters just as the `string' function does in elisp=E2=80=A6 > > First of all I wanted a name that is short, because it is one of the > most often used pattern types. Any better idea? What, this is specific to el-search? why that? I=E2=80=99m almost sure it c= ould be useful in pcase as well (did you try to propose it?). Then, may I change the definition of the macro, so not to accept regexps anymore, so to use `search' instead? #+BEGIN_SRC emacs-lisp (pcase-defmacro in (pattern) `(and (pred sequencep) sequence (guard (search pattern ,sequence)))) #+END_SRC Now it works for all sequences, with the very extremely (let=E2=80=99s post= ulate one-letter is not reasonable, so this is an extreme) short =E2=80=9Cin=E2= =80=9D name, found in =E2=80=9Cinside=E2=80=9D, =E2=80=9Cinclude=E2=80=9D, =E2=80=9Cintr= a=E2=80=9D, =E2=80=9Cinter=E2=80=9D, =E2=80=9Ccontain=E2=80=9D, etc. (other possibility was =E2=80=9Csub=E2=80=9D, already used as an abbreviated name = for set inclusion). So now, to contrast with this oddly not-RE aware function, we make the RE one: #+BEGIN_SRC emacs-lisp (pcase-defmacro re (pattern) `(and (pred stringp) string (guard (string-match ,sequence string)))) #+END_SRC Or, if you find that not understandable enough, you can choose instead `re-in', but I find it redundant, as it is imply by the used re that it is =E2=80=9Cin=E2=80=9D, from the point you choose not to use el-re-specifi= c \` and \'. =E2=80=9Cregexp=E2=80=9D is about the same size of =E2=80=9Ccontain=E2=80= =9D, so I didn=E2=80=99t mind it. >> > The available pattern types are listed in C-h f >> > el-search-defined-patterns. BTW, the arguments of `string' can also >> > be an "extended regexp" - that's a regexp plus a list of bindings like >> > in >> > >> > (string (((case-fold-search nil)) "was")) >> > >> > which would match "I was" but not "I Was", or a predicate accepting a >> > string. >> >> That=E2=80=99s pretty complex=E2=80=A6 I hoped it was for pure text (so= it=E2=80=99s easier to >> enter =E2=80=9Cspecial=E2=80=9D characters such as =E2=80=9C\\=E2=80=9D = or =E2=80=9C(=E2=80=9D), not regexps=E2=80=A6 but >> strangely it seems not to support =E2=80=9C<=E2=80=9D and =E2=80=9C>=E2= =80=9D to match beginning/end of >> words. > > A literal string match pattern is easy to implement: > > (el-search-defpattern string-literal (s) > `(string ,(regexp-quote s))) This is so dirty, because in the end you quote a regexp to search it with a regexp-matcher. And as elisp is not that much optimized yet, this is going to be slower, not speaking of making uselessly the implementation more complex and difficult to understand. > Matching beginning and end of words works with `string': > > (string "\\") Damn! I forgot a backslash! If only elisp RE weren=E2=80=99t two levels of interpretation away from read (one for "\n" et all, the other for RE-level "(" et al). > In isearch, it's possible to enter only one backslash, but el-search > patterns are sexps, so you must escape the escape character to get one > escape character as in any Lisp expression. Indeed. >> > It doesn't have this feature (yet). I guess I could add it, but >> > el-search not really fits for the task. You can combine patterns >> > matching strings in any way. For example, you could search for >> > something like >> > >> > (or (and (string REGEXP1) (string REGEXP2) (pred SOME-PRED)) >> > SOMETHING-DIFFERENT)) >> > >> > so it's not even always well-defined what is intended to be >> > highlighted. >> >> I=E2=80=99d say: the return value of the last pattern, or everything if = =E2=80=9Ct=E2=80=9D. >> So, with a pattern written this way, it would be the whole thing (or the >> submatch matched by =E2=80=9CSOMETHING-DIFFERENT=E2=80=9D), while if wri= tten like =E2=80=9C(or >> (and (pred SOME-PRED) (string REGEXP1) (string REGEXP2)) >> SOMETHING-DIFFERENT))=E2=80=9D it would *always* match the submatch. Bu= t I=E2=80=99m >> unaware of pcase implemantation. It seems to be fairly complex, so it >> might be complex as well to do something alike. > > Yeah, it's not that simple: patterns do not have return values, and side > effects (like changing match data) for matching are tricky. It=E2=80=99s sad they use side effects. Maybe returning a pair of first ch= ar + end char? so (cons (string-match ...) (match-end)), typically. The tricky part is it should be automatically inserted when using string-match, so you don=E2=80=99t need to worry about it=E2=80=A6 Or mayb= e defining it as a pattern (but then it won=E2=80=99t work in other guards): #+BEGIN_SRC emacs-lisp (pcase-defmacro string-match (pattern) `(and (pred stringp) string (guard (cons (string-match ,sequence string) (match-end))))) #+END_SRC Or rather: I wonder if using scoping (maybe it would require dynamical binding? or maybe rather won=E2=80=99t work without lexical binding) you co= uld locally (using cl-flet, or macrolet) redefine string-match upon its former definition, in the appropriated functions so that it returns a cons of its result and the return value of `match-end'. >> Normally a package should be usable withut defining any key. > > Well, it's usable without keys, but then you have no ... keys ... for > going to the next match, etc, as you wanted. That=E2=80=99s why I missed isearch: even if I had no key for isearch-forwa= rd, it just works inside it, because it defines a mode where some normally scrolling-related keys behaves semantically with respect to it: it would be really handy if it was based on isearch and therefore compatible with it. >> That=E2=80=99s (part of) the whole point of package recommandation not to >> define keys: users should decide how they access the interface. And >> then it=E2=80=99s preferable it=E2=80=99s if convenient of course but I = find this >> pushes a bit too much for binding keys: I=E2=80=99m bad at choices and f= inding >> myself a prefix key will let me unsatisfied (and above all: require me >> to learn them, which I don=E2=80=99t have (yet) the time or will to inve= st >> in), > > Then I suggest to simply follow the suggestion in the commentary and use > M-s e as prefix. As I said, I don=E2=80=99t want to bind keys until I=E2=80=99m used to regu= larely use a command: otherwise I=E2=80=99ll have really a hard time remembering the key= , and each time I want to call the command I=E2=80=99ll have to go back to my ini= t.el file to find for my keybindings, kill the buffer, return the original one, then call the keybinding: in the end either I only use the command name and forget the keys, or stop to use the command. That=E2=80=99s what happened to me a lot after discovering iy-go-to-char (which still suffer from its quite nonsensical =E2=80=9Ciy=E2=80=9D name), multiple-cursors, et= c. So without a solution using semantical, common, potentially scrolling-related, keys, I=E2=80=99ll keep doing =E2=80=9CM-x = =E2=80=9D. I will have no problem remembering what follow the prefix, if it=E2=80=99s semantical enough, but I see no mnemotecnic reason for remembering the prefix key sequence. >> and the =E2=80=9Cshift=E2=80=9D thing is specific to qwerty (=E2=80=9C%= =E2=80=9D doesn=E2=80=99t use >> shift on my keyboard, while others keys do (for instance =E2=80=9Cshift+= %=E2=80=9D is >> =E2=80=9C`=E2=80=9D here)). > > Well, I can only predefine bindings, then you have to use these, or you > have to make choices... Yes of course. It=E2=80=99s normal. It=E2=80=99s only to note that making= assumptions on others layout is generally a bad idea (so refering to shift is more a qwerty-local feature, otherwise it just happens all these keys are left undefined by default) > Do you use neo or something like that? What is neo? > Of course you can define bindings on your own, but there are quite a few > in different maps needed, so I predefined the commands that can do this > for the user for convenience. I thought this would especially help > people to try the package quickly. Well it=E2=80=99s surely quicker than redefining everything. But still req= uires to open your init file, check for your keybindings (just in case), and add this line, then keep in mind the prefix for the time of trying. That=E2=80=99s well better than not defining anything, I=E2=80=99m just say= ing that for an interaction that commonly request repetition, it would have been better to have something like isearch. Imho keystrokes are for doing something quicker when you need to do it often or repetedly: otherwise commands names are what you use for trying. =E2=80=9CFor trying=E2=80=9D, personally, I=E2=80=99ll never bothe= r trying to check 2 to 5 times to remember the correct prefix. >> Why not, by default, be compatible with isearch? I=E2=80=99m not totall= y aware >> yet of the whole implementation of isearch, but it seems like it=E2=80= =99 based >> on a mode: maybe a clean and modular way to do that would to make >> derived-mode out of it? or find another way of reusing its library: >> this way it would stay forward-compatible with it, and benefit from >> further additions and improvements made to it. > > When I wrote el-search, I considered compatibility with isearch, but > there are too many requirements for el-search that where incompatible > or impossible to do with isearch ([=E2=80=A6]) So incompatibility with > Isearch is intentional, sorry. Oh, that=E2=80=99s sad: then maybe something alike? like activating a mode = with a different keymap while the search, that=E2=80=99ll quit when triggering an external key. > matches completely inside matches; interruptible (multi-buffer) > search and query-replace, concurrent match count in the background, > and many more things I didn=E2=80=99t understand what=E2=80=99s a single example of them (and no= t even understood the syntax of the first (is one of =E2=80=9Cmatches=E2=80=9D a v= erb? are they both substantive? if so do they refer to the same match?)). If they=E2=80= =99re so important so to justify incompatibility with something so important in emacs as isearch, maybe isearch should change, and potentially gain these capabilities? Did you try or asked its authors?