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

["Garreau\, Alexandre" <galex-713@galex-713.eu>]

Le 28/10/2018 à 23h26, Michael Heerdegen a écrit :
> "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.

Didn’t know that!  I take it as a good point for what I was suggesting
initially, if it already exists.

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

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

> There is another reason it's called "string" btw: if you use it without
> any arguments, it matches strings.

(pred stringp) is more well named, readable, understandable, and
standard for that.  That’s not a sufficent reason to give a bad name to
a such pattern.

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

Not if, as I suggested, there’s some way to evaluate the patterns so
that they return a value.

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

Maybe a such feature should be integrated into pcase?  el-search seems a
pretty awesome compliment to what pcase can allow to achieve, so it
seems reasonable to provide facilities for utilities alike to perform
extensible stuff with patterns, beside conditionals, without side
effects (I was more thinking about tweaking or advicing some pcase
internal function or macro, rather than putting side effects in
patterns, anyway)

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

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.

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

What’s even more funny (beside its sad part) is our government made
illegal “foreign” letters, such as ñ, nowadays absent of french, and
until then essentially used by Spanishes, because it is used by basques
and bretons, two peoples in France territory with strong proportion of
indepentists, and, more importantly, for French State: they have their
own language, which is deemed inadmissible by government of “indivisible
France where only *one* language of the republic shall exist and be
allowed” (which is even more funny when we know this letter, at the same
time it entered breton and basque, some centuries ago, actually was used
in french and is present in some old kings discourses).

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

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.

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

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?

> I guess you would want to use help key to see the meaningful keys?

I guess so, isearch do that (it displays its docstring actually).