In Terminal "command prompt", it seems there's no shortcut to select current command's text? Ctrl-a not working

[carehart]

Is there a reason ctrl-a doesn't allow selecting all the text of the current command line input, such as to then copy it to the clipboard? For now, using ctrl-a does nothing but append ^A to the end of that input. I'm referring here to the Terminal "command prompt" view.

Note that in the Powershell view, or the traditional Windows command prompt (conhost), ctrl-a does this task, so some of us have it trained into our fingers. :-) Since it seems that key combination is unused (in the "command prompt' view), has it been considered for this task?

Yes of course there is the shortcut to "select all", ctrl+shift+a, but that selects the entire terminal (input and output). I'm asking about just the command input. (For any who don't understand what I mean here, simply type a command to run it, then hit up-arrow to retrieve it. I'm asking how to select that command--or any other past one, without using the mouse, such as to copy it to the clipboard.)

And to be clear, I find no feature in the "command palette" to do this ("select all" for the displayed command, only). So for now one must use their mouse to select such a command, which is why I seek a shortcut alternative.

Again, ctrl-a works this way in the Terminal powershell view and the traditional command prompt, and it's not being used in the Terminal Command prompt. Could it be? Or am I missing something? (And I looked, but I didn't see any open issues that seemed related.)

[lhecker]

Hey! With the switch to VT sequences for communication, the Terminal is now more reliant on the shell (cmd/powershell/...) to provide such input line handling, which is why it works in PowerShell. I believe your issue is a duplicate of #10645. I'm personally not entirely sure if duplicating it with #715 was a 100% fit, but mark mode (Ctrl+Shift+M by default - it can be changed) does at least partially do the trick, even if it doesn't do Ctrl+A the way it used to. Ctrl+Shift+Left/Right does work as expected.

[carehart]

Thanks, @lhecker. #10645 is indeed asking the same thing. Sorry I missed that. As for #715, well, that seems to go bit far afield of this one matter.

Also, you propose that "Ctrl+Shift+Left/Right does work as expected." If you mean in Terminal compared to conhost, I'd say that's not so: in conhost, that WOULD select the text (word by word) in the command line (which would be better than nothing), but instead in the Terminal command prompt it ONLY moves the cursor word by word (the shift is not doing anything, though indeed it could and should).

Finally, you open saying that "the Terminal is now more reliant on the shell (cmd/powershell/...) to provide such input line handling, which is why it works in PowerShell", and that would indeed BE encouraging...if only it were so, in this respect of Terminal getting from cmd/conhost this handling of ctrl-a or ctrl-shift-left/right. :-)

I suspect you know or perceive something more (perhaps from #715) that leads you to think there's a clue to follow for perhaps solving this. I'll leave that in the hands of those interested in the topic, and especially familiar with all the inner workings. I am not at all, but am just a user. Indeed, I keep trying to use terminal as the default but I keep running into little things like this that push me back to not using it.

But I am indeed trying to "make the world a better place" by sharing the observations here. I appreciate that in most open source projects there are a lot of folks like me and few folks like you--and we dearly appreciate you guys doing the heavy lifting! :-)

[zadjii-msft]

FWIW the Ctrl+A handling in PowerShell is done by PsReadline (a powershell module), not the terminal / console itself. The "selection" created by Ctrl+A in pwsh is entirely something that pwsh itself is maintaining, not something more fundamental.

Command Prompt doesn't use psreadline (obviously). It relies on the "cooked read" functionality of the console APIs themselves. Theoretically, if we did want to fix this for cmd.exe, the place to do so would be in the cooked read handler in the console. That would add this for both cmd.exe and any other console apps that use cooked reads for input (e.g. the python REPL).

That of course, would also be a "selection" that the Terminal couldn't know about - that would all be internal to the console itself. That "selection" would be entirely independent of the end terminal, so thinks like mark mode wouldn't operate on that selection, which would be wEiRd.

Alas, we actually can't really make changes like that to cmd.exe.

Maybe there's some way we could:

• have terminal request "CookedReadV2" from the console, so that Terminal itself could opt in to new commandline handling, while conhost remains opted out
• have conpty transmit "selection" state to the end terminal (and vice versa)

</notes from trying to fall asleep>

---

I think probably the better solution here is something built on top of shell integration.

[zadjii-msft]

FWIW the Ctrl+A handling in PowerShell is done by PsReadline (a powershell module), not the terminal / console itself. The "selection" created by Ctrl+A in pwsh is entirely something that pwsh itself is maintaining, not something more fundamental.

Command Prompt doesn't use psreadline (obviously). It relies on the "cooked read" functionality of the console APIs themselves. Theoretically, if we did want to fix this for cmd.exe, the place to do so would be in the cooked read handler in the console. That would add this for both cmd.exe and any other console apps that use cooked reads for input (e.g. the python REPL).

That of course, would also be a "selection" that the Terminal couldn't know about - that would all be internal to the console itself. That "selection" would be entirely independent of the end terminal, so thinks like mark mode wouldn't operate on that selection, which would be wEiRd.

Alas, we actually can't really make changes like that to cmd.exe.

Maybe there's some way we could:

• have terminal request "CookedReadV2" from the console, so that Terminal itself could opt in to new commandline handling, while conhost remains opted out
• have conpty transmit "selection" state to the end terminal (and vice versa)

</notes from trying to fall asleep>

---

I think probably the better solution here is something built on top of shell integration.

[DHowett]

the place to do so would be in the cooked read handler in the console.

I do believe that our architectural "purity" is holding us back a little bit here.

Why doesn't ConPTY's input state machine produce conhost input¹? If it did, we would get all of the cooked read line editing stuff for free. Sure, selection would turn out strange but like... it already does in PowerShell.

ConPTY is 50% an interface to a console application and 50% an interface to conhost². Why have we decided that ^A goes through to the application but F7 gets caught up by COOKED_READ? It's roughly the same thing!

Footnotes

1. right now it produces input to be formatted for the input stream ↩

2. F7 ↩

[carlos-zamora]

Tagged up, but leaving "Needs-Triage" on it so we can further discuss as a team.

[zadjii-msft]

tldr:

ctrl+a over conpty to a client doing a cooked read should do the same thing as conhost. Great.

[carehart]

@zadjii-msft , is your tldr there simply summarizing my original request (and replies since)? Or are you somehow reflecting work that's now been done on the team regarding the request? (The prior comment from @carlos-zamora was that it would indeed be triaged and "discussed as a team", a few weeks ago.) I do see you also removed the "needs triage" tag. If this means perhaps the issue has moved up in priority, great. :-)

I appreciate that may not mean "solved any time soon". Just clarifying that I'm not a regular here, so not familiar with the process that requests go through. Thanks.

[zadjii-msft]

Ah, it's more a reflection on the root cause here. I know it sounds like I just said the same thing as you, but I'm more ID'ing exactly where in the codebase to go fix this. (It's probably one of https://github.com/microsoft/terminal/blob/main/src/terminal/adapter/InteractDispatch.cpp or https://github.com/microsoft/terminal/blob/main/src/terminal/parser/InputStateMachineEngine.cpp).

---

Wait though we were maybe a bit hasty. We may have just yanked triage quick cause it was the last one on the queue at 5pm.

There's still the open question - when the user does press Ctrl+A, and conpty "selects" the entire input - how would we convey that info to a terminal to render that? I don't think there's an existing VT sequence for a client app to communicate "this region is selected".

It might be easy enough to accept the ^A and have conpty internally select the text, but without rendering it back to the terminal, you're in a bit of a magic state.

[carehart]

Ah, OK. Thanks. I'll leave you titans to rumble. :-)

[piecevcake]

Ah, it's more a reflection on the root cause here. I know it sounds like I just said the same thing as you, but I'm more ID'ing exactly where in the codebase to go fix this. (It's probably one of https://github.com/microsoft/terminal/blob/main/src/terminal/adapter/InteractDispatch.cpp or https://github.com/microsoft/terminal/blob/main/src/terminal/parser/InputStateMachineEngine.cpp).

Hey if it's too hard, why not just add an option to copy/log the entire cmd window contents to a file either as they appear or on closing the window. We put people on the moon, you know.

When I pressed Ctrl_A the cmd administrator window closed and I lost the entire record of what I had changed, executing a Take Ownership app.