bugGNU nano - Bugs: bug #66637, [Wish] the Execute menu could...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #66637: [Wish] the Execute menu could preserve what was typed before a tool is invoked

Submitter:  Evgeny Pestov <pestov_ev>
Submitted:  Fri 03 Jan 2025 04:32:48 PM UTC
   
 
Severity:  1 - Wish Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Thu 03 Apr 2025 10:45:24 AM UTC, comment #19: 

The tiny feature was released in nano-8.4.

Benno Schulenberg <bens>
Group administrator
Mon 03 Mar 2025 10:53:00 AM UTC, comment #18: 

Ok, thanks for explaining!

I would assume people don't rely on the history to know what was run, but mostly for command reuse  (similar to what OP was talking about intentionally executing commented-out commands). So from a command reuse, it would make more sense to me to have both the unedited and the edited command available in history. But I have no strong opinion on this.

All good on my side for closing then! Thanks again for asking.

T.

Tasos Papastylianou <tpapastylianou>
Sat 01 Mar 2025 03:56:06 PM UTC, comment #17: 

Storing the unused string in a separate variable was chosen on purpose: only commands that are actually executed are added to history.  (Otherwise, imagine going through history two weeks later: "Huh? Did I run that?")  Also, the user would be unlikely to realize that the unused string is available in history -- because it didn't use to be that way -- and type the string needlessly again.  Putting the string right back after the prompt makes its presence obvious.  It's still rather surprising behavior, but... I hope mostly in a good way.

`Cancel` behaves the way I expect: it exits from the menu without changing anything, also not the remembered string.  If you want the edited string to be remembered, do the same as before: invoke one of the tools.  If `Cancel` behaved as a tool, there would be no way to go back to the remembered string before it was edited, because `Undo` does not work at the prompt.

In other words: the current behavior is as intended.

Benno Schulenberg <bens>
Group administrator
Sat 01 Mar 2025 02:28:26 PM UTC, comment #16: 

Thanks! :)

Tasos-crazy-macros-wise, no not a problem; as you say, I can always amend affected macros to add a 'cut'. Plus, with enact, the need for that kind of crazy hacking has gone away, things are a lot cleaner now, heheh :D

However, implementation wise, my suggestion would have been instead of storing in a special "foretext" buffer and 'restoring' at the prompt, I would have preferred (and probably it would also have been simpler to implement) to simply make the unused string part of the execute menu's command history.

This way, the previously entered string is still accessible (i.e. by pressing 'up' at the execute menu), but you don't get a nasty surprise next time you open the execute menu, if restoring the string was not your intent.

I note from the wording of the original poster's opening comment ("Additionally, the interrupted command does not appear in the command history, forcing me to re-enter it."), that this was the expected behaviour they initially had in mind as well. :)

E.g., here's one quick example I found where the current patch causes problems / unexpected behaviour:

1. Type "this is string A" in the execute menu. Now press the speller shortcut (or similar). This stores "this is string A" in the "foretext".

2. Open the execute menu again, and see the foretext automatically restored. Amend the existing string, from "this is string A" to "this is no longer string A but something else". Before pressing enter, you regret your decision, and press cancel to exit the execute menu.

3. Open the execute menu again. Since the previous action was 'cancel', you would have expected, by order of least surprisal, to either (preferably) find yourself in front of an empty menu, or, to at least see "this is no longer string A but something else" prefilled on the prompt. But what you see instead now is "this is string A".

It's up to you whether you want to treat this as a bug in the patch and "fix" 'cancel' actions explicitly, but my personal opinion is that the best way to handle this would have been to stash unexecuted strings into the command history of the execute menu instead (i.e. pressing 'up' once would restore what was lost).

An example of one of my macros that 'would' get affected by this "unpredictability of cancel" behaviour, is: I have bound to ^T^T a macro which intentionally 'cancels' the execute menu, goes to the writeout menu to copy the name of the current file, and then returns to the execute menu (expecting it empty) to place a pdflatex command for that specific filename. If the second time I entered the execute menu it wasn't empty, it would result in a gibberish pdflatex instruction. But, just mentioning this as an example; obviously the scenario described in this bug is rare and as you say I can always amend the macro to add a 'cut' before placing the intended command anyway.

But, yes, to answer your question, no it doesn't horribly break my macros in any significant way, though I very much appreciate you checking :D
And sorry again for the delay!

Tasos Papastylianou <tpapastylianou>
Sat 01 Mar 2025 12:35:33 PM UTC, comment #15: 

Hello Tasos,

Good to see you're still alive.  :)

The gist of the patch is in the commit message: """When the user types something at the Execute prompt and then invokes one of the six tools or special functions (that don't take any input), stash the typed string and restore it upon the next invocation of the Execute menu.  This way the typed string is not lost when the tool or special function was invoked by accident -- which it likely was, as those tools and functions don't take any input from the prompt."""

