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

[Garreau, Alexandre]

On 2018-10-28 at 02:01, Michael Heerdegen wrote:
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>> 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.

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?

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

No, I just didn’t know “pred” consed and eval’d, rather than just
applying, so it could take something else than a symbol or function as a
parameter: but I should have guessed, as its parameter isn’t quoted.

This way looks cleaner.

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

“contain” was already what I suggested first, “has” looks more english,
but is understood enough, yet it is a conjugated verb…  it might be
okay: and still since that works for sequences in general, it might be
used as general.

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

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

which better looks like yours.

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

Ah maybe indeed…  But this is dirty then, to have to use it for
non-regexp input, and not to have a cleartext string-matching function
(only search-forward/backward).

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

Any non-nil value is true, hence a boolean.

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

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

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

Ah yeah I recall it now (I saw its website once in a while, when someone
else pointed at it)! I use Bépo, it’s optimized for french.  I guess
both of ours are made out of Dvorak methods.

Bépo was made in 2003, mostly automatically generated from a huge data
corpus (mainly renaissance/revolution writings, old books, and
wikipedia), then tweaked out to better support programming, english, all
EU languages (including greek, but, since recently, excluding
cyrillic-based ones, for now (will later be fixed)), most african
languages from francophone countries (and some others), esperanto, and
some maths symbols, + unicode modifiers (and almost all currency
symbols, and latin diacritics).

Afaik % was put in direct access because a lot used in accountability, C
programming, et al, but I’ll ask on the mailing-list to know.

There’s more activity now as we’re on to normalize it on a national
level (to AFNOR, local equivalent to ANSI or ISO), aside with (yet
another) (incompatible) new azerty, so it gets validated by government
and maybe even integrated in general-purpose computers, while allowing
to write *correct* french, unlike what most current azerty provide (no
capitals for diacriticed letters, no french quotemarks, no en or em
dashes, no median point (nowadays medias started to (finally) use it for
feminization a few years ago), no unbreakable (fine, large, and/or
justifiable or not) space, 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), our alphabet
officially counts no more 41.5 but 42 letters (exactely twice as in
italian, except here it’s 21 voyels and 21 consonants), and previous
azerty didn’t allow to write them all), no curved quotes, no curved
apostrophe, no suspension mark, etc.).

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

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)

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

Okay, that seems a good reason.  It’s sad isearch is that complex.
Maybe it could (should?) be tidied?

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

I think too experimentation is good, but not at the expense of
consistence: wouldn’t there a way to make something different from
isearch, but with a similar API, so other packages could use it instead
of isearch, or el-search could use isearch instead of it (loosing some
of its capabilities then, of course).  Would be more modular, and if it
indeed gets used, that at the same time could help experiment and
improve it, and push for isearch to integrate the other features, if
they appears to be that much wanted.

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

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)?