unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#52558: Option for easier typing of regexps
@ 2021-12-16 17:41 ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-17 10:07 ` Phil Sainty
                   ` (3 more replies)
  0 siblings, 4 replies; 32+ messages in thread
From: ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-16 17:41 UTC (permalink / raw)
  To: 52558

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.






^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-16 17:41 bug#52558: Option for easier typing of regexps ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-17 10:07 ` Phil Sainty
  2021-12-18 16:47   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-18  4:41 ` Richard Stallman
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 32+ messages in thread
From: Phil Sainty @ 2021-12-17 10:07 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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.







^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-16 17:41 bug#52558: Option for easier typing of regexps ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-17 10:07 ` Phil Sainty
@ 2021-12-18  4:41 ` Richard Stallman
  2021-12-19 11:56 ` Lars Ingebrigtsen
  2021-12-19 17:01 ` Juri Linkov
  3 siblings, 0 replies; 32+ messages in thread
From: Richard Stallman @ 2021-12-18  4:41 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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







^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-17 10:07 ` Phil Sainty
@ 2021-12-18 16:47   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 32+ messages in thread
From: ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-18 16:47 UTC (permalink / raw)
  To: Phil Sainty; +Cc: 52558



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









^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-16 17:41 bug#52558: Option for easier typing of regexps ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-17 10:07 ` Phil Sainty
  2021-12-18  4:41 ` Richard Stallman
@ 2021-12-19 11:56 ` Lars Ingebrigtsen
  2021-12-19 13:03   ` Phil Sainty
                     ` (3 more replies)
  2021-12-19 17:01 ` Juri Linkov
  3 siblings, 4 replies; 32+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-19 11:56 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 11:56 ` Lars Ingebrigtsen
@ 2021-12-19 13:03   ` Phil Sainty
  2021-12-19 14:08     ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-19 15:10   ` Michael Heerdegen
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 32+ messages in thread
From: Phil Sainty @ 2021-12-19 13:03 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ndame, 52558

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






^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 13:03   ` Phil Sainty
@ 2021-12-19 14:08     ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-19 16:11       ` Phil Sainty
  0 siblings, 1 reply; 32+ messages in thread
From: ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-19 14:08 UTC (permalink / raw)
  To: Phil Sainty; +Cc: Lars Ingebrigtsen, 52558


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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 11:56 ` Lars Ingebrigtsen
  2021-12-19 13:03   ` Phil Sainty
@ 2021-12-19 15:10   ` Michael Heerdegen
  2021-12-20  4:43   ` Richard Stallman
  2021-12-20 19:46   ` Jim Porter
  3 siblings, 0 replies; 32+ messages in thread
From: Michael Heerdegen @ 2021-12-19 15:10 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ndame, 52558

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.





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 14:08     ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-19 16:11       ` Phil Sainty
  0 siblings, 0 replies; 32+ messages in thread
From: Phil Sainty @ 2021-12-19 16:11 UTC (permalink / raw)
  To: ndame; +Cc: Lars Ingebrigtsen, 52558

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






^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-16 17:41 bug#52558: Option for easier typing of regexps ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
                   ` (2 preceding siblings ...)
  2021-12-19 11:56 ` Lars Ingebrigtsen
@ 2021-12-19 17:01 ` Juri Linkov
  2021-12-19 17:39   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  3 siblings, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2021-12-19 17:01 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 17:01 ` Juri Linkov
@ 2021-12-19 17:39   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-19 17:52     ` Juri Linkov
  2021-12-19 18:38     ` Juri Linkov
  0 siblings, 2 replies; 32+ messages in thread
From: ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-19 17:39 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 17:39   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-19 17:52     ` Juri Linkov
  2021-12-19 17:57       ` Juri Linkov
  2021-12-19 18:38     ` Juri Linkov
  1 sibling, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2021-12-19 17:52 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 17:52     ` Juri Linkov
