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

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

[Garreau, Alexandre]

On 2018/10/17 at 17:42, Michael Heerdegen wrote:
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>>> Also, package `el-search.el' has similar possibilities (and many other
>>> good things).
>>
>> Wow it seems cool, I’ll try it out when I’ve got time if I remember to.
>> I’ve dreamt of it I think.
>
> If you happen to try it, I'm curious for your feedback, especially if
> you find bugs, something doesn't work as expected, the documentation
> isn't helpful enough, etc.

Other packages have an info file: maybe writing the doc in texinfo and
then exporting to org-mode (or the other way around: writing in org-mode
and exporting to texinfo), could be useful so to get an info
documentation accessible with C-h i.  I have the general habit of
searching with C-h i and docstrings only, but when a package is not
reified around an unique “main” command, usually its package name, so
its docstring can serves both as a mini reference and tutorial for
introducing the package (maybe it would be the case of el-search for
`el-search-pattern'? but then it would better be rather named
`el-search', and its docstring should be more detailed, otherwise it
requires guessing `el-search-pattern' is the main interface, or rather
using the manual for discovering so, which may cause great confusion to
the lazy user).  When a package doesn’t have this, for instance an
addition to a mode, or several modes, or a language feature (“gnorb”,
emms, eieio, etc.).

Btw I really liked what I did read at some point about if you search for
27, it will not match for text or comments (yet I barely need to search
for numbers usually): that makes it look pretty semantic (does it uses
`read', `eval' or something?).

In my memories it was confused, so I was going to try doing the
opposite: searching a string being or containing “was” (or “was:”) in
gnus’ source (/usr/share/emacs/25.1/lisp/gnus/), avoiding comments and
symbols, so to find the function removing exagerated “(was: old
subject)” in subject lines when replying.  But I found nothing relevant
being it, and many docstring contain it :/

I tried “(and (pred stringp) s (guard (string-match "\<was\>:" s)))”,
however that is long to type, so I found very very unfortunate el-search
doesn’t seem to maintain a prompt history (why so? it is easy, just a
symbol, so to put a list there).  However it probably call for a pcase
macro such as “(pcase-defmacro contain (match-string) `(and (pred
stringp) string (guard (string-match ,match-string string))))”, but the
problem is then it highlights the whole string, instead of the matched
part (while this should be easily usable since this macro actually
returns position of match (and match-end its end)), and
el-search-defpattern doesn’t seem to offer a way to do so (match for a
subpattern according its context, or maybe I’m not enough educated of
pcase complex mecanics).

As the search usage (keystrokes, etc.) seem to be quite different than
from isearch (it seems to highlight it specially but doesn’t rebind
special keystrokes (moving exit it (and scrolling commands such as SPC
or <backspace> do exit it too) and I don’t know how to go to next
occurence (maybe I should learn how to use occur so to know how to use
it?))), I’m a bit lost.  I’m used to be able not to bind keystrokes for
command I’m not yet a regular user of (otherwise I just bind the key and
forget it, so I end loosing keybindings for thing I’d actually need),
but it seems el-search enforces the opposite of that, since to continue
a search I *need* to repetedly run the command (which gives a lot of
“M-x <up> <return>”).

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

[Michael Heerdegen]

Hello Garreau",

thanks for your feedback.

> Other packages have an info file

Ok, it's on my list.  I also want to record a demonstration video and
upload it somewhere, and add a live help command you can use while
searching to see the most important keys.

> Btw I really liked what I did read at some point about if you search for
> 27, it will not match for text or comments (yet I barely need to search
> for numbers usually): that makes it look pretty semantic (does it uses
> `read', `eval' or something?).

Yes, it's based on `read'.

> In my memories it was confused, so I was going to try doing the
> opposite: searching a string being or containing “was” (or “was:”) in
> gnus’ source (/usr/share/emacs/25.1/lisp/gnus/), avoiding comments and
> symbols, so to find the function removing exagerated “(was: old
> subject)” in subject lines when replying.  But I found nothing relevant
> being it, and many docstring contain it :/

Yes, that's a very common use case.

> I tried “(and (pred stringp) s (guard (string-match "\<was\>:" s)))”,
> however that is long to type, so I found very very unfortunate el-search
> doesn’t seem to maintain a prompt history (why so? it is easy, just a
> symbol, so to put a list there).

Of course it has one.  Doesn't M-p work for you?

BTW, the solution for your problem is the `string' pattern which exactly
does this: search for strings that match the argument(s).  Like

  (string "was")

The available pattern types are listed in C-h f
el-search-defined-patterns.  BTW, the arguments of `string' can also be
an "extended regexp" - that's a regexp plus a list of bindings like in

  (string (((case-fold-search nil)) "was"))

which would match "I was" but not "I Was", or a predicate accepting a
string.

> However it probably call for a pcase macro such as “(pcase-defmacro
> contain (match-string) `(and (pred stringp) string (guard
> (string-match ,match-string string))))”, but the problem is then it
> highlights the whole string, instead of the matched part (while this
> should be easily usable since this macro actually returns position of
> match (and match-end its end)), and el-search-defpattern doesn’t seem
> to offer a way to do so (match for a subpattern according its context,
> or maybe I’m not enough educated of pcase complex mecanics).

It doesn't have this feature (yet).  I guess I could add it, but
el-search not really fits for the task.  You can combine patterns
matching strings in any way.  For example, you could search for
something like

  (or (and (string REGEXP1) (string REGEXP2) (pred SOME-PRED))
      SOMETHING-DIFFERENT))

so it's not even always well-defined what is intended to be
highlighted.  Strings are atomic objects to el-search, so I decided to
make the interface reflect this.  This doesn't mean that el-search can't
be used to replace words inside strings, for example - it would just
replace matching strings completely with a new string with the relevant
words replaced.

> As the search usage (keystrokes, etc.) seem to be quite different than
> from isearch (it seems to highlight it specially but doesn’t rebind
> special keystrokes (moving exit it (and scrolling commands such as SPC
> or <backspace> do exit it too) and I don’t know how to go to next
> occurence (maybe I should learn how to use occur so to know how to use
> it?))), I’m a bit lost.

The file header should tell it...?  Depending on the set of key bindings
you installed, you get to the next match with C-S (i.e. control-shift-s)
or just s.  Backwards with C-R or r.  You need to install a set of key
bindings to make this work - loading the package doesn't define any
keys.

> I’m used to be able not to bind keystrokes for command I’m not yet a
> regular user of (otherwise I just bind the key and forget it, so I end
> loosing keybindings for thing I’d actually need), but it seems
> el-search enforces the opposite of that, since to continue a search I
> *need* to repetedly run the command (which gives a lot of “M-x <up>
> <return>”).

I see, good point.  I think this is something that would not be hard to
implement.  There exist transient maps to make the keys repeatable.  It
should be possible to only set up the transient maps but avoid to
install any global key bindings.


Thanks,

Michael.

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

[Michael Heerdegen]

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

> occurence (maybe I should learn how to use occur so to know how to use
> it?)))

BTW, if you speak about el-search-occur, you can simply hit M-RET
instead of RET from the pattern prompt and you start the search as
el-occur instead of an interactive search.


Michael.

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

[Garreau, Alexandre]

Le 27/10/2018 à 17h43, Michael Heerdegen a écrit :
> Hello Garreau",
>
> thanks for your feedback.
>
>> Other packages have an info file
>
> Ok, it's on my list.  I also want to record a demonstration video and
> upload it somewhere, and add a live help command you can use while
> searching to see the most important keys.

It’s pretty quick : translate your markdown/rst (which one?) into
org-mode, you basically have to remove the header “====” underlining
text, and replace that by prefixing stars “*”.  Then you do “C-c C-e i
i” and you get an info file.

>> In my memories it was confused, so I was going to try doing the
>> opposite: searching a string being or containing “was” (or “was:”) in
>> gnus’ source (/usr/share/emacs/25.1/lisp/gnus/), avoiding comments and
>> symbols, so to find the function removing exagerated “(was: old
>> subject)” in subject lines when replying.  But I found nothing relevant
>> being it, and many docstring contain it :/
>
> Yes, that's a very common use case.

it would 

>> I tried “(and (pred stringp) s (guard (string-match "\<was\>:" s)))”,
>> however that is long to type, so I found very very unfortunate el-search
>> doesn’t seem to maintain a prompt history (why so? it is easy, just a
>> symbol, so to put a list there).
>
> Of course it has one.  Doesn't M-p work for you?

Oh, indeed it works.  I would have expected C-p/C-n and arrow keys to
work too, like in M-x.  I only use M-p in real buffer such as with
comint-mode modes, barely with minibuffer (as I never wrote more than
two lines of text in it, and with a few lines M-p is only barely useful,
and C-p still work).  Normally using C-p with both `read-string' (which I
last used) and `read-from-minibuffer' (which el-search-pattern seems to
use) support it just as M-x…

> BTW, the solution for your problem is the `string' pattern which exactly
> does this: search for strings that match the argument(s).  Like
>
>   (string "was")

Oh interesting, and it even support non-regexp patterns… but I find it
odd it use “string”.  I would have expected string to destructure in
characters just as the `string' function does in elisp…

> The available pattern types are listed in C-h f
> el-search-defined-patterns.  BTW, the arguments of `string' can also
> be an "extended regexp" - that's a regexp plus a list of bindings like
> in
>
>   (string (((case-fold-search nil)) "was"))
>
> which would match "I was" but not "I Was", or a predicate accepting a
> string.

That’s pretty complex…  I hoped it was for pure text (so it’s easier to
enter “special” characters such as “\\” or “(”), not regexps… but
strangely it seems not to support “<” and “>” to match beginning/end of
words.

>> However it probably call for a pcase macro such as “(pcase-defmacro
>> contain (match-string) `(and (pred stringp) string (guard
>> (string-match ,match-string string))))”, but the problem is then it
>> highlights the whole string, instead of the matched part (while this
>> should be easily usable since this macro actually returns position of
>> match (and match-end its end)), and el-search-defpattern doesn’t seem
>> to offer a way to do so (match for a subpattern according its context,
>> or maybe I’m not enough educated of pcase complex mecanics).
>
> It doesn't have this feature (yet).  I guess I could add it, but
> el-search not really fits for the task.  You can combine patterns
> matching strings in any way.  For example, you could search for
> something like
>
>   (or (and (string REGEXP1) (string REGEXP2) (pred SOME-PRED))
>       SOMETHING-DIFFERENT))
>
> so it's not even always well-defined what is intended to be
> highlighted.

I’d say: the return value of the last pattern, or everything if “t”.
So, with a pattern written this way, it would be the whole thing (or the
submatch matched by “SOMETHING-DIFFERENT”), while if written like “(or
(and (pred SOME-PRED) (string REGEXP1) (string REGEXP2))
SOMETHING-DIFFERENT))” it would *always* match the submatch.  But I’m
unaware of pcase implemantation.  It seems to be fairly complex, so it
might be complex as well to do something alike.

>> As the search usage (keystrokes, etc.) seem to be quite different than
>> from isearch (it seems to highlight it specially but doesn’t rebind
>> special keystrokes (moving exit it (and scrolling commands such as SPC
>> or <backspace> do exit it too) and I don’t know how to go to next
>> occurence (maybe I should learn how to use occur so to know how to use
>> it?))), I’m a bit lost.
>
> The file header should tell it...?  Depending on the set of key bindings
> you installed, you get to the next match with C-S (i.e. control-shift-s)
> or just s.  Backwards with C-R or r.  You need to install a set of key
> bindings to make this work - loading the package doesn't define any
> keys.

Normally a package should be usable withut defining any key.  That’s
(part of) the whole point of package recommandation not to define keys:
users should decide how they access the interface.  And then it’s
preferable it’s if convenient of course but I find this pushes a bit too
much for binding keys: I’m bad at choices and finding myself a prefix
key will let me unsatisfied (and above all: require me to learn them,
which I don’t have (yet) the time or will to invest in), and the “shift”
thing is specific to qwerty (“%” doesn’t use shift on my keyboard, while
others keys do (for instance “shift+%” is “`” here)).

>> I’m used to be able not to bind keystrokes for command I’m not yet a
>> regular user of (otherwise I just bind the key and forget it, so I end
>> loosing keybindings for thing I’d actually need), but it seems
>> el-search enforces the opposite of that, since to continue a search I
>> *need* to repetedly run the command (which gives a lot of “M-x <up>
>> <return>”).
>
> I see, good point.  I think this is something that would not be hard to
> implement.  There exist transient maps to make the keys repeatable.  It
> should be possible to only set up the transient maps but avoid to
> install any global key bindings.

Why not, by default, be compatible with isearch?  I’m not totally aware
yet of the whole implementation of isearch, but it seems like it’ based
on a mode: maybe a clean and modular way to do that would to make
derived-mode out of it? or find another way of reusing its library:
this way it would stay forward-compatible with it, and benefit from
further additions and improvements made to it.

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

[Michael Heerdegen]

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

> It’s pretty quick : translate your markdown/rst (which one?)

Currently I only have the comment in the file header.

> Oh, indeed it works.  I would have expected C-p/C-n and arrow keys to
> work too, like in M-x.  I only use M-p in real buffer such as with
> comint-mode modes, barely with minibuffer (as I never wrote more than
> two lines of text in it, and with a few lines M-p is only barely useful,
> and C-p still work).  Normally using C-p with both `read-string' (which I
> last used) and `read-from-minibuffer' (which el-search-pattern seems to
> use) support it just as M-x…

