Re: el-search usage (doc, strings, pcase, etc.)

[Garreau, Alexandre]

Le 27/10/2018 à 17h43, Michael Heerdegen a écrit :
> Hello Garreau",
>
> thanks for your feedback.
>
>> Other packages have an info file
>
> Ok, it's on my list.  I also want to record a demonstration video and
> upload it somewhere, and add a live help command you can use while
> searching to see the most important keys.

It’s pretty quick : translate your markdown/rst (which one?) into
org-mode, you basically have to remove the header “====” underlining
text, and replace that by prefixing stars “*”.  Then you do “C-c C-e i
i” and you get an info file.

>> In my memories it was confused, so I was going to try doing the
>> opposite: searching a string being or containing “was” (or “was:”) in
>> gnus’ source (/usr/share/emacs/25.1/lisp/gnus/), avoiding comments and
>> symbols, so to find the function removing exagerated “(was: old
>> subject)” in subject lines when replying.  But I found nothing relevant
>> being it, and many docstring contain it :/
>
> Yes, that's a very common use case.

it would 

>> I tried “(and (pred stringp) s (guard (string-match "\<was\>:" s)))”,
>> however that is long to type, so I found very very unfortunate el-search
>> doesn’t seem to maintain a prompt history (why so? it is easy, just a
>> symbol, so to put a list there).
>
> Of course it has one.  Doesn't M-p work for you?

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…

> BTW, the solution for your problem is the `string' pattern which exactly
> does this: search for strings that match the argument(s).  Like
>
>   (string "was")

Oh interesting, and it even support non-regexp patterns… but I find it
odd it use “string”.  I would have expected string to destructure in
characters just as the `string' function does in elisp…

> 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’s pretty complex…  I hoped it was for pure text (so it’s easier to
enter “special” characters such as “\\” or “(”), not regexps… but
strangely it seems not to support “<” and “>” to match beginning/end of
words.

>> However it probably call for a pcase macro such as “(pcase-defmacro
>> contain (match-string) `(and (pred stringp) string (guard
>> (string-match ,match-string string))))”, but the problem is then it
>> highlights the whole string, instead of the matched part (while this
>> should be easily usable since this macro actually returns position of
>> match (and match-end its end)), and el-search-defpattern doesn’t seem
>> to offer a way to do so (match for a subpattern according its context,
>> or maybe I’m not enough educated of pcase complex mecanics).
>
> 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’d say: the return value of the last pattern, or everything if “t”.
So, with a pattern written this way, it would be the whole thing (or the
submatch matched by “SOMETHING-DIFFERENT”), while if written like “(or
(and (pred SOME-PRED) (string REGEXP1) (string REGEXP2))
SOMETHING-DIFFERENT))” it would *always* match the submatch.  But I’m
unaware of pcase implemantation.  It seems to be fairly complex, so it
might be complex as well to do something alike.

>> As the search usage (keystrokes, etc.) seem to be quite different than
>> from isearch (it seems to highlight it specially but doesn’t rebind
>> special keystrokes (moving exit it (and scrolling commands such as SPC
>> or <backspace> do exit it too) and I don’t know how to go to next
>> occurence (maybe I should learn how to use occur so to know how to use
>> it?))), I’m a bit lost.
>
> The file header should tell it...?  Depending on the set of key bindings
> you installed, you get to the next match with C-S (i.e. control-shift-s)
> or just s.  Backwards with C-R or r.  You need to install a set of key
> bindings to make this work - loading the package doesn't define any
> keys.

Normally a package should be usable withut defining any key.  That’s
(part of) the whole point of package recommandation not to define keys:
users should decide how they access the interface.  And then it’s
preferable it’s if convenient of course but I find this pushes a bit too
much for binding keys: I’m bad at choices and finding myself a prefix
key will let me unsatisfied (and above all: require me to learn them,
which I don’t have (yet) the time or will to invest in), and the “shift”
thing is specific to qwerty (“%” doesn’t use shift on my keyboard, while
others keys do (for instance “shift+%” is “`” here)).

>> I’m used to be able not to bind keystrokes for command I’m not yet a
>> regular user of (otherwise I just bind the key and forget it, so I end
>> loosing keybindings for thing I’d actually need), but it seems
>> el-search enforces the opposite of that, since to continue a search I
>> *need* to repetedly run the command (which gives a lot of “M-x <up>
>> <return>”).
>
> I see, good point.  I think this is something that would not be hard to
> implement.  There exist transient maps to make the keys repeatable.  It
> should be possible to only set up the transient maps but avoid to
> install any global key bindings.

Why not, by default, be compatible with isearch?  I’m not totally aware
yet of the whole implementation of isearch, but it seems like it’ 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.