improving query-replace and query-replace-regexp

improving query-replace and query-replace-regexp

[Werner LEMBERG]

What do you think of making M-% and C-M-% b behave similar to C-s and
C-u C-s?  This is, typing it a second time continues a previous
query-and-replace action.  This would save a lot of time.


    Werner

Re: improving query-replace and query-replace-regexp

[Stefan Monnier]

> What do you think of making M-% and C-M-% b behave similar to C-s and
> C-u C-s?  This is, typing it a second time continues a previous
> query-and-replace action.  This would save a lot of time.

After a M-%, you should already be able to continue the same query-replace
action with: M-% RET

At least it works here.......[checking whether it's a local hack that
I haven't installed yet].......hmmm...indeed, it's a local hack.
See patch below,


        Stefan


--- orig/lisp/replace.el
+++ mod/lisp/replace.el
@@ -67,17 +67,28 @@
 (defun query-replace-read-args (string regexp-flag &optional noerror)
   (unless noerror
     (barf-if-buffer-read-only))
-  (let (from to)
+  (let ((lastfrom (car (symbol-value query-replace-from-history-variable)))
+	(lastto (car (symbol-value query-replace-to-history-variable)))
+	from to)
     (if query-replace-interactive
 	(setq from (car (if regexp-flag regexp-search-ring search-ring)))
+      (if (equal lastfrom lastto)
+	  ;; Typically, this is because the two histlists are shared.
+	  (setq lastfrom
+		(cadr (symbol-value query-replace-from-history-variable))))
       ;; The save-excursion here is in case the user marks and copies
       ;; a region in order to specify the minibuffer input.
       ;; That should not clobber the region for the query-replace itself.
       (save-excursion
-	(setq from (read-from-minibuffer (format "%s: " string)
+	(setq from (read-from-minibuffer (if (null lastto)
+					     (format "%s: " string)
+					   (format "%s [%s -> %s]: " string
+						   lastfrom lastto))
 					 nil nil nil
 					 query-replace-from-history-variable
 					 nil t)))
+      (if (and lastto (zerop (length from)))
+	  (setq from lastfrom to lastto)
       ;; Warn if user types \n or \t, but don't reject the input.
       (if (string-match "\\\\[nt]" from)
 	  (let ((match (match-string 0 from)))
@@ -86,12 +97,13 @@
 	      (message "Note: `\\n' here doesn't match a newline; to do that, type C-q C-j instead"))
 	     ((string= match "\\t")
 	      (message "Note: `\\t' here doesn't match a tab; to do that, just type TAB")))
-	    (sit-for 2))))
+	      (sit-for 2)))))
 
+    (unless to
     (save-excursion
       (setq to (read-from-minibuffer (format "%s %s with: " string from)
 				     nil nil nil
-				     query-replace-to-history-variable from t)))
+				       query-replace-to-history-variable from t))))
     (list from to current-prefix-arg)))
 
 (defun query-replace (from-string to-string &optional delimited start end)

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Fri, May 28, 2004 at 06:20:35PM +0200, Werner LEMBERG wrote:
> What do you think of making M-% and C-M-% b behave similar to C-s and
> C-u C-s?  This is, typing it a second time continues a previous
> query-and-replace action.  This would save a lot of time.

It's not necessary -- as those commands use normal minibuffer input, you can
just use the normal minibuffer history mechanism (M-p, etc).

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: improving query-replace and query-replace-regexp

[Kai Grossjohann]

Miles Bader <miles@gnu.org> writes:

> On Fri, May 28, 2004 at 06:20:35PM +0200, Werner LEMBERG wrote:
>> What do you think of making M-% and C-M-% b behave similar to C-s and
>> C-u C-s?  This is, typing it a second time continues a previous
>> query-and-replace action.  This would save a lot of time.
>
> It's not necessary -- as those commands use normal minibuffer input, you can
> just use the normal minibuffer history mechanism (M-p, etc).

Well, the "from" and "to" prompts use the same history, so you have
to be quite careful about the number of times you hit M-p.

One idea would be to have them use separate histories.

But I just use C-x ESC ESC to repeat query-replace.

Kai

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Sat, May 29, 2004 at 01:58:33PM +0200, Kai Grossjohann wrote:
> > It's not necessary -- as those commands use normal minibuffer input, you
> > can just use the normal minibuffer history mechanism (M-p, etc).
> 
> Well, the "from" and "to" prompts use the same history, so you have
> to be quite careful about the number of times you hit M-p.
> 
> One idea would be to have them use separate histories.

I think that would be a mistake -- I very often use the history to retrieve
the `other half' of the search-replace pair, as often the replacement is
simply a slight change to the search text.

> But I just use C-x ESC ESC to repeat query-replace.

Me too, if I just want to exactly redo the q-r.

Anyway, I think there are enough convenient tools already at hand.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: improving query-replace and query-replace-regexp

[Werner LEMBERG]

> Well, the "from" and "to" prompts use the same history, so you have
> to be quite careful about the number of times you hit M-p.

Exactly.

> One idea would be to have them use separate histories.

Yes.  Other editors do it that way.

> But I just use C-x ESC ESC to repeat query-replace.

Thanks, I wasn't aware of this command (IMHO there are still too many
key presses since I have to press `RET' afterwards).


     Werner

Re: improving query-replace and query-replace-regexp

[Stefan Daschek]

Werner LEMBERG <wl@gnu.org> writes:

> What do you think of making M-% and C-M-% b behave similar to C-s and
> C-u C-s?  This is, typing it a second time continues a previous
> query-and-replace action.  This would save a lot of time.

I'd love this feature. I know that there are some alternatives like
C-x ESC ESC or using minibuffer history, but they all require far more
keystrokes. Would it have any unexpected negative effects to make M-%
M-% behaving like C-s C-s?

noniq

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

    After a M-%, you should already be able to continue the same query-replace
    action with: M-% RET

That sounds like an acceptable feature.  I don't think an empty
argument to M-% makes any other sense.

Re: improving query-replace and query-replace-regexp

[Werner LEMBERG]

>     After a M-%, you should already be able to continue the same
>     query-replace action with: M-% RET
> 
> That sounds like an acceptable feature.  I don't think an empty
> argument to M-% makes any other sense.

I just wonder why I still have to type `RET'.  A query-replace action
doesn't happen immediately; you still have to press `y', `n', etc.
Thus I suggest, if possible, to omit the `RET'.


    Werner

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Sat, May 29, 2004 at 07:05:50PM +0200, Werner LEMBERG wrote:
> > That sounds like an acceptable feature.  I don't think an empty
> > argument to M-% makes any other sense.
> 
> I just wonder why I still have to type `RET'.  A query-replace action
> doesn't happen immediately; you still have to press `y', `n', etc.
> Thus I suggest, if possible, to omit the `RET'.

Because it (both the user-interface and the implementation) becomes much more
`magic' then -- C-s after a C-s makes sense because normal i-search enters
immediately into a `every character has an immediate but non-standard
effect', but after you type M-%, you just go into a normal minibuffer
prompt; there, hitting RET to get a default makes more sense.

Surely you don't repeat query-replace commands so often that `M-% RET' is
significantly harder to type than `M-% M-%'?

-Miles
-- 
We live, as we dream -- alone....

Re: improving query-replace and query-replace-regexp

[Werner LEMBERG]

> > I just wonder why I still have to type `RET'.  A query-replace
> > action doesn't happen immediately; you still have to press `y',
> > `n', etc.  Thus I suggest, if possible, to omit the `RET'.
> 
> Surely you don't repeat query-replace commands so often that `M-%
> RET' is significantly harder to type than `M-% M-%'?

Aah, a misunderstanding!  I thought that I have to type `M-% M-% RET'.
Of course `M-% RET' is fine.  Actually, `M-% M-%' and `M-% RET' could
do the same...


    Werner

Re: improving query-replace and query-replace-regexp

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     After a M-%, you should already be able to continue the same query-replace
>     action with: M-% RET
>
> That sounds like an acceptable feature.  I don't think an empty
> argument to M-% makes any other sense.

I like the idea to make M-% to repeat the last query-replace more easily,
because C-x ESC ESC is too inconvenient way to do that.

But an empty argument to M-% can't be used to repeat query-replace
because the first argument of query-replace makes sense even when
it is empty.  It can be used to insert a replacement string between
all characters, i.e. to change a string like "abcdef" into ";a;b;c;d;e;f;"
by (query-replace "" ";").  This is an infrequent operation but
still makes sense.

There should be a better solution like already proposed M-% M-% with
the second M-% typed in the minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Sun, May 30, 2004 at 12:15:00AM +0300, Juri Linkov wrote:
> But an empty argument to M-% can't be used to repeat query-replace
> because the first argument of query-replace makes sense even when
> it is empty.  It can be used to insert a replacement string between
> all characters, i.e. to change a string like "abcdef" into ";a;b;c;d;e;f;"
> by (query-replace "" ";").  This is an infrequent operation but
> still makes sense.

I don't think it's frequent enough to matter; the "empty string inserts
between characters" usage is a kludgey hack, not something you expect people
to know about.

> There should be a better solution like already proposed M-% M-% with
> the second M-% typed in the minibuffer.

That's a really kludgey hack too.  Minibuffer input is _not like_ isearch
input...

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

    > But I just use C-x ESC ESC to repeat query-replace.

I use that also, but it is somewhat of a pain, and these commands
are often repeated.  It may be worth adding the RET feature.
Especially since that sequence of input has no other use.

Re: improving query-replace and query-replace-regexp

[Juri Linkov]

Miles Bader <miles@gnu.org> writes:
> On Sun, May 30, 2004 at 12:15:00AM +0300, Juri Linkov wrote:
>> But an empty argument to M-% can't be used to repeat query-replace
>> because the first argument of query-replace makes sense even when
>> it is empty.  It can be used to insert a replacement string between
>> all characters, i.e. to change a string like "abcdef" into ";a;b;c;d;e;f;"
>> by (query-replace "" ";").  This is an infrequent operation but
>> still makes sense.
>
> I don't think it's frequent enough to matter; the "empty string inserts
> between characters" usage is a kludgey hack, not something you expect people
> to know about.

I have no other objections to M-% RET.  I only wanted to note that
an empty argument makes sense, but since it's infrequent, RET is ok.
There are other available methods to insert a string between all characters.

I tried Stefan's implementation and it works fine.  I have only one remark:
if the last history item contains newlines, it may confuse users because
it displays only the closing square bracket at the minibuffer prompt.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: improving query-replace and query-replace-regexp

[Stefan Monnier]

> I tried Stefan's implementation and it works fine.  I have only one remark:
> if the last history item contains newlines, it may confuse users because
> it displays only the closing square bracket at the minibuffer prompt.

Good point.  How about the version below instead?


        Stefan


--- orig/lisp/replace.el
+++ mod/lisp/replace.el
@@ -1,6 +1,6 @@
 ;;; replace.el --- replace commands for Emacs
 
-;; Copyright (C) 1985, 86, 87, 92, 94, 96, 1997, 2000, 2001, 2002
+;; Copyright (C) 1985, 86, 87, 92, 94, 96, 1997, 2000, 2001, 02, 03, 2004
 ;;  Free Software Foundation, Inc.
 
 ;; Maintainer: FSF
@@ -69,17 +69,32 @@
 (defun query-replace-read-args (string regexp-flag &optional noerror)
   (unless noerror
     (barf-if-buffer-read-only))
-  (let (from to)
+  (let ((lastfrom (car (symbol-value query-replace-from-history-variable)))
+	(lastto (car (symbol-value query-replace-to-history-variable)))
+	from to)
     (if query-replace-interactive
 	(setq from (car (if regexp-flag regexp-search-ring search-ring)))
+      (if (equal lastfrom lastto)
+	  ;; Typically, this is because the two histlists are shared.
+	  (setq lastfrom
+		(cadr (symbol-value query-replace-from-history-variable))))
       ;; The save-excursion here is in case the user marks and copies
       ;; a region in order to specify the minibuffer input.
       ;; That should not clobber the region for the query-replace itself.
       (save-excursion
-	(setq from (read-from-minibuffer (format "%s: " string)
+	(setq from (read-from-minibuffer
+		    (if (null lastto)
+			(format "%s: " string)
+		      (format "%s [%s -> %s]: " string
+			      (mapconcat 'isearch-text-char-description
+					 lastfrom "")
+			      (mapconcat 'isearch-text-char-description
+					 lastto "")))
 					 nil nil nil
 					 query-replace-from-history-variable
 					 nil t)))
+      (if (and lastto (zerop (length from)))
+	  (setq from lastfrom to lastto)
       ;; Warn if user types \n or \t, but don't reject the input.
       (if (string-match "\\\\[nt]" from)
 	  (let ((match (match-string 0 from)))
@@ -88,12 +103,13 @@
 	      (message "Note: `\\n' here doesn't match a newline; to do that, type C-q C-j instead"))
 	     ((string= match "\\t")
 	      (message "Note: `\\t' here doesn't match a tab; to do that, just type TAB")))
