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

[Michael Heerdegen <michael_heerdegen@web.de>]

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

> If rx is available in pcase, then, it is already in el-search anyway,
> right?

Sure!

> > 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.
>
> Maybe a such feature should be integrated into pcase?

In pcase' real life it is not really a restriction since you can export
any information via variables.  Therefore you gain cleaner code: no side
effects by pattern matching, side effects (possibly) in the bodies.

Wouldn't it be confusing if there was an (and P1 P2 P3 P4), and P1, P2,
P3 would cause side effects, and matching P4 finally fails (and so the
whole pattern)?

> Not if you want to condition that according contextual sexp patterns.
> And it will still be easier and cleaner to replace only in strings
> using el-search than a complex half-lisp-parsing regexp in isearch.

My current solution is that el-search will allow you to hit a key (it
will be "e") to edit a match manually in a separate buffer.

el-search is not really good at "text processing" since it currently
completely ignores comments.

> If it was well written enough, it should be easy to take extra features
> apart, and modularily change the base while still keeping the basic
> thing working, then progressively adapt the (hopefully modular)
> features.  But that’s the ideal state and I guess it’s only in a better
> shape than other similarily complex features of emacs.

I don't know, really.  But you would have to expect to introduce a lot
of bugs.  I'm not against what you propose, it's just my time
is...limited.

> Yes, as a map, without prefix, as you invoked it anyway.  And to quit
> you hit <backspace>.  Do you think that would bother other more
> use-once usages?

The problem here is that if a user doesn't like the default bindings, he
needs to remove them explicitly.  Since there are already two very
different suggested binding schemes (AFAIR they also slightly
interfere), I decided against that.  I'll think about what could be a
good solution.


Michael.