bugGNU nano - Bugs: bug #61702, at a prompt, one cannot copy the...

 
 

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

bug #61702: at a prompt, one cannot copy the answer to the cutbuffer

Submitter:  Tasos Papastylianou <tpapastylianou>
Submitted:  Sun 19 Dec 2021 03:13:03 PM UTC
   
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Thu 10 Feb 2022 09:05:33 AM UTC, comment #8: 

Released in nano-6.1.  Thanks for reporting!

Benno Schulenberg <bens>
Group administrator
Sun 30 Jan 2022 04:47:19 PM UTC, comment #7: 

Fixed in git, commit 3b657a26, by adding the copy-text functionality to the prompts, bound to M-6 by default.

Benno Schulenberg <bens>
Group administrator
Sun 30 Jan 2022 04:30:57 PM UTC, comment #6: 

Well... if ^K at a prompt would behave as you propose, then the following scenario would not work (or at least, not as straightforward): I open a file, come across a string that would be a much better name for the file, I copy it with M-6, do ^O, type ^K to erase the current name, type ^U to paste the new name...  Oops, it pastes the old name back.  :|

(With your proposed functions, instead of typing ^K ^U, one would have to type: <Home> ^U M-K ^K M-K.  Five keystrokes instead of two, and needing to know about M-K.  Sure, the user could do just <Alt+Del> ^U, but <Alt+Del> is a new and awkward keystroke, few users will know it or, when they learned about it, remember it.)

Since ^K at a prompt exists, it has always simply erased the answer, without affecting the cutbuffer.  I want to keep it that way.  To enable the user to copy the current answer at the prompt, I consider it better to add M-6 (just like ^U was added some years ago), even though it lacks the visible feedback that ^K provides.  But... this copying of the answer from the prompt is rather niche, so... I think M-6 will do fine.

Oh, almost forgot: adding a toggle to any prompt is out of the question.  M-X is the one toggle that works at the prompts, it will stay the only exception.

Also, I don't like the 'cutfromcursor' mode -- I don't understand why anyone would want to use it (unless it is what they are used to from another editor): it takes always two ^Ks to cut a single line.  And if ever I want to cut from somewhere in the middle of a line, I hit <Enter> first and then ^K -- easy.  So, I don't want to propagate the use of this mode or this toggle.

Benno Schulenberg <bens>
Group administrator
Fri 28 Jan 2022 01:57:00 PM UTC, comment #5: 


