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

[Michael Heerdegen]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> It’s pretty quick : translate your markdown/rst (which one?)

Currently I only have the comment in the file header.

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

In emacs -Q, C-p and C-n don't browse the history for M-x.  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.

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

First of all I wanted a name that is short, because it is one of the
most often used pattern types.  Any better idea?

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

A literal string match pattern is easy to implement:

(el-search-defpattern string-literal (s)
  `(string ,(regexp-quote s)))

Then you can e.g. search for (string-literal "**") to search for string
containing two subsequent star chars.

Matching beginning and end of words works with `string':

  (string "\\<word\\>")

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.

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

Yeah, it's not that simple: patterns do not have return values, and side
effects (like changing match data) for matching are tricky.

> 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’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),

Then I suggest to simply follow the suggestion in the commentary and use
M-s e as prefix.

> and the “shift” thing is specific to qwerty (“%” doesn’t use
> shift on my keyboard, while others keys do (for instance “shift+%” is
> “`” here)).

Well, I can only predefine bindings, then you have to use these, or you
have to make choices...

Do you use neo or something like that?

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.

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

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 (matches completely inside matches;
interruptible (multi-buffer) search and query-replace, concurrent match
count in the background, and many more things).  So incompatibility with
Isearch is intentional, sorry.


Michael.