bug#52751: 27.1; Go back to editing the from part in query replace

bug#52751: 27.1; Go back to editing the from part in query replace

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

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

I often run into the situation of doing a complicated query replace/regexp, submitting the FROM part and then during editing the TO part I notice an error in FROM. But I cannot go back there to fix it, I can either cancel the replace which deletes the FROM part, because it did not yet go into history, or I can submit some dummy TO value, cancel the replace, restart it and then use history to fix the FROM value.

There should be an easy way to go back to editing FROM without cumbersome workarounds.

Mainstream UIs solve this by having different input fields where I can switch to and edit any input field before submitting. Maybe the FROM -> TO input should be the default with a preinserted -> arrow, so the user can switch back an forth easily between FROM and TO?

[-- Attachment #2: Type: text/html, Size: 860 bytes --]

bug#52751: 27.1; Go back to editing the from part in query replace

[Juri Linkov]

> I often run into the situation of doing a complicated query replace/regexp,
>  submitting the FROM part and then during editing the TO part I notice an
> error in FROM. But I cannot go back there to fix it, I can either cancel
> the replace which deletes the FROM part, because it did not yet go into
> history, or I can submit some dummy TO value, cancel the replace, restart
> it  and then use history to fix the FROM value.
>
> There should be an easy way to go back to editing FROM without cumbersome
> workarounds.
>
> Mainstream UIs solve this by having different input fields where I can
> switch to and edit any input field before submitting. Maybe the FROM -> TO
> input should be the default with a preinserted -> arrow, so the user can
> switch back an forth easily between FROM and TO?

Preinserting an arrow by default would be confusing for users.
But maybe M-n could insert it.

bug#52751: 27.1; Go back to editing the from part in query replace

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

>
> Preinserting an arrow by default would be confusing for users.

I'm thinking of a UI where the user can access both FROM and TO
at the same time while it's clear which is which. E.g. something
like fields:

  Replace ______ with ______

where you can move around the two values freely before submitting.

The current UI is limiting, because it forces you to input
sequentially with no ability to correct the previous value.
It's better to have something resembling dialog window

bug#52751: 27.1; Go back to editing the from part in query replace

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

Sent too quickly, the end was missing:

> It's better to have something resembling dialog window
> input where you can edit all fields any time before
> submitting

bug#52751: 27.1; Go back to editing the from part in query replace

[Richard Stallman]

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

  > Mainstream UIs solve this by having different input fields where I
  > can switch to and edit any input field before submitting. Maybe
  > the FROM -> TO input should be the default with a preinserted ->
  > arrow, so the user can switch back an forth easily between FROM
  > and TO?

That is an interesting idea, but I think it would be a pain unless
there is a convenient, easy way to move between those two parts of the
minibuffer.

Any ideas for how to do that?

One idea that occurs to me is to define two special movement commands
and bind M-{ and M-} to them.  It is unusual for the FROM and TO
strings to contain multiple paragraphs, so the standard bindings of
those two keys won't be much missed.


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

bug#52751: 27.1; Go back to editing the from part in query replace

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

>
> That is an interesting idea, but I think it would be a pain unless
> there is a convenient, easy way to move between those two parts of the
> minibuffer.
>
> Any ideas for how to do that?
>

Usually in UIs TAB is the key to move between fields, Customize in
Emacs also uses TAB for this. It's convenient and easy to reach.

And if one wants to replace a TAB character then there's C-q for that.

bug#52751: 27.1; Go back to editing the from part in query replace

[Juri Linkov]

> Usually in UIs TAB is the key to move between fields, Customize in
> Emacs also uses TAB for this. It's convenient and easy to reach.

Then typing TAB could insert the arrow separator when it doesn't exist yet.
When it exists, then TAB could jump to the second field.  And fields could
be highlighted using the same faces as customization widgets use for fields.

bug#52751: 27.1; Go back to editing the from part in query replace

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

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

>
> Then typing TAB could insert the arrow separator when it doesn't exist yet.
> When it exists, then TAB could jump to the second field. And fields could
> be highlighted using the same faces as customization widgets use for fields.

If you have two input fields which you can edit before submitting then the whole arrow
thing is obsolete, because you don't have a single field where you have to insert
a marker to separate the from/to inputs.

You have two fields which can be edited separately, they expand as necessary to show
their contents in full, you press TAB to switch between them as needed and
you press Enter to submit when ready.

See the attached picture for two mockups: first the initial state and then a state
before submitting when the user filled the inputs.

[-- Attachment #2: Capture - Copy.PNG --]
[-- Type: image/png, Size: 9637 bytes --]

bug#52751: 27.1; Go back to editing the from part in query replace

[Juri Linkov]

> If you have two input fields which you can edit before submitting then the whole arrow
> thing is obsolete, because you don't have a single field where you have to insert
> a marker to separate the from/to inputs.

Unfortunately, there are problems with two fields.

First, each of these fields should act as the minibuffer
where M-p and M-n navigates the history of previous FROM->TO pairs.

Second, typing RET in the first field is ambiguous: it can mean either
that the user want to move to the second field, or that the user want
to replace all matches with an empty string by leaving the second field
empty.  This requires special-casing: RET in the first field to move to
the second field, and RET in the second field to accept both fields.

bug#52751: 27.1; Go back to editing the from part in query replace

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

>
> First, each of these fields should act as the minibuffer
> where M-p and M-n navigates the history of previous FROM->TO pairs.

Yes, history navigation keys should fill the FROM and TO fields
as appropriate. What's the problem here? Of course, they have to
be reimplemented here, if this is what you mean.

Optimally, this two field input thing should be made generic, so
other commands can also use it in the future. So it should be
a reusable input widget, a new kind of interactive input for commands
to use, beside the usual single minibuffer input.

> Second, typing RET in the first field is ambiguous

It is not ambiguous. RET submits, TAB moves between fields.
This is how dialogs work in mainstream UIs, users are used
to this.

So RET in the first field means the user wants to replace
matches with the empty string. In order to add a TO string
the users presses TAB to move to the second field.

bug#52751: 27.1; Go back to editing the from part in query replace

[Juri Linkov]

>> First, each of these fields should act as the minibuffer
>> where M-p and M-n navigates the history of previous FROM->TO pairs.
>
> Yes, history navigation keys should fill the FROM and TO fields
> as appropriate. What's the problem here? Of course, they have to
> be reimplemented here, if this is what you mean.
>
> Optimally, this two field input thing should be made generic, so
> other commands can also use it in the future. So it should be
> a reusable input widget, a new kind of interactive input for commands
> to use, beside the usual single minibuffer input.

This means like there is a generic function 'completing-read-multiple'
that reads multiple fields using "," as a separator, a similar function
could be created to read a list of values from fields in the minibuffer.

bug#52751: 27.1; Go back to editing the from part in query replace

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

>
> This means like there is a generic function 'completing-read-multiple'
> that reads multiple fields using "," as a separator, a similar function
> could be created to read a list of values from fields in the minibuffer.

Yes, something like that.

It's practically a mini dialog where you provide field
labels and it reads fields for you. It may even display
the dialog fields vertically in the minibuffer in
label -  field format like Customize:

Replace __________
with  ____________

But it's not clear for me how generic it should be. After all,
in case of query replace up arrow or M-p should fill the fields
with previous from/to pairs which may be specific to query replace.
Or is it also applicable for other commands which read multiple values that up arrow should fill the fields with previous configs? We'll
know if other commands are identified which read multiple values
in sequence which could be given in any order.

Maybe it should be implemented first for query-replace/regexp and
made more generic if other possible use cases are identified.

bug#52751: 27.1; Go back to editing the from part in query replace

[Richard Stallman]

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

  > If you have two input fields which you can edit before submitting then the whole arrow
  > thing is obsolete, because you don't have a single field where you have to insert
  > a marker to separate the from/to inputs.

"Fields", in Emacs, usually mean parts of a buffer.
A single minibuffer which contains the from and to strings
separated by an arrow can be thought of as "two fields".
We could use TAB to move point from one field to the other.

That might be a good choice.

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

bug#52751: 27.1; Go back to editing the from part in query replace

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

ndame <laszlomail@protonmail.com> writes:

> I often run into the situation of doing a complicated query
> replace/regexp, submitting the FROM part and then during editing the
> TO part I notice an error in FROM. But I cannot go back there to fix
> it, I can either cancel the replace which deletes the FROM part,
> because it did not yet go into history [...]

The FROM value is stored in history even if you abort the query and
replace without completing it:

emacs -Q
M-% foo RET
C-g
M-% M-p (this should recover "foo").

There's room for improvement, though.  If there are complete query
replace items of the form FROM -> TO, then they are placed before the
FROM entries in the history.  Perhaps there should be a mechanism to
recover those FROM entries from history more quickly.

bug#52751: 27.1; Go back to editing the from part in query replace

[Juri Linkov]

> The FROM value is stored in history even if you abort the query and
> replace without completing it:
>
> emacs -Q
> M-% foo RET
> C-g
> M-% M-p (this should recover "foo").
>
> There's room for improvement, though.  If there are complete query
> replace items of the form FROM -> TO, then they are placed before the
> FROM entries in the history.  Perhaps there should be a mechanism to
> recover those FROM entries from history more quickly.

The problem is that when reading the TO field was not interrupted,
then it's much more preferable to show complete replacement pairs
FROM -> TO on M-p, instead of a single FROM value.