> (By the way, the normal way to supply a patch is with 'diff -ur'.  And it's better to give the patch a fitting name, with the extension .patch or .diff.)


Thanks! I wasn't sure if there's a convention...

Please do play around with the (second) patch a bit before you make a decision. It does feel like the more natural solution to me, since it involves exactly the same keystrokes and thought process as in the main editor, rather than requiring functions to have a different logic when in the answer prompt; perhaps you may feel the same after trying it.

But otherwise, sure, what you are suggesting also sounds reasonable, and I would welcome that functionality! Thanks again for your efforts!

Tasos Papastylianou <tpapastylianou>
Fri 28 Jan 2022 10:41:38 AM UTC, comment #4: 

Owww!  I get notified when a new bug is posted, but don't get any message when someone posts new info to a bug -- not until I am subscribed to the bug (which happens automatically when I comment on it).

So... I've thought about this without seeing your further comments.  And I concluded that I didn't want to change the behavior of ^K at a prompt.  The thing is: in the beginning 'zap' did not exist (it has existed for just three years, since version 3.2), and 'cut' (^K) was used to erase/zap/delete/kill the answer at the prompt.  I didn't find this slight change of meaning of ^K, from cut-and-save in the edit window to cut-and-forget at a prompt, in any way strange or troubling.  In fact, I found it natural: I think I would be annoyed if a ^K at a prompt would destroy what I have in my cutbuffer at that time.

So... instead of changing the existing meaning of 'cut' at a prompt, I would suggest to add the function 'copy' to all prompts (except yesno).  This allows the user to overwrite the cutbuffer with whatever is currently at the prompt (M-6), to erase the current answer without affecting the cutbuffer (^K), and to paste the first line of the cutbuffer into the answer (^U).

Allowing the user to toggle 'cutfromcursor' at a prompt... I don't like it.  I myself never use that option, but I can see that it would be nice to be able to make ^K behave like it does at a shell prompt: erase from cursor to end-of-line.

Hmmm...  Maybe the behavior of ^K at a prompt could be made dependent on the position of the cursor: when the cursor is at the end of the answer (where it in the normal case will be), then ^K erases the whole answer, but when the cursor is somewhere in the middle, ^K erases until end-of-line -- and if the user meant to erase the whole answer, a second ^K will achieve that.  What do you think?

(By the way, the normal way to supply a patch is with 'diff -ur'.  And it's better to give the patch a fitting name, with the extension .patch or .diff.)

Benno Schulenberg <bens>
Group administrator
Mon 10 Jan 2022 04:43:05 PM UTC, comment #3: 

Dear Benno, please disregard the previous comment; my compilation chain was flawed. (rookie mistake).

Please find attached a final patch, which implements 'cut', 'zap', and 'do_toggle(CUT_FROM_CURSOR)' for menu prompts.

The only thing this implementation does 'not' do is show a statusline after a toggle (e.g. "Cut to end enabled/disabled"), as happens in the main editing mode. However, I think in the context of prompts this is probably a good thing anyway, since presumably someone using this toggle in a prompt knows what they're doing, and showing a statusline on top of a prompt is probably more clutter than anything.

Please let me know if you find this acceptable or if I'm missing something obvious in the code!

(file #52634)

Tasos Papastylianou <tpapastylianou>
Sun 09 Jan 2022 01:29:13 PM UTC, comment #2: 

To follow up from the previous comment; if I make the following change in global.c:


1023c1023
<       add_to_funcs(zap_text, MMAIN,
---
>       add_to_funcs(zap_text, MMOST,
1256c1256
<       add_to_sclist(MMAIN, "M-Del", ALT_DELETE, zap_text, 0);
---
>       add_to_sclist(MMOST, "M-Del", ALT_DELETE, zap_text, 0);


then I expected zap to work correctly in prompts when pressing Alt-Delete. But for some reason this is not the case.

However, if I bind a different shortcut to the 'zap' function separately in my nanorc, e.g.:


bind M-! zap all


then pressing M-! in the context of a prompt works as expected.

Is there something I'm missing with regards to the hard-coded Alt-Delete shortcut specifically?

Tasos Papastylianou <tpapastylianou>
Sat 08 Jan 2022 04:39:09 PM UTC, comment #1: 

I'm trying to familiarise myself a bit with the codebase, so that I can contribute a bit more usefully other than just open "I wish nano did X" requests. :)

In that vein, I am uploading a small patch for prompt.c which attempts to partially resolve this ticket.

I think the 'cut' side of things is fine, but I couldn't get the 'zap' equivalent function to work in that context. Any help would be appreciated :)

What this patch solves:
 - 'Cut' in prompts now inserts the 'answer' text into the cutbuffer rather than just delete it. If CUT_FROM_CURSOR is already enabled, then this has the intended effect within the prompt menu too.

What it does not solve:
 - I was unable to get the existing keybinding for 'zap' to work with the equivalent do_statusbar_zap_text function. I toyed a bit with trying to make zap present in more menus within global.c, but nothing I tried helped.
 - the cut-from-cursor toggle doesn't work from within the prompt context. It needs to be set from within the main window before entering the prompt.

In a sense this is enough for me, since I can work around it and achieve everything else I want with macros. But it doesn't feel very integrated unless "cut-from-cursor" and "zap" also work for these menus in the same way.

(file #52629)

Tasos Papastylianou <tpapastylianou>
Sun 19 Dec 2021 03:13:03 PM UTC, original submission:  

One can legally bind the 'cut' function in menus other than main. However, trying to use this does not work as expected (i.e. the cut contents are not stored in the
cutbuffer).

By contrast, the 'paste' function works as intended (i.e. pastes in the prompt).




Example use-case: create a macro to obtain the current filename:
 - Press Ctrl+O to open the writeout dialog
 - Cut the contents of the prompt, in order to obtain the current filename.
 - Cancel to exit the menu

The name of the current buffer is now stored in the cutbuffer.

A more elaborate example is in using this to create a 'reload' macro -- useful
when having the same file open in separate nano instances (e.g. split tmux panes),
and you want to update the right pane to show changes made in the left pane.

E.g. assume you have a file called "myfile". You could create the following macro:
Keystrokes:
1. ^R       # open insert menu
2. myfile   # i.e. type the file name
3. y        # in case the 'already open elsewhere, are you sure' dialogue comes up
4. M-U      # in case the 'already open elsewhere, are you sure' dialogue did NOT come up, and a 'y' was printed instead :p
5. M-<      # switch to the 'old' buffer
6. ^X       # exit without saving

Step 2 requires you to know the name of the file, and then the macro can only be used with that specific file only. If you had a way to 'cut' the name of the file from the writeout menu, you could expand this macro to detect the filename of the current buffer automatically, and reload the file without having to hardcode the name in the macro.

Tasos Papastylianou <tpapastylianou>

 

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

Attached Files
file #52634:  patch added by tpapastylianou (1KiB - application/octet-stream - final patch to differentiate between cutting vs zapping in the statusbar of menu prompts with working cut-from-cursor toggle)
file #52629:  prompt_c_patch added by tpapastylianou (609B - application/octet-stream - Patch to differentiate between cutting vs zapping in the statusbar of menu prompts)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by tpapastylianou (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-10 bens Open/ClosedOpen Closed
    2022-01-30 bens StatusNone Fixed
    2022-01-30 bens Summaryat a prompt, 'cut' does not put anything in the cutbuffer at a prompt, one cannot copy the answer to the cutbuffer
    2022-01-28 bens Severity3 - Normal 2 - Minor
        Assigned toNone bens
        SummaryCut does not work as expected in menu prompts. at a prompt, 'cut' does not put anything in the cutbuffer
    2022-01-10 tpapastylianou Attached File- Added patch, #52634
    2022-01-08 tpapastylianou Attached File- Added prompt_c_patch, #52629

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code