-	    (sit-for 2))))
+	      (sit-for 2)))))
 
+    (unless to
     (save-excursion
       (setq to (read-from-minibuffer (format "%s %s with: " string from)
 				     nil nil nil
-				     query-replace-to-history-variable from t)))
+				       query-replace-to-history-variable from t))))
     (list from to current-prefix-arg)))
 
 (defun query-replace (from-string to-string &optional delimited start end)
@@ -842,7 +858,6 @@
 	  (let ((matches 0)	;; count of matched lines
 		(lines 1)	;; line count
 		(matchbeg 0)
-		(matchend 0)
 		(origpt nil)
 		(begpt nil)
 		(endpt nil)
@@ -862,8 +877,7 @@
 		  (setq origpt (point))
 		  (when (setq endpt (re-search-forward regexp nil t))
 		    (setq matches (1+ matches)) ;; increment match count
-		    (setq matchbeg (match-beginning 0)
-			  matchend (match-end 0))
+		    (setq matchbeg (match-beginning 0))
 		    (setq begpt (save-excursion
 				  (goto-char matchbeg)
 				  (line-beginning-position)))

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Tue, Jun 01, 2004 at 07:48:23PM -0400, Stefan Monnier wrote:
> > I tried Stefan's implementation and it works fine.  I have only one remark:
> > if the last history item contains newlines, it may confuse users because
> > it displays only the closing square bracket at the minibuffer prompt.
> 
> Good point.  How about the version below instead?

The standard emacs syntax for prompt defaults seems to be "(default ...)"; is
there any reason to use some different syntax here?  [I know, things are not
exactly consistent as it is, but let's not make it worse.]

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: improving query-replace and query-replace-regexp

[Stefan Monnier]

> The standard emacs syntax for prompt defaults seems to be "(default ...)"; is
> there any reason to use some different syntax here?  [I know, things are not
> exactly consistent as it is, but let's not make it worse.]

I've seen both (default foo) and [foo] used and I personally prefer the
second form because it is shorter.  BTW, here is a suggested patch
to deal with this second form in minibuffer-eldef.


        Stefan


--- orig/lisp/minibuf-eldef.el
+++ mod/lisp/minibuf-eldef.el
@@ -1,6 +1,6 @@
 ;;; minibuf-eldef.el --- Only show defaults in prompts when applicable
 ;;
-;; Copyright (C) 2000, 2001 Free Software Foundation, Inc.
+;; Copyright (C) 2000, 01, 2004  Free Software Foundation, Inc.
 ;;
 ;; Author: Miles Bader <miles@gnu.org>
 ;; Keywords: convenience
@@ -36,7 +36,7 @@
 ;;; Code:
 
 (defvar minibuffer-default-in-prompt-regexps
-  '(("\\( (default\\>.*)\\):? \\'" . 1))
+  '(("\\( (default\\>.*)\\):? \\'" . 1) ("\\( \\[.*\\]\\): \\'" . 1))
   "*A list of regexps matching the parts of minibuffer prompts showing defaults.
 When `minibuffer-electric-default-mode' is active, these regexps are
 used to identify the portions of prompts to elide.
@@ -157,5 +157,5 @@
 
 (provide 'minibuf-eldef)
 
-;;; arch-tag: 7e421fae-c275-4729-b0da-7836af377d3d
+;; arch-tag: 7e421fae-c275-4729-b0da-7836af377d3d
 ;;; minibuf-eldef.el ends here

Re: improving query-replace and query-replace-regexp

[Kevin Rodgers]

Miles Bader wrote:
 > On Sun, May 30, 2004 at 12:15:00AM +0300, Juri Linkov wrote:
 >>There should be a better solution like already proposed M-% M-% with
 >>the second M-% typed in the minibuffer.
 >
 > That's a really kludgey hack too.  Minibuffer input is _not like_ isearch
 > input...

Indeed, since I've set enable-recursive-minibuffers I want to be able to
run M-% on the contents of the minibuffer (yanked, or inserted via M-p).

-- 
Kevin Rodgers

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Tue, Jun 01, 2004 at 08:10:59PM -0400, Stefan Monnier wrote:
> > The standard emacs syntax for prompt defaults seems to be "(default
> > ...)"; is there any reason to use some different syntax here?  [I know,
> > things are not exactly consistent as it is, but let's not make it worse.]
> 
> I've seen both (default foo) and [foo] used and I personally prefer the
> second form because it is shorter.

I'm sure you do, but emacs should present a consistent face to its users
unless there's a good reason not to.  It seems pretty clear that the
"(default ...)" form is canonical as that's what the most fundamental emacs
commands use.

Please change it.

Thanks,

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Tue, Jun 01, 2004 at 06:16:18PM -0600, Kevin Rodgers wrote:
> Indeed, since I've set enable-recursive-minibuffers I want to be able to
> run M-% on the contents of the minibuffer (yanked, or inserted via M-p).

Yeah I do that sometimes too, though it's slightly confusing because you
can't see what's happening (I almost always just hit ! immediately).

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: improving query-replace and query-replace-regexp

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I tried Stefan's implementation and it works fine.  I have only one remark:
>> if the last history item contains newlines, it may confuse users because
>> it displays only the closing square bracket at the minibuffer prompt.
>
> Good point.  How about the version below instead?

This version works fine, it displays all control characters explicitly.
I suggest to use the same technique in all other places where
search strings are displayed literally, i.e. in messages like

"Query replacing %s with %s".

And for consistency with the above message the default prompt
could use the word "with" instead of the "->" arrow:

"Query replace [%s with %s]: "

or as Miles suggested:

"Query replace (default %s with %s): "

And your compact default prompt grew so much :-/

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: improving query-replace and query-replace-regexp

[Juri Linkov]

Kevin Rodgers <ihs_4664@yahoo.com> writes:
> Miles Bader wrote:
>  > On Sun, May 30, 2004 at 12:15:00AM +0300, Juri Linkov wrote:
>  >>There should be a better solution like already proposed M-% M-% with
>  >>the second M-% typed in the minibuffer.
>  >
>  > That's a really kludgey hack too.  Minibuffer input is _not like_ isearch
>  > input...
>
> Indeed, since I've set enable-recursive-minibuffers I want to be able to
> run M-% on the contents of the minibuffer (yanked, or inserted via M-p).

As I understand, the proposal for M-% M-% was with the intention
that the second M-% would repeat the last replacement only when typed
in the empty minibuffer.  So you still could use M-% to replace strings
in the minibuffer if the input string is not empty (yanked or inserted).
Anyway, this seems irrelevant now with the M-% RET solution.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: improving query-replace and query-replace-regexp

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> or as Miles suggested:
>
> "Query replace (default %s with %s): "
>
> And your compact default prompt grew so much :-/

This is a case where `minibuffer-electric-default-mode' would really
help...

What do people think of enabling this by default?  Not only does it
reduce minibuffer overflow, but I think it makes the user-interface
more intuitive.

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

minibuffer-eldef (was: improving query-replace and query-replace-regexp)

[Stefan Monnier]

>> "Query replace (default %s with %s): "
>> 
>> And your compact default prompt grew so much :-/

> This is a case where `minibuffer-electric-default-mode' would really
> help...

Actually I already use it, so the space concern for me has to do with being
able to show the whole prompt, not just with being able to show the prompt
plus the user input.

Also I like avoiding words (which are necessarily language-specific).
Must be some Europe-vs-US thing, seeing how the US road signs are full
of text whereas Europeans ones use mostly language-neutral symbols.

> What do people think of enabling this by default?

I'm all for it.  I've turned it on a long while ago and never regretted it.


        Stefan

Re: minibuffer-eldef

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Also I like avoiding words (which are necessarily language-specific).
> Must be some Europe-vs-US thing, seeing how the US road signs are full
> of text whereas Europeans ones use mostly language-neutral symbols.

I actually prefer the " [...]" syntax over "(default ...)" too[*], but I
think it's more important for Emacs to be consistent.  I don't think it
should be just "Whatever the prompt author happened to like."

[*] I suppose I could see an argument that explicitly saying "default"
    helps extreme newbies, though -- at least those that know English.
    :-)

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: minibuffer-eldef

[Stefan Monnier]

> I actually prefer the " [...]" syntax over "(default ...)" too[*], but I
> think it's more important for Emacs to be consistent.

We can be consistent by using [...] everywhere.


        Stefan

Re: minibuffer-eldef

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I actually prefer the " [...]" syntax over "(default ...)" too[*], but I
>> think it's more important for Emacs to be consistent.
>
> We can be consistent by using [...] everywhere.

Sure.  Feel free to make that argument, but:

  (1) Until you've won everybody over, please use the normal default
      syntax (at least when you're changing core functionality; I'd
      prefer _everywhere_, but it's too exhausting to argue about
      cork-puller-mode or whatever).

  (2) Surely it's an after-the-release sort of thing...?

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: minibuffer-eldef

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> I actually prefer the " [...]" syntax over "(default ...)" too[*], but I
> >> think it's more important for Emacs to be consistent.
> >
> > We can be consistent by using [...] everywhere.
> 
> Sure.  Feel free to make that argument, but:
> 
>   (1) Until you've won everybody over,

I am won over.  Next please.

>   please use the normal default syntax (at least when you're
>       changing core functionality; I'd prefer _everywhere_, but it's
>       too exhausting to argue about cork-puller-mode or whatever).
> 
>   (2) Surely it's an after-the-release sort of thing...?

I can't see a change like this breaking things.  So if there was
consensus about it, I'd consider this even fit for a last-minute
change.  Similarly for the names of menu entries and other
non-functional changes (keybindings are a bit different: there we have
the "I found I hated it after trying for a while to get used to it"
effect we should wait for before establishing them).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: minibuffer-eldef

[Miles Bader]

On Wed, Jun 02, 2004 at 09:01:30AM +0200, David Kastrup wrote:
> >   (2) Surely it's an after-the-release sort of thing...?
> 
> I can't see a change like this breaking things.

I agree, but it's not exactly a boundlessly productive thing to be arguing
about either...

-Miles
-- 
Run away!  Run away!

Re: minibuffer-eldef

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > I actually prefer the " [...]" syntax over "(default ...)" too[*], but I
> > think it's more important for Emacs to be consistent.
> 
> We can be consistent by using [...] everywhere.

Couldn't minibuffer-electric-default-mode automatically
change (default X) to [X] ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: minibuffer-eldef

[Werner LEMBERG]

> > I actually prefer the " [...]" syntax over "(default ...)" too[*],
> > but I think it's more important for Emacs to be consistent.
> 
> We can be consistent by using [...] everywhere.

I favor that.


    Werner

Re: minibuffer-eldef

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

storm@cua.dk (Kim F. Storm) writes:
> Couldn't minibuffer-electric-default-mode automatically
> change (default X) to [X] ?

Hmmm, clever!

Try the attached patch, and then eval the following function and do:

   (setq minibuf-eldef-frob-function 'minibuf-eldef-squirk-default)

   (defun minibuf-eldef-squirk-default (overlay state)
     (cond (state
            (unless (overlay-get overlay 'replacement)
              (let ((string 
                     (buffer-substring (overlay-start overlay)
                                       (overlay-end overlay))))
                (setq string 
                      (replace-regexp-in-string " *(default `?\\(.*\\)'?)"
                                                " [\\1]"
                                                string))
                (overlay-put overlay 'replacement string)))
            (overlay-put overlay 'display (overlay-get overlay 'replacement)))
           (t
            (overlay-put overlay 'invisible t)
            (overlay-put overlay 'intangible t)
            (overlay-put overlay 'display nil))))


The only (slight) problem is that it uses a `display' property, which
can be annoying if you want to manually copy the value of the default
or something.  It could probably do something more clever like only
overlaying the bracketting portions of the default or something.

-Miles


Patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: +minibuf-default-frob.patch --]
[-- Type: text/x-patch, Size: 1676 bytes --]

--- orig/lisp/minibuf-eldef.el
+++ mod/lisp/minibuf-eldef.el
@@ -1,6 +1,6 @@
 ;;; minibuf-eldef.el --- Only show defaults in prompts when applicable
 ;;
-;; Copyright (C) 2000, 2001 Free Software Foundation, Inc.
+;; Copyright (C) 2000, 2001, 2004 Free Software Foundation, Inc.
 ;;
 ;; Author: Miles Bader <miles@gnu.org>
 ;; Keywords: convenience
@@ -46,6 +46,8 @@
 matching the default part of the prompt, and who's cdr indicates the
 regexp subexpression that matched.")
 
+(defvar minibuf-eldef-frob-function nil)
+
 \f
 ;;; Internal variables
 
@@ -103,7 +105,11 @@
 	    (minibuffer-contents-no-properties))
       (setq minibuf-eldef-initial-buffer-length (point-max))
       (add-to-list 'minibuf-eldef-frobbed-minibufs (current-buffer))
-      (add-hook 'post-command-hook #'minibuf-eldef-update-minibuffer nil t))))
+      (add-hook 'post-command-hook #'minibuf-eldef-update-minibuffer nil t)
+      (when minibuf-eldef-frob-function
+	(funcall minibuf-eldef-frob-function
+		 minibuf-eldef-overlay
+		 minibuf-eldef-showing-default-in-prompt)))))
 
 ;; post-command-hook to swap prompts when necessary
 (defun minibuf-eldef-update-minibuffer ()
@@ -118,7 +124,11 @@
     ;; swap state
     (setq minibuf-eldef-showing-default-in-prompt
 	  (not minibuf-eldef-showing-default-in-prompt))
-    (cond (minibuf-eldef-showing-default-in-prompt
+    (cond (minibuf-eldef-frob-function
+	   (funcall minibuf-eldef-frob-function
+		    minibuf-eldef-overlay
+		    minibuf-eldef-showing-default-in-prompt))
+	  (minibuf-eldef-showing-default-in-prompt
 	   (overlay-put minibuf-eldef-overlay 'invisible nil)
 	   (overlay-put minibuf-eldef-overlay 'intangible nil))
 	  (t

[-- Attachment #3: Type: text/plain, Size: 80 bytes --]

-- 
.Numeric stability is probably not all that important when you're guessing.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

Could people prepare the NEWS and manual changes along with the code
changes?  We should do that, now, for any user-visible change.

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

    > The standard emacs syntax for prompt defaults seems to be "(default ...)"; is
    > there any reason to use some different syntax here?  [I know, things are not
    > exactly consistent as it is, but let's not make it worse.]

    I've seen both (default foo) and [foo] used and I personally prefer the
    second form because it is shorter.

The standard for Emacs is (default foo).  There may be some
nonstandard functions that use [foo], due to imperfect quality
control, but we should stick to the standard (unless we decide to
change it).

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

    This is a case where `minibuffer-electric-default-mode' would really
    help...

    What do people think of enabling this by default?  Not only does it
    reduce minibuffer overflow, but I think it makes the user-interface
    more intuitive.

Let's several of us try it for a week, then talk about it again.
I am trying it now.

If we do make this change, we will need to rewrite parts of the Emacs
manual.

Re: improving query-replace and query-replace-regexp

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     This is a case where `minibuffer-electric-default-mode' would really
>     help...
> 
>     What do people think of enabling this by default?  Not only does it
>     reduce minibuffer overflow, but I think it makes the user-interface
>     more intuitive.
> 
> Let's several of us try it for a week, then talk about it again.
> I am trying it now.

Ok, just customized it "on" as well.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: minibuffer-eldef

[Richard Stallman]

Let's end the discussion of whether to use (Default ) or [...]  to
indicate Emacs defaults.  I am not going to change it now.  We have
lots of other work that needs doing in order to have a release,
including updating the manuals.  Could people work on that, please?

I have noticed a tendency lately for people to write lots of mail
discussing the precise best way to answer some minor question.
It must be hard to get other work done while having these discussions.

Re: improving query-replace and query-replace-regexp

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     This is a case where `minibuffer-electric-default-mode' would really
>     help...
>
>     What do people think of enabling this by default?  Not only does it
>     reduce minibuffer overflow, but I think it makes the user-interface
>     more intuitive.
>
> Let's several of us try it for a week, then talk about it again.
> I am trying it now.

Thanks Richard (and David).

BTW, the other little minibuffer hack I had proposed enabling by default
was `file-name-shadow-mode' (which indicates what part of a filename
being entered in the minibuffer will be ignored); I think you've been
using this for a while, what do you think?

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: improving query-replace and query-replace-regexp

[Stefan Monnier]

> BTW, the other little minibuffer hack I had proposed enabling by default
> was `file-name-shadow-mode' (which indicates what part of a filename
> being entered in the minibuffer will be ignored); I think you've been
> using this for a while, what do you think?

I think I like it, except when I use url-handler-mode because it
treats file names like http://foo/bar incorrectly.


        Stefan

Re: improving query-replace and query-replace-regexp

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> BTW, the other little minibuffer hack I had proposed enabling by default
>> was `file-name-shadow-mode'
>
> I think I like it, except when I use url-handler-mode because it
> treats file names like http://foo/bar incorrectly.

These seem to work a bit oddly in the context of filename input (when
substitute-in-file-name is used) anyway, e.g., -- they won't be properly
handled unless the user manually erases the filename prefix.

In their current form, they could be handled by file-name-shadow-mode as
a special case, or theoretically handled in a general manner by adding
to file-name-handler-alist, but I wonder if their current behavior is
even desirable... it seems like a grey area.

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: minibuffer-eldef

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Let's end the discussion of whether to use (Default ) or [...]  to
> indicate Emacs defaults.  I am not going to change it now.  We have
> lots of other work that needs doing in order to have a release,
> including updating the manuals.  Could people work on that, please?
> 
> I have noticed a tendency lately for people to write lots of mail
> discussing the precise best way to answer some minor question.  It
> must be hard to get other work done while having these discussions.

Well, considering the suggested default of
minibuffer-electric-default-mode: I have tried it now for a while, and
I don't like it.  It makes parts of the line jump forwards and
backwards.

The right way to do this would be to display the default value right
in the text entry box in a special color.  If delete-selection-mode is
enabled, the natural choice would be to just paste the default value
into the text entry box and have it selected.

Anyway, the gist is the following: I don't like
minibuffer-electric-default-mode in its current incantation, and a
better user interface would cause additional work and experiments.
Let's shift this discussion to after 21.4.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: improving query-replace and query-replace-regexp

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> BTW, the other little minibuffer hack I had proposed enabling by
> default was `file-name-shadow-mode' (which indicates what part of a
> filename being entered in the minibuffer will be ignored); I think
> you've been using this for a while, what do you think?

It has my vote.  I consider it an improvement without relevant
drawbacks.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: minibuffer-eldef

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Well, considering the suggested default of
> minibuffer-electric-default-mode: I have tried it now for a while, and
> I don't like it.  It makes parts of the line jump forwards and
> backwards.
>
> The right way to do this would be to display the default value right
> in the text entry box in a special color.

I think that wouldn't be right.

The `jumping' can be slightly disconcerting at first, but I think most
people would quickly learn to prefer it -- defaults in prompts can often
take up lots of room in the minibuffer, and eliding them when the user
actually starts to type in his input is useful behavior.

The default string is elided by attaching an `invisible' property, so
using `face' instead would be trivial, but I think that would be the
wrong interface.

> If delete-selection-mode is enabled, the natural choice would be to
> just paste the default value into the text entry box and have it
> selected.

No.

That microsoft/apple behavior is clever hack on the way their selection
works, but it's horribly annoying to actually use.  Emacs' behavior is a
lot nicer.

-Miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy it into your sig so it can spread.

Re: minibuffer-eldef

[Stephan Stahl]

Hi.

David Kastrup said:

> If delete-selection-mode is
> enabled, the natural choice would be to just paste the default value
> into the text entry box and have it selected.

That is a nice idea but it seems unnecessary because at most minibuffer
prompts M-n pastes the default value into the text entry box.
-- 
Stephan Stahl

Re: minibuffer-eldef

[David Kastrup]

"Stephan Stahl" <stahl@eos.franken.de> writes:

> David Kastrup said:
> 
> > If delete-selection-mode is
> > enabled, the natural choice would be to just paste the default value
> > into the text entry box and have it selected.
> 
> That is a nice idea but it seems unnecessary because at most minibuffer
> prompts M-n pastes the default value into the text entry box.

"most".  And it is something that a new user will never come across
by chance.  It's not even in the tutorial, and it is not bound to a
key that a user would actually touch naturally.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: minibuffer-eldef

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> David Kastrup <dak@gnu.org> writes:
> > Well, considering the suggested default of
> > minibuffer-electric-default-mode: I have tried it now for a while, and
> > I don't like it.  It makes parts of the line jump forwards and
> > backwards.
> >
> > The right way to do this would be to display the default value right
> > in the text entry box in a special color.
> 
> I think that wouldn't be right.

Of course, it would disappear once you type something on your own.

> The `jumping' can be slightly disconcerting at first, but I think most
> people would quickly learn to prefer it -- defaults in prompts can often
> take up lots of room in the minibuffer, and eliding them when the user
> actually starts to type in his input is useful behavior.

Sure.  But if the text is shown in the text entry box, it does not
take up additional room, it is elided when the user actually starts
to type, and the cursor does not jump.

> The default string is elided by attaching an `invisible' property,
> so using `face' instead would be trivial, but I think that would be
> the wrong interface.

I am talking about moving the default value over to after the colon.
In the text entry box.

> > If delete-selection-mode is enabled, the natural choice would be
> > to just paste the default value into the text entry box and have
> > it selected.
> 
> No.
> 
> That microsoft/apple behavior is clever hack on the way their
> selection works, but it's horribly annoying to actually use.  Emacs'
> behavior is a lot nicer.

That does not change that if people configure delete-selection-mode,
they have expressed an explicit desire to have this "horribly
annoying" behavior.  So when we have an option for enabling it, there
is little point in not making use of it.

I never argued that delete-selection-mode should be the default for
Emacs.  I just said that when it _is_ switched on, it might be
sensible to deal with default values in the usual and somewhat natural
manner people associate with that mode.

But anyhow, this discussion is not relevant for 21.4, I guess.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: minibuffer-eldef

[Stephan Stahl]

Hi.

David Kastrup said:
> "Stephan Stahl" <stahl@eos.franken.de> writes:
>> That is a nice idea but it seems unnecessary because at most minibuffer
>> prompts M-n pastes the default value into the text entry box.
>
> "most".  And it is something that a new user will never come across
> by chance.  It's not even in the tutorial, and it is not bound to a
> key that a user would actually touch naturally.

"most" will get better with every report as to where it does not work
right now.

Right, i myself learned it just recently.. i'm however not sure were i
read about it :). The thing is just that delete-selection-mode seems to
have nothing to do with default values at minibuffer prompts.
Being able to edit the default value is useful for everyone not just
people that use delete-selection-mode. M-n is already there. So maybe M-n
should be in the tutoraial and some words in the elisp manual telling
developers to provide a default value for every minibuffer prompt because
of M-n ?

-- 
Stephan Stahl

Re: minibuffer-eldef

[Stefan Monnier]

> The right way to do this would be to display the default value right
> in the text entry box in a special color.  If delete-selection-mode is
> enabled, the natural choice would be to just paste the default value
> into the text entry box and have it selected.

I agree that it would make sense, especially since it is what many people
using delete-selection-mode are already accustomed to.  But it is less
general, as can be seen in the recent discussion of M-%: the default
displayed in the prompt shows both `from' and `to' strings whereas the
prompt is only asking the user to enter the `from' string.  I think this
"discrepency" doesn't cause the slightest problem when the default is put in
a "(default FOO)" annotation in the prompt, whereas it would be slightly
confusing if it were put in the text field.


        Stefan

Re: minibuffer-eldef

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > The right way to do this would be to display the default value
> > right in the text entry box in a special color.  If
> > delete-selection-mode is enabled, the natural choice would be to
> > just paste the default value into the text entry box and have it
> > selected.
> 
> I agree that it would make sense, especially since it is what many
> people using delete-selection-mode are already accustomed to.  But
> it is less general, as can be seen in the recent discussion of M-%:
> the default displayed in the prompt shows both `from' and `to'
> strings whereas the prompt is only asking the user to enter the
> `from' string.  I think this "discrepency" doesn't cause the
> slightest problem when the default is put in a "(default FOO)"
> annotation in the prompt, whereas it would be slightly confusing if
> it were put in the text field.

So we need to come up with something better.  After 21.4 has been
released.  Enabling minibuffer-electric-default-mode does not appear
as a good solution to me after trying it, and so in my opinion
enabling it in the current form for 21.4 by default does not make
sense: there is little point in subjecting people to the hassle of
getting used to a setting that should get changed again soon.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: improving query-replace and query-replace-regexp

[Kevin Rodgers]

Miles Bader wrote:
 > On Tue, Jun 01, 2004 at 06:16:18PM -0600, Kevin Rodgers wrote:
 >>Indeed, since I've set enable-recursive-minibuffers I want to be able to
 >>run M-% on the contents of the minibuffer (yanked, or inserted via M-p).
 >
 > Yeah I do that sometimes too, though it's slightly confusing because you
 > can't see what's happening (I almost always just hit ! immediately).

Me, too.  WIBNI a second minibuffer window were displayed for the
recursive minibuffer?

-- 
Kevin Rodgers

Re: improving query-replace and query-replace-regexp

[Stefan Monnier]

>> On Tue, Jun 01, 2004 at 06:16:18PM -0600, Kevin Rodgers wrote:
>>> Indeed, since I've set enable-recursive-minibuffers I want to be able to
>>> run M-% on the contents of the minibuffer (yanked, or inserted via M-p).
>> 
>> Yeah I do that sometimes too, though it's slightly confusing because you
>> can't see what's happening (I almost always just hit ! immediately).

> Me, too.  WIBNI a second minibuffer window were displayed for the
> recursive minibuffer?

You just need to tweak replace.el's messages so that they are displayed
differently when working in the minibuffer.  They could use the same trick
used in completion commands:  [Complete but not unique].

I think many places that use message (or minibuffer-message) could
advantageously use a function that calls either message or
minibuffer-message depending on the context.


        Stefan

Re: improving query-replace and query-replace-regexp

[Miles Bader]

On Thu, Jun 03, 2004 at 02:57:57PM -0400, Stefan Monnier wrote:
> You just need to tweak replace.el's messages so that they are displayed
> differently when working in the minibuffer.  They could use the same trick
> used in completion commands:  [Complete but not unique].
> 
> I think many places that use message (or minibuffer-message) could
> advantageously use a function that calls either message or
> minibuffer-message depending on the context.

I long ago (during Gerd's reign) advanced a patch that put messages in a
little appended " [...]" box while you were in the minibuffer.  I thought it
made using the minibuffer _much_ more pleasant in the presence of errors; the
current behavior (were messages _replace_ the minibuffer text you're still
entering, for a short period of time!) is pretty annoying, and I imagine must
be very confusing for newbies.

There were a few glitches with that patch in rare circumstances (mostly to do
with quail input I think), though, and I never got around to making a more
robust version and it sort of ended up in the "complete someday pile" of
patches...

This is something I'd like to revisit, but I guess it's an "after the
release" thing... :-)

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: minibuffer-eldef

[Miles Bader]

On Thu, Jun 03, 2004 at 10:13:44AM +0200, David Kastrup wrote:
> I never argued that delete-selection-mode should be the default for
> Emacs.  I just said that when it _is_ switched on, it might be
> sensible to deal with default values in the usual and somewhat natural
> manner people associate with that mode.

I disagree.  That style of `default' is annoying even on MS systems (which of
course always use the equivalent of `delete-selection-mode').  It's just a
dumb idea.

It might make sense to allow people to _explicitly_ request that style of
default if they use delete-selection-mode, but that's pretty irrelevant to
the question at hand.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: minibuffer-eldef

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> The right way to do this would be to display the default value right
> in the text entry box in a special color.  If delete-selection-mode is
> enabled, the natural choice would be to just paste the default value
> into the text entry box and have it selected.

This may conflict with INITIAL-INPUT argument.

However, if a special option will be added to enable selecting
the default value, then it could co-exist with DEFULT-VALUE in such a
way that if INITIAL-INPUT is specified, it could be selected as the region;
but if INITIAL-INPUT is nil and DEFULT-VALUE is non-nil, only then
DEFULT-VALUE will be inserted into the minibuffer and selected.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

    > BTW, the other little minibuffer hack I had proposed enabling by
    > default was `file-name-shadow-mode' (which indicates what part of a
    > filename being entered in the minibuffer will be ignored); I think
    > you've been using this for a while, what do you think?

    It has my vote.  I consider it an improvement without relevant
    drawbacks.

I have been using this for a while too, and it seems natural.
So we could enable this, if someone writes the text to change the
Emacs manual.

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

    I long ago (during Gerd's reign) advanced a patch that put messages in a
    little appended " [...]" box while you were in the minibuffer.  I thought it
    made using the minibuffer _much_ more pleasant in the presence of errors; the
    current behavior (were messages _replace_ the minibuffer text you're still
    entering, for a short period of time!) is pretty annoying, and I imagine must
    be very confusing for newbies.

I would not mind installing this as an option
so that people could try it out and we could decide
whether it is a good change of default behavior.

Re: improving query-replace and query-replace-regexp

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     > the other little minibuffer hack I had proposed enabling by
>     > default was `file-name-shadow-mode'
>
> I have been using this for a while too, and it seems natural.  So we
> could enable this, if someone writes the text to change the Emacs
> manual.

I'll give it a go.

BTW, how _does_ one enable a mode like this by default?  Currently, when
a user has enabled it via customize, loading user's customizations sets
things up.  If it is enabled by default, in what place should the setup
happen?

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: improving query-replace and query-replace-regexp

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> What do you think of making M-% and C-M-% b behave similar to C-s and
>> C-u C-s?  This is, typing it a second time continues a previous
>> query-and-replace action.  This would save a lot of time.
> [...]
> +	(setq from (read-from-minibuffer (if (null lastto)
> +					     (format "%s: " string)
> +					   (format "%s [%s -> %s]: " string

When I looked more at the arrow in the prompt in the Stefan's patch,
I thought: why not to use that arrow in the input string instead of the
prompt.  This means to use a special user-defined separator to split
one input string into two parts: from-string and to-string.  When
using this, the prompt and a sample input string might look like this:

Query replace (sep=" -> "): x -> y

The separator value in the prompt reminds the user what string is
currently used as the separator in the input string.  Users should
choose such separators which don't appear in the text to replace.

This has several benefits: it's much easier to repeat previous
replacements by moving through the history list with both from-string
and to-string inserted into the minibuffer at a time; it's possible
to change from-string value during entering the value of to-string
in the same input string...

In the following patch a new variable `query-replace-args-separator'
is nil by default which means that the current behavior with two
separate prompts is still preserved.  But if this option is set
to a string, it is used to split the input string.  It the input
string doesn't contain a separator, then the string is considered
as the from-string only, and the second prompt asks for the to-string.
 
Index: lisp/replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.180
diff -u -r1.180 replace.el
--- lisp/replace.el	3 Jul 2004 05:18:38 -0000	1.180
+++ lisp/replace.el	3 Jul 2004 09:31:43 -0000
@@ -70,6 +70,17 @@
   :group 'matching
   :version "21.4")
 
+(defcustom query-replace-args-separator nil
+  "*Non-nil value separates from-string and to-string in one input string.
+This means that after `query-replace-read-args' reads the first
+argument it splits it using the value of this variable and
+assignes the first half of the input string to the from-string
+and the second half to the to-string.  This works provided the
+separator does not appear in the text you want to replace."
+  :type 'regexp
+  :group 'matching
+  :version "21.4")
+
 (defun query-replace-read-args (string regexp-flag &optional noerror)
   (unless noerror
     (barf-if-buffer-read-only))
@@ -82,12 +93,19 @@
       ;; That should not clobber the region for the query-replace itself.
       (save-excursion
         (setq from (read-from-minibuffer
-                    (format "%s: " string)
+                    (if query-replace-args-separator
+                        (format "%s (sep=\"%s\"): "
+                                string query-replace-args-separator)
+                      (format "%s: " string))
                     (if (eq query-replace-interactive 'initial)
                         (car (if regexp-flag regexp-search-ring search-ring)))
                     nil nil
                     query-replace-from-history-variable
                     nil t)))
+      (if (and query-replace-args-separator
+               (string-match query-replace-args-separator from))
+          (setq to   (substring from (match-end 0))
+                from (substring from 0 (match-beginning 0))))
       ;; Warn if user types \n or \t, but don't reject the input.
       (and regexp-flag
 	   (string-match "\\(\\`\\|[^\\]\\)\\(\\\\\\\\\\)*\\(\\\\[nt]\\)" from)
@@ -99,11 +117,12 @@
 	       (message "Note: `\\t' here doesn't match a tab; to do that, just type TAB")))
 	     (sit-for 2))))
 
