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

[Michael Heerdegen]

"Garreau, Alexandre" <galex-713@galex-713.eu> 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…  Then maybe el-search should define it still as a pcase pattern,
> so that it might use it, and users might copy and use it until it’s
> 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’t see how: regexp always match strings, and most of time are
> strings.  Though they may be lists… 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’t offer a straightforward way to get the return
> 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’s something
> eval’able)).

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 æ nor œ nor ÿ (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’s 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’t yet overrun the next (which I find sad: so if you search
> from different positions, you may get completely different result sets
> for “t.*?t” for instance)

Yeah, we would have to rethink what "match" means and how they are
ordered.

> Okay, that seems a good reason.  It’s 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’t it be possible to make it inherit the current
> 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.