In emacs -Q, C-p and C-n don't browse the history for M-x.  Also, in
el-search, the pattern input buffer is in elisp-mode and often contains
multiline input, so I decided that up and down move by lines.  That's
beneficial when you write more complex patterns.

> Oh interesting, and it even support non-regexp patterns… but I find it
> odd it use “string”.  I would have expected string to destructure in
> characters just as the `string' function does in elisp…

First of all I wanted a name that is short, because it is one of the
most often used pattern types.  Any better idea?

> > The available pattern types are listed in C-h f
> > el-search-defined-patterns.  BTW, the arguments of `string' can also
> > be an "extended regexp" - that's a regexp plus a list of bindings like
> > in
> >
> >   (string (((case-fold-search nil)) "was"))
> >
> > which would match "I was" but not "I Was", or a predicate accepting a
> > string.
>
> That’s pretty complex…  I hoped it was for pure text (so it’s easier to
> enter “special” characters such as “\\” or “(”), not regexps… but
> strangely it seems not to support “<” and “>” to match beginning/end of
> words.

A literal string match pattern is easy to implement:

(el-search-defpattern string-literal (s)
  `(string ,(regexp-quote s)))

Then you can e.g. search for (string-literal "**") to search for string
containing two subsequent star chars.

Matching beginning and end of words works with `string':

  (string "\\<word\\>")

In isearch, it's possible to enter only one backslash, but el-search
patterns are sexps, so you must escape the escape character to get one
escape character as in any Lisp expression.

> > It doesn't have this feature (yet).  I guess I could add it, but
> > el-search not really fits for the task.  You can combine patterns
> > matching strings in any way.  For example, you could search for
> > something like
> >
> >   (or (and (string REGEXP1) (string REGEXP2) (pred SOME-PRED))
> >       SOMETHING-DIFFERENT))
> >
> > so it's not even always well-defined what is intended to be
> > highlighted.
>
> I’d say: the return value of the last pattern, or everything if “t”.
> So, with a pattern written this way, it would be the whole thing (or the
> submatch matched by “SOMETHING-DIFFERENT”), while if written like “(or
> (and (pred SOME-PRED) (string REGEXP1) (string REGEXP2))
> SOMETHING-DIFFERENT))” it would *always* match the submatch.  But I’m
> unaware of pcase implemantation.  It seems to be fairly complex, so it
> might be complex as well to do something alike.

