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

[Michael Heerdegen]

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

> Yeah, and the package description in list-packages, and its related
> -readme.txt file, looks like rst or markdown, that’s what I meant:
> convert that comment to org-mode like structuration, so then you can use
> the commentary extracted by packaging tool, export to texinfo, which
> will convert to many other formats, including info.

Ok, will try this when I have the time.

> Okay now that’s strange: here, C-p and C-n browse the history with M-x,
> in emacs -Q, -q, etc.  Maybe debian modified it to do so?

It didn't have a chance, I build Emacs from master.  This is really a
mystery.

> Yeah, like I regularely do with `eval-expression': wherever it is it or
> M-x, C-p and C-n already move by lines, but when you’re at the first or
> last line, respectively, instead of erring out “\(Beginning\|End\) of
> buffer”, they browse history: much more expressive and handy.

I know that `minibuffer-local-map' has bindings for up and down to
`previous-line-or-history-element' and `next-line-or-history-element'
(see bindings.el).  I could do the same for el-search.  I still don't
get where your control bindings come from.

> What, this is specific to el-search? why that? I’m almost sure it could
> be useful in pcase as well (did you try to propose it?).

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.

> Then, may I change the definition of the macro, so not to accept
> regexps anymore, so to use `search' instead?
>
> #+BEGIN_SRC emacs-lisp
>   (pcase-defmacro in (pattern)
>     `(and (pred sequencep)
>           sequence
>           (guard (search pattern ,sequence))))
> #+END_SRC

I would write it as

#+begin_src emacs-lisp
(pcase-defmacro in (pattern)
  `(and (pred sequencep)
        (pred (cl-search ,pattern))))
#+end_src

But if you use it, it reads really awkward, right?

(pcase (list 1 2 4)
  ((in '(2)) t))
==> t

"has" or "contains" would be easier to read (el-search also has
"contains" btw, but it works recursively).  The direction of the word
"in" is just wrong.

> Now it works for all sequences, with the very extremely (let’s postulate
> one-letter is not reasonable, so this is an extreme) short “in” name,
> found in “inside”, “include”, “intra”, “inter”, “contain”, etc. (other
> possibility was “sub”, already used as an abbreviated name for set
> inclusion).  So now, to contrast with this oddly not-RE aware function,
> we make the RE one:
>
> #+BEGIN_SRC emacs-lisp
>   (pcase-defmacro re (pattern)
>     `(and (pred stringp)
>           string
>           (guard (string-match ,sequence string))))
> #+END_SRC

> Or, if you find that not understandable enough, you can choose instead
> `re-in', but I find it redundant, as it is imply by the used re that it
> is “in”, from the point you choose not to use el-re-specific \` and
> \'.

One reason I chose "string" was that it is obvious with this name that
the pattern performs an implicit stringp test.  It's important that
people don't need to remember it.  Something named "regexp" suggests the
opposite imho.

> > A literal string match pattern is easy to implement:
> >
> > (el-search-defpattern string-literal (s)
> >   `(string ,(regexp-quote s)))
>
> This is so dirty, because in the end you quote a regexp to search it
> with a regexp-matcher.  And as elisp is not that much optimized yet,
> this is going to be slower, not speaking of making uselessly the
> implementation more complex and difficult to understand.

I would expect that the optimized regexp matcher implemented in C is
still faster if "misused" that way as the slow elisp-implemented
cl-search function.

> It’s sad they use side effects.  Maybe returning a pair of first char +
> end char? so (cons (string-match ...) (match-end)), typically.  The
> tricky part is it should be automatically inserted when using
> string-match, so you don’t need to worry about it…  Or maybe defining it
> as a pattern (but then it won’t work in other guards):
>
> #+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.  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.  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).


> > Do you use neo or something like that?
>
> What is neo?

An optimized keyboard layout.  I thought you could be using something
like that.  But ok, I'm sorry, it's optimized for German.

So, why don't you need shift to enter % with your keyboard?

> Oh, that’s sad: then maybe something alike? like activating a mode with
> a different keymap while the search, that’ll quit when triggering an
> external key.

el-search already has that.  Not using a minor mode, but a transient
map.  Yet this map is not prefilled because the two suggested binding
schemes lead to different bindings also in this transient map.

> > matches completely inside matches; interruptible (multi-buffer)
> > search and query-replace, concurrent match count in the background,
> > and many more things
>
> I didn’t understand what’s a single example of them (and not even
> understood the syntax of the first (is one of “matches” a verb? are they
> both substantive? if so do they refer to the same match?)).

Substantive, and no, different matches.  Simple example: you have a
buffer containing only

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

> If they’re so important so to justify incompatibility with something
> so important in emacs as isearch, maybe isearch should change, and
> potentially gain these capabilities?  Did you try or asked its
> authors?

I think the result could be worth it, but given that isearch is already
heavily complex, it would be an immense task.

So I decided for myself to start from scratch and experiment with a
different user interface, mainly for fun and because I think that it
would be beneficial, not because I dislike isearch (which I don't).

Another reason was that el-search started as an experiment, and I just
didn't know how and to what it would develop.  Now I think it would be
worth to get some ideas into isearch but I also still want to experiment
with el-search's interface and see how it develops.  I still get new
ideas for what could be convenient and like that it's easy for me to try
things out.


Michael.