@ 2021-12-19 17:57       ` Juri Linkov
  0 siblings, 0 replies; 32+ messages in thread
From: Juri Linkov @ 2021-12-19 17:57 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 17:39   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-12-19 17:52     ` Juri Linkov
@ 2021-12-19 18:38     ` Juri Linkov
  2021-12-19 18:48       ` Juri Linkov
  1 sibling, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2021-12-19 18:38 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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






^ permalink raw reply related	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 18:38     ` Juri Linkov
@ 2021-12-19 18:48       ` Juri Linkov
  2021-12-28 19:15         ` Juri Linkov
  2022-01-22 14:23         ` Lars Ingebrigtsen
  0 siblings, 2 replies; 32+ messages in thread
From: Juri Linkov @ 2021-12-19 18:48 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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





^ permalink raw reply related	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 11:56 ` Lars Ingebrigtsen
  2021-12-19 13:03   ` Phil Sainty
  2021-12-19 15:10   ` Michael Heerdegen
@ 2021-12-20  4:43   ` Richard Stallman
  2021-12-20 19:46   ` Jim Porter
  3 siblings, 0 replies; 32+ messages in thread
From: Richard Stallman @ 2021-12-20  4:43 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: laszlomail, 52558

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







^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 11:56 ` Lars Ingebrigtsen
                     ` (2 preceding siblings ...)
  2021-12-20  4:43   ` Richard Stallman
@ 2021-12-20 19:46   ` Jim Porter
  2021-12-22  4:16     ` Richard Stallman
  3 siblings, 1 reply; 32+ messages in thread
From: Jim Porter @ 2021-12-20 19:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen, ndame; +Cc: 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-20 19:46   ` Jim Porter
@ 2021-12-22  4:16     ` Richard Stallman
  0 siblings, 0 replies; 32+ messages in thread
From: Richard Stallman @ 2021-12-22  4:16 UTC (permalink / raw)
  To: Jim Porter; +Cc: laszlomail, larsi, 52558

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







^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 18:48       ` Juri Linkov
@ 2021-12-28 19:15         ` Juri Linkov
  2021-12-28 20:21           ` Eli Zaretskii
  2022-01-22 14:23         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2021-12-28 19:15 UTC (permalink / raw)
  To: ndame; +Cc: 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-28 19:15         ` Juri Linkov
@ 2021-12-28 20:21           ` Eli Zaretskii
  2021-12-28 20:25             ` Juri Linkov
  0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2021-12-28 20:21 UTC (permalink / raw)
  To: Juri Linkov; +Cc: laszlomail, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-28 20:21           ` Eli Zaretskii
@ 2021-12-28 20:25             ` Juri Linkov
  2021-12-28 20:35               ` Eli Zaretskii
  0 siblings, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2021-12-28 20:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: laszlomail, 52558

> 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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-28 20:25             ` Juri Linkov
@ 2021-12-28 20:35               ` Eli Zaretskii
  2021-12-28 20:51                 ` Juri Linkov
  0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2021-12-28 20:35 UTC (permalink / raw)
  To: Juri Linkov; +Cc: laszlomail, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-28 20:35               ` Eli Zaretskii
@ 2021-12-28 20:51                 ` Juri Linkov
  2021-12-29 12:32                   ` Eli Zaretskii
  0 siblings, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2021-12-28 20:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: laszlomail, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-28 20:51                 ` Juri Linkov
@ 2021-12-29 12:32                   ` Eli Zaretskii
  2021-12-29 17:17                     ` Juri Linkov
  0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2021-12-29 12:32 UTC (permalink / raw)
  To: Juri Linkov; +Cc: laszlomail, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-29 12:32                   ` Eli Zaretskii
@ 2021-12-29 17:17                     ` Juri Linkov
  2021-12-29 18:25                       ` Eli Zaretskii
  0 siblings, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2021-12-29 17:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: laszlomail, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-29 17:17                     ` Juri Linkov