Yeah, it's not that simple: patterns do not have return values, and side
effects (like changing match data) for matching are tricky.

> Normally a package should be usable withut defining any key.

Well, it's usable without keys, but then you have no ... keys ... for
going to the next match, etc, as you wanted.

> That’s (part of) the whole point of package recommandation not to
> define keys: users should decide how they access the interface.  And
> then it’s preferable it’s if convenient of course but I find this
> pushes a bit too much for binding keys: I’m bad at choices and finding
> myself a prefix key will let me unsatisfied (and above all: require me
> to learn them, which I don’t have (yet) the time or will to invest
> in),

Then I suggest to simply follow the suggestion in the commentary and use
M-s e as prefix.

> and the “shift” thing is specific to qwerty (“%” doesn’t use
> shift on my keyboard, while others keys do (for instance “shift+%” is
> “`” here)).

Well, I can only predefine bindings, then you have to use these, or you
have to make choices...

Do you use neo or something like that?

Of course you can define bindings on your own, but there are quite a few
in different maps needed, so I predefined the commands that can do this
for the user for convenience.  I thought this would especially help
people to try the package quickly.

> Why not, by default, be compatible with isearch?  I’m not totally aware
> yet of the whole implementation of isearch, but it seems like it’ based
> on a mode: maybe a clean and modular way to do that would to make
> derived-mode out of it? or find another way of reusing its library:
> this way it would stay forward-compatible with it, and benefit from
> further additions and improvements made to it.

When I wrote el-search, I considered compatibility with isearch, but
there are too many requirements for el-search that where incompatible or
impossible to do with isearch (matches completely inside matches;
interruptible (multi-buffer) search and query-replace, concurrent match
count in the background, and many more things).  So incompatibility with
Isearch is intentional, sorry.


Michael.

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

[Garreau, Alexandre]

On 2018/10/27 at 22:19, Michael Heerdegen wrote:
> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>
>> It’s pretty quick : translate your markdown/rst (which one?)
>
> Currently I only have the comment in the file header.

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.

>> Oh, indeed it works.  I would have expected C-p/C-n and arrow keys to
>> work too, like in M-x.  I only use M-p in real buffer such as with
>> comint-mode modes, barely with minibuffer (as I never wrote more than
>> two lines of text in it, and with a few lines M-p is only barely useful,
>> and C-p still work).  Normally using C-p with both `read-string' (which I
>> last used) and `read-from-minibuffer' (which el-search-pattern seems to
>> use) support it just as M-x…
>
> In emacs -Q, C-p and C-n don't browse the history for M-x.

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?

However, if M-x accepts something, el-search input should be compatible
just the same, because both use read-* functions that behaves the same.
So if in your configuration M-x doesn’t accept C-p and C-n, then it’s
normal elsearch neither, but if in mine M-x does, elsearch should too.

> Also, in el-search, the pattern input buffer is in elisp-mode and
> often contains multiline input, so I decided that up and down move by
> lines.  That's beneficial when you write more complex patterns.

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.

>> Oh interesting, and it even support non-regexp patterns… but I find it
>> odd it use “string”.  I would have expected string to destructure in
>> characters just as the `string' function does in elisp…
>
> First of all I wanted a name that is short, because it is one of the
> most often used pattern types.  Any better idea?

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

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

“regexp” is about the same size of “contain”, so I didn’t mind it.

>> > The available pattern types are listed in C-h f
>> > el-search-defined-patterns.  BTW, the arguments of `string' can also
>> > be an "extended regexp" - that's a regexp plus a list of bindings like
>> > in
>> >
>> >   (string (((case-fold-search nil)) "was"))
>> >
>> > which would match "I was" but not "I Was", or a predicate accepting a
>> > string.
>>
>> That’s pretty complex…  I hoped it was for pure text (so it’s easier to
>> enter “special” characters such as “\\” or “(”), not regexps… but
>> strangely it seems not to support “<” and “>” to match beginning/end of
>> words.
>
> 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.

> Matching beginning and end of words works with `string':
>
>   (string "\\<word\\>")

Damn! I forgot a backslash!  If only elisp RE weren’t two levels of
interpretation away from read (one for "\n" et all, the other for
RE-level "(" et al).

> In isearch, it's possible to enter only one backslash, but el-search
> patterns are sexps, so you must escape the escape character to get one
> escape character as in any Lisp expression.

Indeed.

>> > It doesn't have this feature (yet).  I guess I could add it, but
>> > el-search not really fits for the task.  You can combine patterns
>> > matching strings in any way.  For example, you could search for
>> > something like
>> >
>> >   (or (and (string REGEXP1) (string REGEXP2) (pred SOME-PRED))
>> >       SOMETHING-DIFFERENT))
>> >
>> > so it's not even always well-defined what is intended to be
>> > highlighted.
>>
>> I’d say: the return value of the last pattern, or everything if “t”.
>> So, with a pattern written this way, it would be the whole thing (or the
>> submatch matched by “SOMETHING-DIFFERENT”), while if written like “(or
>> (and (pred SOME-PRED) (string REGEXP1) (string REGEXP2))
>> SOMETHING-DIFFERENT))” it would *always* match the submatch.  But I’m
>> unaware of pcase implemantation.  It seems to be fairly complex, so it
>> might be complex as well to do something alike.
>
> Yeah, it's not that simple: patterns do not have return values, and side
> effects (like changing match data) for matching are tricky.

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