What I think might interfere with your macros (strings binds) is that maybe some of your macros cleverly steer into the Execute menu to send some part of the macro that is unwanted at that moment into oblivion.  But now, it won't go away: it will be there again the next time the Execute menu is opened.  But I guess you could adjust for that change by including a {cut} right after {execute} if the answer should be empty.

Benno Schulenberg <bens>
Group administrator
Sat 01 Mar 2025 12:20:25 PM UTC, comment #14: 

edit:  'if' my opinion is still relevant/useful

Tasos Papastylianou <tpapastylianou>
Sat 01 Mar 2025 12:18:53 PM UTC, comment #13: 

Hi Benno,

Thanks for including me, and very sorry for not responding to your original mention (and for completely missing the 'ping' one).

I meant to take a look at your patch, but have been extremely busy at work.

I know you've just committed, but my opinion is still relevant/useful, I can have a look today.

In all honesty though, until I look at the patch, I'm not too clear still what was being discussed here. What's the gist of the patch / change?

Tasos Papastylianou <tpapastylianou>
Sat 01 Mar 2025 11:05:52 AM UTC, comment #12: 

The patch has been pushed to master, commit c1df6dfd.

Benno Schulenberg <bens>
Group administrator
Tue 11 Feb 2025 11:34:34 AM UTC, comment #11: 

Ping, Tasos?

Benno Schulenberg <bens>
Group administrator
Tue 14 Jan 2025 10:07:28 AM UTC, comment #10: 

Hello Tasos.  Would this patch, file #56768, interfere with your set of macros (string binds)?  Or do you maybe see other negative side effects?

Benno Schulenberg <bens>
Group administrator
Mon 13 Jan 2025 10:38:20 AM UTC, comment #9: 

I hadn't thought about what ^C (Cancel) should do.  But thinking about it now, I think it's good that Cancel does not retain what was typed, because I think the average user would be surprised that on the next invocation of ^T (Execute) the typed text would again be there: "What the heck? I cancelled that. Why is it here now?"  So I think it's good that Cancel forgets what was typed at the Execute prompt (if not some other tool stored it earlier).

Also, apart from prefixing a partial command with # and sending it to the shell (to do nothing), the user could also save that partial command with M-6, then cancel with ^C, and then come back with ^T and do ^U to paste back the partial command.

Benno Schulenberg <bens>
Group administrator
Sun 12 Jan 2025 08:01:56 PM UTC, comment #8: 

Abstract
^C doesn't retain command.
M-\ works fine in all cases now.
Other functions works fine.

About ^C
^C doesn't retain command.
Not sure was it intentional or not.
I can clear execute prompt by using ^K (undocumented execute menu feature).
I would find it more convenient if ^C saved the command.
Because I can start typing the command, then pause to look at the contents of the file,
and then finish typing the command.
In case ^C deletes the command, I can do the same by adding # to the beginning of the prompt.
So both variants (^C retains) / (^C deletes) command are ok.

Version
same 7.2, but with second patch

Environment
same

Tests

Functions
1.  add to history after Enter  ok
2.  retain after ^J, ^T  ok
3.  retain after ^V, ^T  ok
4.  retain after ^C, ^T  fail
5.  retain after ^Z, fg, ^T  ok
6.  retain after ^G, ^X  ok
7.  retain after ^F  ok
8.  retain after M-\  ok

Commands with default configs
9.  retain after ^O (no formatter), ^T  ok
10. retain after ^Y (no linter), ^T  ok

Commands with setup configs
11. retain after ^O, formatting, ^T  ok
12. retain after ^Y, linting, ^T  ok
13. retain after ^S, spelling, ^T  ok

Evgeny Pestov <pestov_ev>
Sat 11 Jan 2025 11:34:32 AM UTC, comment #7: 

Second attempt is attached.