-    (save-excursion
-      (setq to (read-from-minibuffer
-                (format "%s %s with: " string from)
-                nil nil nil
-                query-replace-to-history-variable from t)))
+    (unless to
+      (save-excursion
+        (setq to (read-from-minibuffer
+                  (format "%s %s with: " string from)
+                  nil nil nil
+                  query-replace-to-history-variable from t))))
     (when (and regexp-flag
 	       (string-match "\\(\\`\\|[^\\]\\)\\(\\\\\\\\\\)*\\\\[,#]" to))
       (let (pos list char)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: improving query-replace and query-replace-regexp

[Richard Stallman]

      When
    using this, the prompt and a sample input string might look like this:

    Query replace (sep=" -> "): x -> y

That is an interesting idea.  It might be a shocking change for users,
but it might be a good improvement.  It would be a useful thing for
some people to try this out for a while.

But I'd like to remind everyone that we should focus now on
the tasks in admin/FOR-RELEASE, so that we can make another release,
not on looking for improvements to make.

Re: improving query-replace and query-replace-regexp

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     When using this, the prompt and a sample input string might look
>     like this:
> 
>     Query replace (sep=" -> "): x -> y
> 
> That is an interesting idea.  It might be a shocking change for
> users, but it might be a good improvement.  It would be a useful
> thing for some people to try this out for a while.
> 
> But I'd like to remind everyone that we should focus now on the
> tasks in admin/FOR-RELEASE, so that we can make another release, not
> on looking for improvements to make.

Quite so.  While working off for-release points, one might come across
functionality that it makes sense to replace if the documentation
effort makes clear that a different solution with limited scope and
work should be implemented rather than the current one documented.[1]

But the " -> " proposal to me, while interesting, seems unrelated to
solving a problem connected with this release.


Footnotes: 

[1] Which happened a lot with the new edition of "The LaTeX companion"
documenting a vast diversity of LaTeX packages: the companion author,
when confronted with package behavior he found too obnoxious to
explain, often instead managed to convince the upstream authors to
change the semantics of their packages into something more worthwhile
to be documented.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum