Documentation Clarification about clink HOT 9 CLOSED

I have observed this issue of "typing" characters for a long time [when pasting], and also assumed the issue is with Windows Terminal, not clink. Similar to what you suggested, I have been working around it by changing key-bindings1.

However, I just did some tests, and it appears Terminal does this only when clink is injected. On a vanilla cmd window, it seems to actually paste the text in one go.

Do you know why this is? Is there anything that can be done from Clink's side to "fix" it?

It's all about the ReadConsole() system API.

• Windows Terminal provides its own version of that system API.
• The only way Clink can work is by intercepting that API and providing a replacement. Inside the replacement is where Clink does everything.

Windows Terminal is almost certainly looking at the ENABLE_LINE_INPUT console mode. When that's set, then ReadConsole() reads a whole line at a time, and that would make it possible for Paste to insert text at all once into the edit line. Clink has to disable that console mode in order to be able to provide a replacement line editor, and to be able to support key bindings and do anything at all.

So, no, Clink can't "fix" Windows Terminal's input handling.

from clink.

I just stumbled upon this and was going through the documentation, but I cannot find any "clear" reference or instructions with regards to where I should declare my own DOSKEY macros or aliases.

There isn't a "should" -- declare where/how you want, just as you normally would with CMD.

But there is an optional startup script that you could use, if you don't already have a way that you set up macros/etc. I recommend reading the Getting Started section of the documentation. There is a sub-section about Startup Cmd Script that mentions an optional startup script, but that's not required.

1. Would I just copy the the macros from my previous macrofile into the .inputrc file, is it 1-for-1 syntax compatible?

I recommend reading the documentation on the .inputrc file. It is a specific format and has nothing to do with doskey macros.

2. After installation, I noticed that it somehow loaded some of my previously defined macros. Where is it doing this? I like to understaand deeply the tools that I use so that I can troubleshoot if something is working as intended.

Clink isn't loading them. Clink doesn't change whatever else you had configured, so I recommend to review how you had previously configured the macros to be loaded.

3. I created an .inputrc file in my %HOME% folder per the example in the docs. The dump-functions works but neither of the other two works. Any suggestions or clarification on a misunderstanding woul be appreciated.

"\C-x\C-f": dump-functions
"\C-x\C-m": dump-macros
"\C-x\C-v": dump-variables

You haven't said what terminal program you're using.

• The Ctrl-V key is often intercepted by terminal programs, and you'd need to undefine a Ctrl-V key binding in the terminal program so that the key can reach Clink.
• The Ctrl-M key is sometimes intercepted by terminal programs, and you might need to undefine a Ctrl-M key binding in the terminal program so that the key can reach Clink.

Also, refer to the Customizing Key Bindings documentation. For example, it has a section about "Discovering Clink key sequences", and that can help you identify which keys are reaching Clink.

from clink.

Hi @chrisant996, thanks for the quick reply. Your comments helped guide me in the right direction. I understand you've put a lot of time into the docs however, as a newcomer and someone not entirely verse all things terminal/shell related it's a bit much to digest at first blush and feels more like a wall of text.

That aside, I had some follow-up questions/comments:

FYI - I'm using command prompt in Windows Terminal.

#​1. Cleared up, thanks.
#​2. I originally had my own startup.cmd file configured in the registry AutoRun key but during the installation wizard (pictured below) the description text states that it would configure the AutoRun regkey.

So, I assumed it would just overwrite whatever I had prior, what I missed though was that the wizard only configured the AutoRun regkey at "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" registry key whereas I had set it at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor".

I did want to ask though, is that intentional in only setting the regkey under HKCU and not HKLM, if so, I'm just curious as to the rationale.

#​3. I read some more of the docs from the link you provided and used clink echo to debug the keybinding. From that, I got the following result for Ctrl-M "\e[27;5;77~", which according to your docs has to do with terminal.differentiate_keys being enabled. However, when I ran clink set, the terminal.differentiate_keys variable/setting was set to False. Do you have any suggestions/idea as to why I'm getting that result?

#​4. (New) Does the dump-macros function only show macros and custom keybindings added via the .inputrc file, or is referring to macros loaded via the clink_start.cmd (if it was created/configured)? I see in the docs states it as

Print all of the Readline key sequences bound to macros and the strings they output. If a numeric argument is supplied, the output is formatted in such a way that it can be made part of an inputrc file. This command is unbound by default.

If the command is unbound by default, how would you go about binding it, and to what?
Again, this comes back to not being verse in all things terminals/shells and was hoping for something slightly more straightforward or in layman's terms.

from clink.

#​4. (New) Does the dump-macros function only show macros and custom keybindings added via the .inputrc file [...]

dump-macros will only dump readline macros defined in your .inputrc. This has nothing to do with doskey macros or whatever cmd.exe specific data ingestion you might think of. See:

\e\C-l outputs --help\C-e | less -X
\eC outputs curl --location --remote-name \C-e
\er outputs history | rg \C-e

If you need a parabole, think of clink as basically being what bash is regarding to your average Linux-distro shell with history and whatnot. But it's not a shell. It just hooks a GNU readline lib onto any or all cmd.exe process.

(Hope to not interfere in the issue tracker, but since I'm mostly a Windows user and a clink user since 2015, I offer my feedback).

from clink.

as a newcomer and someone not entirely verse all things terminal/shell related it's a bit much to digest at first blush and feels more like a wall of text.

Yes, there's a lot. Some users want lots of information immediately, some want only the basics first, others want information in very different specific orders from each other. No one wants to read a bunch of definitions first. And so it's very hard to produce a linear document, since so many things are connected and need to reference each other.

FYI - I'm using command prompt in Windows Terminal.

Got it, thanks. You need to undefine Ctrl-V in Windows Terminal (or redefine Paste to a different key binding in Windows Terminal), if you want Clink to be able to receive Ctrl-V. Windows Terminal gets first crack at all input. Clink only receives input that Windows Terminal doesn't handle itself.

Clink has a default binding for Ctrl-V that pastes from the Windows clipboard, which is essentially what Windows Terminal's default Ctrl-V binding does. But Windows Terminal's Ctrl-V handler inserts characters one at a time from the Windows clipboard, as if you typed them one at a time, so that it can simulate pasting into all applications, without the application needing to know about pasting. Clink's Ctrl-V handler inserts all the text at once, because it knows about pasting and can be more smart and efficient.

If you undefine Ctrl-V in Windows Terminal, then any console apps you run that don't know about pasting won't be able to handle pasting. So, you might want to redefine Windows Terminal's Paste command to a different key binding, maybe Ctrl-Shift-V, according to your preferences.

#​2. I originally had my own startup.cmd file configured in the registry AutoRun key but during the installation wizard (pictured below) the description text states that it would configure the AutoRun regkey.

... So, I assumed it would just overwrite whatever I had prior.

Installing an app should not be a destructive operation that ruins other things. Clink does not replace/remove other configuration, instead it adds to it.

what I missed though was that the wizard only configured the AutoRun regkey at "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" registry key whereas I had set it at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor".

I did want to ask though, is that intentional in only setting the regkey under HKCU and not HKLM, if so, I'm just curious as to the rationale.

Yes. Applications generally should be very careful about which things they write into HKLM. That affects all users on the computer, even to background operations running as the OS's internal "Local System" account for system services and processes.

A computer can be shared by many users. When one user installs an app for their own use, that shouldn't necessarily install it for all users. And it definitely shouldn't automatically configure every user account and force everyone to use the same configuration as the one user who installed the software.

#​3. I read some more of the docs from the link you provided and used clink echo to debug the keybinding. From that, I got the following result for Ctrl-M "\e[27;5;77~", which according to your docs has to do with terminal.differentiate_keys being enabled. However, when I ran clink set, the terminal.differentiate_keys variable/setting was set to False. Do you have any suggestions/idea as to why I'm getting that result?

You installed with "Use enhanced defaults". That means it emulates the shortcuts that Windows provides in the default console host. Ctrl-M has for many years been the Mark command to mark text in the terminal for copy/paste. But terminal emulators normally don't differentiate between Ctrl-M and Enter -- this is how terminals have always worked, for many decades. In order for Enter and Ctrl-M to do different things, Clink's input driver has to produce different codes for them.

#​4. (New) Does the dump-macros function only show macros and custom keybindings added via the .inputrc file, or is referring to macros loaded via the clink_start.cmd (if it was created/configured)?

It's for Readline macros, defined in the .inputrc file.

Readline macros and Doskey macros are completely separate and unrelated (as are Word macros, Excel macros, and other macros). Doskey is part of Windows, and Clink doesn't try to document pre-existing parts of Windows. Run doskey /macros to list the installed doskey macros. See doskey /? for help.

Print all of the Readline key sequences bound to macros and the strings they output. If a numeric argument is supplied, the output is formatted in such a way that it can be made part of an inputrc file. This command is unbound by default.

If the command is unbound by default, how would you go about binding it, and to what? Again, this comes back to not being verse in all things terminals/shells and was hoping for something slightly more straightforward or in layman's terms.

Refer to Customizing Key Bindings.

You can bind whatever commands you want, to whatever keys you want.

from clink.

@chrisant996 Thank you for taking the time to respond to my questions and also providing some of the historical context behind the decisions made, I genuinely appreciate it.

Given your responses and clarifications, I definitely have a better understanding now and look forward to getting more acquainted with clink.

from clink.

@garoto, I understood most of what you stated but I wasn't clear on the example you provided, or more specifically I wasn't clear on how to interpret key sequences or the overall command.

For instance:
\e\C-l outputs --help\C-e | less -X
Should I read \e\C-l as Esc + Crtl-l? and what does it mean by saying it outputs --help\C-e | less -X

from clink.

which is essentially what Windows Terminal's default Ctrl-V binding does. But Windows Terminal's Ctrl-V handler inserts characters one at a time from the Windows clipboard, as if you typed them one at a time, so that it can simulate pasting into all applications, without the application needing to know about pasting. Clink's Ctrl-V handler inserts all the text at once, because it knows about pasting and can be more smart and efficient.

If you undefine Ctrl-V in Windows Terminal, then any console apps you run that don't know about pasting won't be able to handle pasting. So, you might want to redefine Windows Terminal's Paste command to a different key binding, maybe Ctrl-Shift-V, according to your preferences.

I have observed this issue of "typing" characters for a long time, and also assumed the issue is with Windows Terminal, not clink. Similar to what you suggested, I have been working around it by changing key-bindings¹.

However, I just did some tests, and it appears Terminal does this only when clink is injected. On a vanilla cmd window, it seems to actually paste the text in one go.

Do you know why this is? Is there anything that can be done from Clink's side to "fix" it?

I didn't open a new issue since I'm not sure whether I am just misunderstanding something. Let me know if I should.

from clink.

Update: Clink v1.5.2 was published (see Releases) and solves the issue where pasting in Windows Terminal or ConEmu moves slowly enough that you can watch the pasted text "flow" into the input line.

from clink.