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

[Michael Heerdegen <michael_heerdegen@web.de>]

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.

> Btw I really liked what I did read at some point about if you search for
> 27, it will not match for text or comments (yet I barely need to search
> for numbers usually): that makes it look pretty semantic (does it uses
> `read', `eval' or something?).

Yes, it's based on `read'.

> 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.

> 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?

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")

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.

> 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.  Strings are atomic objects to el-search, so I decided to
make the interface reflect this.  This doesn't mean that el-search can't
be used to replace words inside strings, for example - it would just
replace matching strings completely with a new string with the relevant
words replaced.

> 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.

> 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.


Thanks,

Michael.