bug#52558: Option for easier typing of regexps

bug#52558: Option for easier typing of regexps

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I use query replace regexp a lot, as I imagine other people do, and I
always found that typing capturing groups and alternation is clumsy,
because they have to be escaped, and they are the ones  needed
most often: \(...\) \|

There could be a user option to make these easier to type by providing
a variable which controls which characters need escaping in
interactive mode, so the user could list those characters for which
the escaping rules are reversed when typing in the regexp replace
prompt.

E.g.  specifying "()|" means the user can do capturing and alternation
without typing backslashes and match the literal characters with escaping.

This is only an interactive helper feature, so it does not affect the
underlying lisp implementation. The input of the interactive prompt is
normalized after submission.

bug#52558: Option for easier typing of regexps

[Phil Sainty]

You can probably implement what you want by overriding
`read-regexp'.  In principle I'd expect anything prompting
for a regexp to be using this.

bug#52558: Option for easier typing of regexps

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I agree that we could sure use some improvement in this area.
But designing a better interface is likely to be tricky.
We might want to change several aspects at once, rather than
making a small incremental change.  I urge people to look for
various ideas for a more convenient interactive way to specify regexps.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#52558: Option for easier typing of regexps

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> You can probably implement what you want by overriding
> `read-regexp'. In principle I'd expect anything prompting
> for a regexp to be using this.

That's what I thought too at first, but turns out it's not
the right way, because then history contains the normalized
regexp, so if the user goes back in history then he doesn't
see the easy version, though the goal is that the user works
with the easy variant.

So read-regexp is not the right place, because the result of
that goes into history. The translation has to be done only
before the regexp is used.

In case of query-replace-regexp it can be done before
perform-replace. Here's a solution with advice:


(defun my-perform-replace (origfun &rest args)
  (apply
   origfun

   (if (fourth args) ;; do conversion only for regexp replace
       (cons (let ((s (car args))
                   (chars '("|" "(" ")"))
                   (placeholder (format "@placeholder%s@"
                                        (int-to-string
                                         (buffer-modified-tick)))))
               (dolist (char chars)
                 (setq s (replace-regexp-in-string
                          placeholder char
                          (replace-regexp-in-string
                           char (concat "\\\\" char)
                           (replace-regexp-in-string
                            (concat "\\\\" char) placeholder
                            s)))))
               s)

             (cdr args))

     args)))

(advice-add 'perform-replace :around 'my-perform-replace)

bug#52558: Option for easier typing of regexps

[Lars Ingebrigtsen]

ndame <laszlomail@protonmail.com> writes:

> I use query replace regexp a lot, as I imagine other people do, and I
> always found that typing capturing groups and alternation is clumsy,
> because they have to be escaped, and they are the ones  needed
> most often: \(...\) \|
>
> There could be a user option to make these easier to type by providing
> a variable which controls which characters need escaping in
> interactive mode, so the user could list those characters for which
> the escaping rules are reversed when typing in the regexp replace
> prompt.

I think it would be really confusing to have a different regexp syntax
when prompting interactively to when you're writing code, so I don't
think this would be a good idea.  Anybody else have a different opinion?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52558: Option for easier typing of regexps

[Phil Sainty]

On 2021-12-20 00:56, Lars Ingebrigtsen wrote:
> I think it would be really confusing to have a different regexp
> syntax when prompting interactively to when you're writing code

I do recall discussions about allowing (via a user option) rx syntax
at regexp prompts, however.  I think *that* could be nice; but if we
were to have an rx option, perhaps additional options could be up
for consideration as well.

Personally I agree with you that multiple string syntax options has
potential to create confusion, but https://github.com/joddie/pcre2el
shows there's some demand for such things.  Perhaps that library
would suffice as a solution for this particular request?


-Phil

bug#52558: Option for easier typing of regexps

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> On 2021-12-20 00:56, Lars Ingebrigtsen wrote:
>
> I agree with you that multiple string syntax options has
> potential to create confusion

Why would it create confusion if it's an option which the
user has to enable explicitly?

Anyway, I'm using the advice posted before and it's much
more convenient in interactive mode than the default,
and it's not hard to remember that it's different in elisp,
because there one has to type two slashes anyway. Or one
can use rx.

That's why I thought a built in option for this could be
useful, but feel free to close the bug report if you don't
agree. I'm satisfied with the advice too.

bug#52558: Option for easier typing of regexps

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think it would be really confusing to have a different regexp syntax
> when prompting interactively to when you're writing code, so I don't
> think this would be a good idea.  Anybody else have a different
> opinion?

I can only say that I hate to enter stringish regexps in general.  So
much that I hacked `read-regexp' and isearch to accept rx forms as
regexps instead.

Michael.

bug#52558: Option for easier typing of regexps

[Phil Sainty]

On 2021-12-20 03:08, ndame wrote:
> Why would it create confusion if it's an option which the
> user has to enable explicitly?

If the user is (a) well aware of the change they've made (not
blindly copying it from somewhere else), and (b) have a good
understanding of regexp syntax and/or the documentation such
that they won't be asking anyone questions about regexps, then
it shouldn't cause them any confusion.

OTOH for someone who (a) doesn't have a strong understanding of
Emacs regexp syntax; (b) is more familiar with other dialects
with fewer backslashes; (c) enables the hypothetical option to
make things seem more familiar but still doesn't entirely know
what they're doing; and (d) asks questions or searches for pre-
existing Q&As to figure out how to construct their regexp...
I think there's ample opportunity for crossed wires on both
sides of any ensuing interactions, and pre-existing information
will likely not match the syntax that they have chosen.

To me it feels like the kind of option which would be more
likely to be preferred by people who are less familiar with
Emacs regexp syntax, in which case the likelihood of confusion
probably increases.

I'm just speculating, though.


-Phil

bug#52558: Option for easier typing of regexps

[Juri Linkov]

> I use query replace regexp a lot, as I imagine other people do, and I
> always found that typing capturing groups and alternation is clumsy,
> because they have to be escaped, and they are the ones  needed
> most often: \(...\) \|
>
> There could be a user option to make these easier to type by providing
> a variable which controls which characters need escaping in
> interactive mode, so the user could list those characters for which
> the escaping rules are reversed when typing in the regexp replace
> prompt.

Such option already exists, and it allows using custom regexp syntax
both for isearch and query-replace:

(setq search-default-mode
      (lambda (s &optional _lax)
	(let ((chars '("|" "(" ")"))
              (placeholder (format "@placeholder%s@"
                                   (int-to-string
                                    (buffer-modified-tick)))))
          (dolist (char chars)
            (setq s (replace-regexp-in-string
                     placeholder char
                     (replace-regexp-in-string
                      char (concat "\\\\" char)
                      (replace-regexp-in-string
                       (concat "\\\\" char) placeholder
                       s)))))
          s)))

The same way more choices could be added easily to this user option,
such as `pcre' or `rx'.

bug#52558: Option for easier typing of regexps

[ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Such option already exists, and it allows using custom regexp syntax
> both for isearch and query-replace:

Interesting, though its help mentions only isearch, so if I start
M-x query-replace-regexp directly, it doesn't seem affected.

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>> Such option already exists, and it allows using custom regexp syntax
>> both for isearch and query-replace:
>
> Interesting, though its help mentions only isearch, so if I start
> M-x query-replace-regexp directly, it doesn't seem affected.

It affects all commands started from isearch: isearch-query-replace,
isearch-occur, isearch-highlight-regexp.

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>>> Such option already exists, and it allows using custom regexp syntax
>>> both for isearch and query-replace:
>>
>> Interesting, though its help mentions only isearch, so if I start
>> M-x query-replace-regexp directly, it doesn't seem affected.
>
> It affects all commands started from isearch: isearch-query-replace,
> isearch-occur, isearch-highlight-regexp.

It occurred to me now that when isearch-mode is disabled,
these commands could call isearch-edit-string to read
a search string, then proceed with their usual flow.

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>> Such option already exists, and it allows using custom regexp syntax
>> both for isearch and query-replace:
>
> Interesting, though its help mentions only isearch, so if I start
> M-x query-replace-regexp directly, it doesn't seem affected.

If you want to use M-x query-replace directly,
then simpler would be add replace-regexp-function
that you can use with:

(setq replace-regexp-function
      (lambda (s &optional _lax)
	(let ((chars '("|" "(" ")"))
              (placeholder (format "@placeholder%s@"
                                   (int-to-string
                                    (buffer-modified-tick)))))
          (dolist (char chars)
            (setq s (replace-regexp-in-string
                     placeholder char
                     (replace-regexp-in-string
                      char (concat "\\\\" char)
                      (replace-regexp-in-string
                       (concat "\\\\" char) placeholder
                       s)))))
          s)))

diff --git a/lisp/replace.el b/lisp/replace.el
index 0e81b15a09..84c2d523d7 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -2621,6 +2621,8 @@ replace-re-search-function
 It is called with three arguments, as if it were
 `re-search-forward'.")
 
+(defvar replace-regexp-function nil)
+
 (defun replace-search (search-string limit regexp-flag delimited-flag
 		       case-fold &optional backward)
   "Search for the next occurrence of SEARCH-STRING to replace."
@@ -2633,7 +2635,8 @@ replace-search
   ;; outside of this function because then another I-search
   ;; used after `recursive-edit' might override them.
   (let* ((isearch-regexp regexp-flag)
-	 (isearch-regexp-function (or delimited-flag
+	 (isearch-regexp-function (or replace-regexp-function
+                                      delimited-flag
 				      (and replace-char-fold
 					   (not regexp-flag)
 					   #'char-fold-to-regexp)))
-- 

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>>> Such option already exists, and it allows using custom regexp syntax
>>> both for isearch and query-replace:
>>
>> Interesting, though its help mentions only isearch, so if I start
>> M-x query-replace-regexp directly, it doesn't seem affected.
>
> If you want to use M-x query-replace directly,
> then simpler would be add replace-regexp-function
> that you can use with:
>
> (setq replace-regexp-function

And additional change is needed for correct highlighting:

diff --git a/lisp/replace.el b/lisp/replace.el
index 0e81b15a09..4302868520 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -2690,7 +2693,8 @@ replace-highlight
   (if query-replace-lazy-highlight
       (let ((isearch-string search-string)
 	    (isearch-regexp regexp-flag)
-	    (isearch-regexp-function (or delimited-flag
+	    (isearch-regexp-function (or replace-regexp-function
+                                         delimited-flag
 					 (and replace-char-fold
 					      (not regexp-flag)
 					      #'char-fold-to-regexp)))

bug#52558: Option for easier typing of regexps

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think it would be really confusing to have a different regexp syntax
  > when prompting interactively to when you're writing code, so I don't
  > think this would be a good idea.

Actually, the two already are different, in precisely the way that you
worry will be confusing.

Regexps in Lisp code are in string constants, so you have to escape
each backslash with a second backslash.  Regexps in the minibuffer
don't do that.  "\\(foo\\|bar\\)" vs `\(foo\|bar\)'.

It IS confusing.  But I don't see a good way to simplify it.

However, if we could invent a way to specify, "Use extended regexp
syntax", where there are no backslashes for many of these constructs,
we could unify the two.  "(foo|bar)" and `(foo|bar)'.

Unfortunately, there are many \-letter constructs which this
change would not simplify.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#52558: Option for easier typing of regexps

[Jim Porter]

On 12/19/2021 3:56 AM, Lars Ingebrigtsen wrote:
> I think it would be really confusing to have a different regexp syntax
> when prompting interactively to when you're writing code, so I don't
> think this would be a good idea.  Anybody else have a different opinion?

I think this depends on how people use Emacs. While there's definitely 
some potential for confusion if you switch between entering Emacs 
regexps interactively or by writing Elisp, there's also potential for 
confusion if you often write regexps for external tools from Emacs. For 
example, if you use one of the "modern" recursive grep-like tools (ack, 
ag, ripgrep, etc), most of them use PCRE syntax (or something close to 
PCRE). It's easy to forget that Isearch uses BRE but your preferred 
rgrep-like tool uses ERE/PCRE.

I've attempted to resolve this issue in the other direction in 
Urgrep[1], which provides a unified way of running all these recursive 
grep-like tools. Specifically, it defaults to accepting BRE syntax and 
then, if the tool only accepts ERE/PCRE, it converts the BRE input into 
ERE/PCRE. That's not perfect either since then you end up in a situation 
where to use PCRE features, you have to enter them in a BRE-like syntax, 
which I find pretty confusing too. (This behavior is customizable in 
Urgrep, so if you like ERE/PCRE, you can set those as the input syntax.)

I'm not sure this makes the decision about what to do any easier though. 
In fact, it probably just muddies the waters further. :)

[1] https://github.com/jimporter/urgrep

bug#52558: Option for easier typing of regexps

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I've attempted to resolve this issue in the other direction in 
  > Urgrep[1], which provides a unified way of running all these recursive 
  > grep-like tools. Specifically, it defaults to accepting BRE syntax and 
  > then, if the tool only accepts ERE/PCRE, it converts the BRE input into 
  > ERE/PCRE. That's not perfect either since then you end up in a situation 
  > where to use PCRE features, you have to enter them in a BRE-like syntax, 
  > which I find pretty confusing too. (This behavior is customizable in 
  > Urgrep, so if you like ERE/PCRE, you can set those as the input syntax.)

I think it would be a big step forward if we could do something along
these lines in Emacs.  The details may be tricky, though.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>>>> Such option already exists, and it allows using custom regexp syntax
>>>> both for isearch and query-replace:
>>>
>>> Interesting, though its help mentions only isearch, so if I start
>>> M-x query-replace-regexp directly, it doesn't seem affected.
>>
>> If you want to use M-x query-replace directly,
>> then simpler would be add replace-regexp-function
>> that you can use with:
>>
>> (setq replace-regexp-function
>
> And additional change is needed for correct highlighting:
>
> @@ -2690,7 +2693,8 @@ replace-highlight
> +	    (isearch-regexp-function (or replace-regexp-function

This is pushed to master, so now it's possible to provide a custom
regexp converter for search and replace using isearch-regexp-function
and replace-regexp-function.

bug#52558: Option for easier typing of regexps

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 28 Dec 2021 21:15:32 +0200
> Cc: 52558@debbugs.gnu.org
> 
> >> (setq replace-regexp-function
> >
> > And additional change is needed for correct highlighting:
> >
> > @@ -2690,7 +2693,8 @@ replace-highlight
> > +	    (isearch-regexp-function (or replace-regexp-function
> 
> This is pushed to master, so now it's possible to provide a custom
> regexp converter for search and replace using isearch-regexp-function
> and replace-regexp-function.

Thanks, but the doc string of the new function is hard to understand:

> +(defvar replace-regexp-function nil
> +  "Function to convert a search string to a regexp to replace.
> +It's bound to `isearch-regexp-function' when searching
> +for a string to replace.")

The first sentence is unclear: what do you mean by "convert a search
string to a regexp to replace"?  What "search string" is being
converted to regexp, and how does "replace" enter this picture?

And this:

  It's bound to `isearch-regexp-function' when searching

seems to be incorrect: it's isearch-regexp-function that's bound to
replace-regexp-function, not the other way around.

Can you clarify the doc string, please?

bug#52558: Option for easier typing of regexps

[Juri Linkov]

> Thanks, but the doc string of the new function is hard to understand:
>
>> +(defvar replace-regexp-function nil
>> +  "Function to convert a search string to a regexp to replace.
>> +It's bound to `isearch-regexp-function' when searching
>> +for a string to replace.")
>
> The first sentence is unclear: what do you mean by "convert a search
> string to a regexp to replace"?  What "search string" is being
> converted to regexp, and how does "replace" enter this picture?

It has a reference to `isearch-regexp-function' that has
a complete explanation to avoid duplication of the docstring.

> And this:
>
>   It's bound to `isearch-regexp-function' when searching
>
> seems to be incorrect: it's isearch-regexp-function that's bound to
> replace-regexp-function, not the other way around.

Maybe this is better:

  `isearch-regexp-function' is bound to it when searching

bug#52558: Option for easier typing of regexps

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: laszlomail@protonmail.com,  52558@debbugs.gnu.org
> Date: Tue, 28 Dec 2021 22:25:56 +0200
> 
> >> +(defvar replace-regexp-function nil
> >> +  "Function to convert a search string to a regexp to replace.
> >> +It's bound to `isearch-regexp-function' when searching
> >> +for a string to replace.")
> >
> > The first sentence is unclear: what do you mean by "convert a search
> > string to a regexp to replace"?  What "search string" is being
> > converted to regexp, and how does "replace" enter this picture?
> 
> It has a reference to `isearch-regexp-function' that has
> a complete explanation to avoid duplication of the docstring.

I don't think this is enough.  First, the first sentence of the above
doc string doesn't have any such reference, so Apropos commands, which
show only the first sentence, will not have that reference.  And
second, the doc string of isearch-regexp-function says nothing about
replacements.

There's no need to repeat the whole story you have in
isearch-regexp-function, just to say enough for the reader to
understand what is this function about and what it is used for.

> >   It's bound to `isearch-regexp-function' when searching
> >
> > seems to be incorrect: it's isearch-regexp-function that's bound to
> > replace-regexp-function, not the other way around.
> 
> Maybe this is better:
> 
>   `isearch-regexp-function' is bound to it when searching

Yes, definitely better.

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>> >> +(defvar replace-regexp-function nil
>> >> +  "Function to convert a search string to a regexp to replace.
>> >> +It's bound to `isearch-regexp-function' when searching
>> >> +for a string to replace.")
>> >
>> > The first sentence is unclear: what do you mean by "convert a search
>> > string to a regexp to replace"?  What "search string" is being
>> > converted to regexp, and how does "replace" enter this picture?
>>
>> It has a reference to `isearch-regexp-function' that has
>> a complete explanation to avoid duplication of the docstring.
>
> I don't think this is enough.  First, the first sentence of the above
> doc string doesn't have any such reference, so Apropos commands, which
> show only the first sentence, will not have that reference.

But "isearch-regexp-function" is too long for the first sentence.

> And second, the doc string of isearch-regexp-function says nothing
> about replacements.

It should say nothing about replacements.  This is explained
in the second sentence:

  `isearch-regexp-function' is bound to it when searching
  for a string to replace.

bug#52558: Option for easier typing of regexps

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: laszlomail@protonmail.com,  52558@debbugs.gnu.org
> Date: Tue, 28 Dec 2021 22:51:09 +0200
> 
> >> >> +(defvar replace-regexp-function nil
> >> >> +  "Function to convert a search string to a regexp to replace.
> >> >> +It's bound to `isearch-regexp-function' when searching
> >> >> +for a string to replace.")
> >> >
> >> > The first sentence is unclear: what do you mean by "convert a search
> >> > string to a regexp to replace"?  What "search string" is being
> >> > converted to regexp, and how does "replace" enter this picture?
> >>
> >> It has a reference to `isearch-regexp-function' that has
> >> a complete explanation to avoid duplication of the docstring.
> >
> > I don't think this is enough.  First, the first sentence of the above
> > doc string doesn't have any such reference, so Apropos commands, which
> > show only the first sentence, will not have that reference.
> 
> But "isearch-regexp-function" is too long for the first sentence.

Yes.  But I didn't mean to include that name in the first sentence, I
meant to say that we should say there something to better explain the
purpose.

> > And second, the doc string of isearch-regexp-function says nothing
> > about replacements.
> 
> It should say nothing about replacements.  This is explained
> in the second sentence:
> 
>   `isearch-regexp-function' is bound to it when searching
>   for a string to replace.

So we have now made a full circle, and came back to what I said
initially: "searching for a string to replace" doesn't explain itself,
because the relevance of this to some search of a string and to some
replacement is not clear.

How about if you try to explain it to me in your own words, without
paying attention to the constraints of a doc string, and I will then
try to propose a more formal wording?

Thanks.

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>> >> >> +(defvar replace-regexp-function nil
>> >> >> +  "Function to convert a search string to a regexp to replace.
>> >> >> +It's bound to `isearch-regexp-function' when searching
>> >> >> +for a string to replace.")
>> >> >
>> >> > The first sentence is unclear: what do you mean by "convert a search
>> >> > string to a regexp to replace"?  What "search string" is being
>> >> > converted to regexp, and how does "replace" enter this picture?
>> >>
>> >> It has a reference to `isearch-regexp-function' that has
>> >> a complete explanation to avoid duplication of the docstring.
>> >
>> > I don't think this is enough.  First, the first sentence of the above
>> > doc string doesn't have any such reference, so Apropos commands, which
>> > show only the first sentence, will not have that reference.
>> 
>> But "isearch-regexp-function" is too long for the first sentence.
>
> Yes.  But I didn't mean to include that name in the first sentence, I
> meant to say that we should say there something to better explain the
> purpose.
>
>> > And second, the doc string of isearch-regexp-function says nothing
>> > about replacements.
>> 
>> It should say nothing about replacements.  This is explained
>> in the second sentence:
>> 
>>   `isearch-regexp-function' is bound to it when searching
>>   for a string to replace.
>
> So we have now made a full circle, and came back to what I said
> initially: "searching for a string to replace" doesn't explain itself,
> because the relevance of this to some search of a string and to some
> replacement is not clear.
>
> How about if you try to explain it to me in your own words, without
> paying attention to the constraints of a doc string, and I will then
> try to propose a more formal wording?

query-replace uses isearch functions to search the next occurrence to replace.
The new variable replace-regexp-function is intended just to set
the value of isearch-regexp-function that is used by isearch functions.
And isearch-regexp-function already has 18 lines of its docstring
that explains all details.  This is why it's important to have a link
to isearch-regexp-function in the docstring of replace-regexp-function.

bug#52558: Option for easier typing of regexps

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: laszlomail@protonmail.com,  52558@debbugs.gnu.org
> Date: Wed, 29 Dec 2021 19:17:51 +0200
> 
> query-replace uses isearch functions to search the next occurrence to replace.
> The new variable replace-regexp-function is intended just to set
> the value of isearch-regexp-function that is used by isearch functions.
> And isearch-regexp-function already has 18 lines of its docstring
> that explains all details.  This is why it's important to have a link
> to isearch-regexp-function in the docstring of replace-regexp-function.

Thanks, I used this to clarify the doc string.

bug#52558: Option for easier typing of regexps

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> If you want to use M-x query-replace directly,
>> then simpler would be add replace-regexp-function
>> that you can use with:
>>
>> (setq replace-regexp-function
>
> And additional change is needed for correct highlighting:
>
> diff --git a/lisp/replace.el b/lisp/replace.el
> index 0e81b15a09..4302868520 100644
> --- a/lisp/replace.el
> +++ b/lisp/replace.el
> @@ -2690,7 +2693,8 @@ replace-highlight
>    (if query-replace-lazy-highlight
>        (let ((isearch-string search-string)
>  	    (isearch-regexp regexp-flag)
> -	    (isearch-regexp-function (or delimited-flag
> +	    (isearch-regexp-function (or replace-regexp-function
> +                                         delimited-flag
>  					 (and replace-char-fold

Re-skimming this thread, I think these extensions make sense, so perhaps
you should just push them?  (With a NEWS item, I guess.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>>> If you want to use M-x query-replace directly,
>>> then simpler would be add replace-regexp-function
>>> that you can use with:
>>>
>>> (setq replace-regexp-function
>>
>> And additional change is needed for correct highlighting:
>>
>> diff --git a/lisp/replace.el b/lisp/replace.el
>> index 0e81b15a09..4302868520 100644
>> --- a/lisp/replace.el
>> +++ b/lisp/replace.el
>> @@ -2690,7 +2693,8 @@ replace-highlight
>>    (if query-replace-lazy-highlight
>>        (let ((isearch-string search-string)
>>  	    (isearch-regexp regexp-flag)
>> -	    (isearch-regexp-function (or delimited-flag
>> +	    (isearch-regexp-function (or replace-regexp-function
>> +                                         delimited-flag
>>  					 (and replace-char-fold
>
> Re-skimming this thread, I think these extensions make sense, so perhaps
> you should just push them?  (With a NEWS item, I guess.)

This patch was pushed, but does it really need a NEWS item?
It was intended as a basis for a new user-facing feature
that could be now implemented and described in NEWS.

bug#52558: Option for easier typing of regexps

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> -	    (isearch-regexp-function (or delimited-flag
>>> +	    (isearch-regexp-function (or replace-regexp-function
>>> +                                         delimited-flag
>>>  					 (and replace-char-fold
>>
>> Re-skimming this thread, I think these extensions make sense, so perhaps
>> you should just push them?  (With a NEWS item, I guess.)
>
> This patch was pushed, but does it really need a NEWS item?
> It was intended as a basis for a new user-facing feature
> that could be now implemented and described in NEWS.

What was the new user-facing feature?  I thought the point of this was
to just allow users to implement their own replace-regexp-function and
have it work more consistently, which your change fixed...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52558: Option for easier typing of regexps

[Juri Linkov]

>>>> -	    (isearch-regexp-function (or delimited-flag
>>>> +	    (isearch-regexp-function (or replace-regexp-function
>>>> +                                         delimited-flag
>>>>  					 (and replace-char-fold
>>>
>>> Re-skimming this thread, I think these extensions make sense, so perhaps
>>> you should just push them?  (With a NEWS item, I guess.)
>>
>> This patch was pushed, but does it really need a NEWS item?
>> It was intended as a basis for a new user-facing feature
>> that could be now implemented and described in NEWS.
>
> What was the new user-facing feature?  I thought the point of this was
> to just allow users to implement their own replace-regexp-function and
> have it work more consistently, which your change fixed...

This means that after adding a NEWS item this feature request can be closed?

bug#52558: Option for easier typing of regexps

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> What was the new user-facing feature?  I thought the point of this was
>> to just allow users to implement their own replace-regexp-function and
>> have it work more consistently, which your change fixed...
>
> This means that after adding a NEWS item this feature request can be closed?

I think so?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52558: Option for easier typing of regexps

[Juri Linkov]

close 52558 29.0.50
stop

>>> What was the new user-facing feature?  I thought the point of this was
>>> to just allow users to implement their own replace-regexp-function and
>>> have it work more consistently, which your change fixed...
>>
>> This means that after adding a NEWS item this feature request can be closed?
>
> I think so?

So now this is mentioned in NEWS and closed.  For further possible uses
of the new variable, a new feature request could be created.