@ 2021-12-29 18:25                       ` Eli Zaretskii
  0 siblings, 0 replies; 32+ messages in thread
From: Eli Zaretskii @ 2021-12-29 18:25 UTC (permalink / raw)
  To: Juri Linkov; +Cc: laszlomail, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2021-12-19 18:48       ` Juri Linkov
  2021-12-28 19:15         ` Juri Linkov
@ 2022-01-22 14:23         ` Lars Ingebrigtsen
  2022-01-22 19:01           ` Juri Linkov
  1 sibling, 1 reply; 32+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-22 14:23 UTC (permalink / raw)
  To: Juri Linkov; +Cc: ndame, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2022-01-22 14:23         ` Lars Ingebrigtsen
@ 2022-01-22 19:01           ` Juri Linkov
  2022-01-23 12:36             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2022-01-22 19:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ndame, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2022-01-22 19:01           ` Juri Linkov
@ 2022-01-23 12:36             ` Lars Ingebrigtsen
  2022-01-23 18:09               ` Juri Linkov
  0 siblings, 1 reply; 32+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-23 12:36 UTC (permalink / raw)
  To: Juri Linkov; +Cc: ndame, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2022-01-23 12:36             ` Lars Ingebrigtsen
@ 2022-01-23 18:09               ` Juri Linkov
  2022-01-23 18:29                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 32+ messages in thread
From: Juri Linkov @ 2022-01-23 18:09 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ndame, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2022-01-23 18:09               ` Juri Linkov
@ 2022-01-23 18:29                 ` Lars Ingebrigtsen
  2022-01-24 18:46                   ` Juri Linkov
  0 siblings, 1 reply; 32+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-23 18:29 UTC (permalink / raw)
  To: Juri Linkov; +Cc: ndame, 52558

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





^ permalink raw reply	[flat|nested] 32+ messages in thread

* bug#52558: Option for easier typing of regexps
  2022-01-23 18:29                 ` Lars Ingebrigtsen
@ 2022-01-24 18:46                   ` Juri Linkov
  0 siblings, 0 replies; 32+ messages in thread
From: Juri Linkov @ 2022-01-24 18:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ndame, 52558

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.





^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2022-01-24 18:46 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-16 17:41 bug#52558: Option for easier typing of regexps ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-17 10:07 ` Phil Sainty
2021-12-18 16:47   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-18  4:41 ` Richard Stallman
2021-12-19 11:56 ` Lars Ingebrigtsen
2021-12-19 13:03   ` Phil Sainty
2021-12-19 14:08     ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-19 16:11       ` Phil Sainty
2021-12-19 15:10   ` Michael Heerdegen
2021-12-20  4:43   ` Richard Stallman
2021-12-20 19:46   ` Jim Porter
2021-12-22  4:16     ` Richard Stallman
2021-12-19 17:01 ` Juri Linkov
2021-12-19 17:39   ` ndame via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-19 17:52     ` Juri Linkov
2021-12-19 17:57       ` Juri Linkov
2021-12-19 18:38     ` Juri Linkov
2021-12-19 18:48       ` Juri Linkov
2021-12-28 19:15         ` Juri Linkov
2021-12-28 20:21           ` Eli Zaretskii
2021-12-28 20:25             ` Juri Linkov
2021-12-28 20:35               ` Eli Zaretskii
2021-12-28 20:51                 ` Juri Linkov
2021-12-29 12:32                   ` Eli Zaretskii
2021-12-29 17:17                     ` Juri Linkov
2021-12-29 18:25                       ` Eli Zaretskii
2022-01-22 14:23         ` Lars Ingebrigtsen
2022-01-22 19:01           ` Juri Linkov
2022-01-23 12:36             ` Lars Ingebrigtsen
2022-01-23 18:09               ` Juri Linkov
2022-01-23 18:29                 ` Lars Ingebrigtsen
2022-01-24 18:46                   ` Juri Linkov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).