Or rather: I wonder if using scoping (maybe it would require dynamical
binding? or maybe rather won’t work without lexical binding) you could
locally (using cl-flet, or macrolet) redefine string-match upon its
former definition, in the appropriated functions so that it returns a
cons of its result and the return value of `match-end'.

>> Normally a package should be usable withut defining any key.
>
> Well, it's usable without keys, but then you have no ... keys ... for
> going to the next match, etc, as you wanted.

That’s why I missed isearch: even if I had no key for isearch-forward,
it just works inside it, because it defines a mode where some normally
scrolling-related keys behaves semantically with respect to it: it would
be really handy if it was based on isearch and therefore compatible with
it.

>> That’s (part of) the whole point of package recommandation not to
>> define keys: users should decide how they access the interface.  And
>> then it’s preferable it’s if convenient of course but I find this
>> pushes a bit too much for binding keys: I’m bad at choices and finding
>> myself a prefix key will let me unsatisfied (and above all: require me
>> to learn them, which I don’t have (yet) the time or will to invest
>> in),
>
> Then I suggest to simply follow the suggestion in the commentary and use
> M-s e as prefix.

As I said, I don’t want to bind keys until I’m used to regularely use a
command: otherwise I’ll have really a hard time remembering the key, and
each time I want to call the command I’ll have to go back to my init.el
file to find for my keybindings, kill the buffer, return the original
one, then call the keybinding: in the end either I only use the command
name and forget the keys, or stop to use the command.  That’s what
happened to me a lot after discovering iy-go-to-char (which still suffer
from its quite nonsensical “iy” name), multiple-cursors, etc.  So
without a solution using semantical, common, potentially
scrolling-related, keys, I’ll keep doing “M-x <up> <return>”.

I will have no problem remembering what follow the prefix, if it’s
semantical enough, but I see no mnemotecnic reason for remembering the
prefix key sequence.

>> and the “shift” thing is specific to qwerty (“%” doesn’t use
>> shift on my keyboard, while others keys do (for instance “shift+%” is
>> “`” here)).
>
> Well, I can only predefine bindings, then you have to use these, or you
> have to make choices...