(file #56768)

Benno Schulenberg <bens>
Group administrator
Wed 08 Jan 2025 04:24:51 PM UTC, comment #6: 

Hmm.  For me (on 8.3 plus patch), M-\ places a "|" at the ^T prompt, but a second M-\ fails to remove it.  When first typing something at the ^T prompt, then indeed M-\ fails to add a "|" before what was typed.

Will have to think a bout how to fix this.

Benno Schulenberg <bens>
Group administrator
Tue 07 Jan 2025 04:11:54 PM UTC, comment #5: 

Abstract
M-\ is broken. It inserts "|" to the beginning of the prompt in original nano-7.2, but with the patch it doesn't.
Other functions and commands at the Execute menu works fine.

Version
Nano 7.2-1+deb12u1

Applied patches:
0001-linter-use-a-format-string-to-deflect-format-string-.patch
0002-startup-use-a-format-string-to-deflect-format-string.patch
0003-justify-set-x-0-for-the-undo-item-for-when-using-cut.patch
0004-files-run-chmod-and-chown-on-the-descriptor-not-on-t.patch
0005-execute-retain-what-the-user-typed-before-a-tool-was.patch  <-- test subject

Environment
Debian 12
LC_ALL=C
speller: hunspell-en-us
linter: pyflakes3
formatter: python3-flake8-black

Tests

Functions
1.  add to history after Enter  ok
2.  retain after ^J, ^T  ok
3.  retain after ^V, ^T  ok
4.  retain after ^C, ^T  ok
5.  retain after ^Z, fg, ^T  ok
6.  retain after ^G, ^X  ok
7.  retain after ^F  ok
8.  retain after M-\  fail

Commands with default configs
9.  retain after ^O (no formatter), ^T  ok
10. retain after ^Y (no linter), ^T  ok

Commands with setup configs
11. retain after ^O, formatting, ^T  ok
12. retain after ^Y, linting, ^T  ok
13. retain after ^S, spelling, ^T  ok

Evgeny Pestov <pestov_ev>
Sun 05 Jan 2025 11:28:57 AM UTC, comment #4: 

Attached is a tentative implementation.  Please try it out.


(file #56742)

Benno Schulenberg <bens>
Group administrator
Sun 05 Jan 2025 10:22:00 AM UTC, comment #3: 

Blocking the tools (^S, ^Y, ^O) and the special functions (^J, ^V, ^Z) from running when the input field is not empty would be surprising, annyoing, and frustrating, so that is not an option.

But saving the contents of the input field when something was typed before one of the tools or special functions is invoked... that makes some sense.  Because either a) the user did not know what they were doing when they typed something at the prompt, and then it is no problem to restore that upon the next invocation of ^T, or b) they typed the string on purpose for some reason, before invoking a tool, and then it is nice to restore that string at the prompt upon the next ^T.

I will think about this some more.

However, even if I make this and include it into nano, it would probably take many months and even some years for such a new nano to propagate to your remote machines...  So, it will probably be better to alias your ssh to some function that first copies across  a little script, then ssh's across, and then first executes this little script -- which checks whether ~/.nanorc exists, and if not, creates a basic ~/.nanorc with your essential settings.

Benno Schulenberg <bens>
Group administrator
Sat 04 Jan 2025 02:41:26 PM UTC, comment #2: 

Thank you for the explanation. It is helpful.

I use nano via ssh on many devices to edit configs and scripts.
So I sometimes will deal with default configured nano
and may need to re-enter a command after misspressed ^J.

To reduce the impact of misspressed ^J in the execute menu, here are two possible solutions:
1. Save the input field content to a buffer and restore it the next time ^T is used.
2. Block ^J from running if the input field is not empty.

It looks like there are 5 functions in the execute menu which ignores input field content:
1. ^S speller
2. ^Y linter
3. ^J fulljustify
4. ^V cutrestoffile
5. ^Z suspend

These two solutions may be applied to all functions that ignore input content.

What do you think about this approach?

Evgeny Pestov <pestov_ev>
Sat 04 Jan 2025 07:42:47 AM UTC, comment #1: 

Nano allows changing the key bindings.  In the Execute menu you want ^J to behave like Enter -- you can achieve that by putting the following line at the end of your .nanorc file:

bind ^J enter execute

(By the way, by default ^T^J does not justify a paragraph but the whole buffer, as you can see when you look at the help text: ^T^G.)

Benno Schulenberg <bens>
Group administrator
Fri 03 Jan 2025 04:32:48 PM UTC, original submission:  

When entering a command in GNOME Terminal, I can run it by pressing Enter, ^M, or ^J. I have a habit of using ^J to execute commands.

In nano, to execute a command, I press ^T, enter the command in the "Command to execute:" field, and then press Enter or ^M to run it.

However, if I press ^J instead of Enter or ^M, the "Command to execute:" field closes, and the paragraph is justified. Additionally, the interrupted command does not appear in the command history, forcing me to re-enter it.

It would be convenient if ^J would execute command like in other terminals.

Evgeny Pestov <pestov_ev>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tpapastylianou (Posted a comment)
  • -email is unavailable- added by bens
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by pestov_ev (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-04-03 bens Open/ClosedOpen Closed
    2025-03-01 bens StatusReady for test Fixed
    2025-01-14 bens Carbon-Copy- Added tpapastylianou
    2025-01-11 bens Attached File- Added 0001-execute-retain-what-the-user-typed-before-a-tool-was.patch, #56768
        StatusNone Ready for test
    2025-01-08 bens StatusReady for test None
    2025-01-05 bens Attached File- Added 0001-execute-retain-what-the-user-typed-before-a-tool-was.patch, #56742
        StatusNone Ready for test
    2025-01-05 bens StatusWorks for me None
        Assigned toNone bens
        Summary^J interrupts command entering [Wish] the Execute menu could preserve what was typed before a tool is invoked
    2025-01-04 bens Severity3 - Normal 1 - Wish
        StatusNone Works for me

    Back to the top

    Powered by Savane 3.15.
    Corresponding source code