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.

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

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?

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.