Yes of course.  It’s normal.  It’s only to note that making assumptions
on others layout is generally a bad idea (so refering to shift is more a
qwerty-local feature, otherwise it just happens all these keys are left
undefined by default)

> Do you use neo or something like that?

What is neo?

> Of course you can define bindings on your own, but there are quite a few
> in different maps needed, so I predefined the commands that can do this
> for the user for convenience.  I thought this would especially help
> people to try the package quickly.

Well it’s surely quicker than redefining everything.  But still requires
to open your init file, check for your keybindings (just in case), and
add this line, then keep in mind the prefix for the time of trying.
That’s well better than not defining anything, I’m just saying that for
an interaction that commonly request repetition, it would have been
better to have something like isearch.

Imho keystrokes are for doing something quicker when you need to do it
often or repetedly: otherwise commands names are what you use for
trying.  “For trying”, personally, I’ll never bother trying to check 2
to 5 times to remember the correct prefix.

>> Why not, by default, be compatible with isearch?  I’m not totally aware
>> yet of the whole implementation of isearch, but it seems like it’ based
>> on a mode: maybe a clean and modular way to do that would to make
>> derived-mode out of it? or find another way of reusing its library:
>> this way it would stay forward-compatible with it, and benefit from
>> further additions and improvements made to it.
>
> When I wrote el-search, I considered compatibility with isearch, but
> there are too many requirements for el-search that where incompatible
> or impossible to do with isearch ([…])  So incompatibility with
> Isearch is intentional, sorry.

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.

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

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.

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

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

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

BTW, I first thought writing the basic features for efficient matching
would be complicated, and the user interface would be easy going.  It
turned out the opposite was true: Implementing the matching routines was
fun, but maintaining the user interface is hard work.  Mainly because
already the specification of the interface is really, much more than I
had expected.  I guess it's similar for isearch.


Michael.

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

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.

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

[Garreau, Alexandre]

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

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

[Michael Heerdegen]

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