No, the keys inside popup windows aren't configurable.

@chrisant996 Is there any chance that this will be possible in the future, or is it hardcoded and probably won't be configurable??

There are no plans to enable configuration of keys in popup lists.

However, I am considering whether to add a setting like clink.reverse_enter_in_popups. But I'm concerned about adding such a setting, for several reasons.

Some examples:

• If it's possible to reverse how Enter works, that's a little dangerous because then different machines can behave differently, and users have to be extra careful to know how each machine is configured.
• At a minimum the popup footer would need to list Enter=Execute or Shift-Enter=Execute.
• It starts down a path of configuring keys in popup lists, and that gets very complicated very quickly.
• It adds extra clarifications that are necessary when saying how to do something. One can't just say "press Enter", one has to say more like "find out how your popup lists are configured, and then press either Enter or Shift-Enter depending on the configuration, and here is how to tell which way it's configured: blah blah blah".

At a minimum the popup footer would need to list Enter=Execute or Shift-Enter=Execute.

I think there should be such information now, even if this action is not configurable. The problem is that I often select entries from the list, which then only need to be slightly modified before execution. Pressing Enter is too easy/fast and natural, so I often end up running the entry rather than entering it in the console for possible corrections. Sometimes nothing bad happens, but there are commands that can do some damage or create unnecessary additional work. In such cases, it would be much more convenient if triggering them required more attention (a more difficult shortcut).

This isn't the first time I've encountered this problem, so I finally decided to bring it up. It would be best if both of these actions had a configurable shortcut. But if this is not possible, a simple reverse (as you propose) would be enough and solve this problem.

If it's possible to reverse how Enter works, that's a little dangerous because then different machines can behave differently, and users have to be extra careful to know how each machine is configured.

It is enough to clearly describe the use of this option in the manual along with any potential problems in certain environments (if they actually arise). I think that if someone discovers this new option, they will first try to find its official description.

Btw., I noticed that in win-history-list the Left/Right arrows insert an entry without running it, but in the case of clink-popup-history they don't work, although they would be more comfortable than Shift/Ctrl+Enter.

At a minimum the popup footer would need to list Enter=Execute or Shift-Enter=Execute.

I think there should be such information now, even if this action is not configurable.

I've had requests to show literally all available keys. But the available keys don't all fit in the footer.

The reason Del is listed in the history list is because that's the only key whose functionality is conditional/different between the different popup list windows, and because it's completely undiscoverable otherwise.

I get that Enter is interesting as the main action, and it's nice to know what the main action will be. But what happens with Enter is different in each popup list (history, directory, key bindings, custom lists in Lua scripts, etc). Should the meaning of Enter be reversed in all popup lists? Should the meaning be listed in the footer in every popup list? What about custom popup lists shown by Lua scripts, where Clink has no idea what will happen?

There is a slippery slope here, and it quickly falls into complexity that is very difficult to manage.

The problem is that I often select entries from the list, which then only need to be slightly modified before execution. Pressing Enter is too easy/fast and natural, so I often end up running the entry rather than entering it in the console for possible corrections.

Can I ask what software has conditioned you to expect that Enter in a history list won't execute the history entry? Maybe if I know more about the background of this problem, it might help find a solution that doesn't devolve into great complexity.

• cmd's built in popup history list executes on Enter.
• TakeCommand's popup history list executes on Enter.

But,

• fzf's history list filter insert on Enter by default, and fzf has no way to execute by default.
  • You can change its key bindings to whatever you want.
  • However, I don't think there's a way to add a key binding to force execution, though, unless you make special changes to the fzf.lua script as well, and hack together cooperation between the fzf.lua script and the customized fzf key bindings.

Sometimes nothing bad happens, but there are commands that can do some damage or create unnecessary additional work. In such cases, it would be much more convenient if triggering them required more attention (a more difficult shortcut).

Have you considered using fzf with clink-fzf and configuring its key bindings to meet your needs?

If it's possible to reverse how Enter works, that's a little dangerous because then different machines can behave differently, and users have to be extra careful to know how each machine is configured.

It is enough to clearly describe the use of this option in the manual along with any potential problems in certain environments (if they actually arise). I think that if someone discovers this new option, they will first try to find its official description.

Perhaps for you it is enough. I have to think broadly, since everyone would have access to it.

As for "if they actually arise" -- what about when you install Clink on another computer? Or start a new profile? It'll behave the default way again. So if you reversed the behavior, then they'll behave opposite from what you expect.

Btw., I noticed that in win-history-list the Left/Right arrows insert an entry without running it, but in the case of clink-popup-history they don't work, although they would be more comfortable than Shift/Ctrl+Enter.

Correct. Because Left/Right in Clink's popup lists scroll the list contents left/right if any lines don't fit (i.e. got truncated). That's documented behavior.

But what happens with Enter is different in each popup list (history, directory, key bindings, custom lists in Lua scripts, etc). Should the meaning of Enter be reversed in all popup lists? Should the meaning be listed in the footer in every popup list? What about custom popup lists shown by Lua scripts, where Clink has no idea what will happen?

Right, it gets more complicated if there are different variants of lists. Maybe in the first attempt it is worth doing it in a simpler way (like additional information in the footer).

Maybe if I know more about the background of this problem, it might help find a solution that doesn't devolve into great complexity.
cmd's built in popup history list executes on Enter.

In the case of cmd it's much simpler because when I bring up a list window (and I don't remember exactly all the shortcuts for each program), I first try the simplest standard input variants (like Tab or Left/Right), and I always choose Enter as a last resort (if nothing else doesn't work), so here the risk of pressing Enter is lower.

Have you considered using fzf with clink-fzf and configuring its key bindings to meet your needs?

I'll try it out when I have some free time, but clink-popup-history is enough for me and I'd rather avoid further dependencies.

As for "if they actually arise" -- what about when you install Clink on another computer? Or start a new profile? It'll behave the default way again. So if you reversed the behavior, then they'll behave opposite from what you expect.

But this applies to every option changed to a state other than the default one? If we change options, we know exactly what we are doing and what can happen if we do not have access to the previous configuration files.

Maybe it's enough to simply add in the footer that Enter=execute and Shift/Ctrl+Enter=insert for those windows where both of these actions are obvious and noticeably different, like history or directory? There is enough space in the footer for additional information. At least we wouldn't have to guess which key is responsible only for insertion (and maybe it would reduce accidentally pressing Enter). This is not ideal because inserting is more difficult than executing (requires a more difficult shortcut), but at least it would be immediately obvious.

Maybe if I know more about the background of this problem, it might help find a solution that doesn't devolve into great complexity.
cmd's built in popup history list executes on Enter.

In the case of cmd it's much simpler because when I bring up a list window (and I don't remember exactly all the shortcuts for each program), I first try the simplest standard input variants (like Tab or Left/Right), and I always choose Enter as a last resort (if nothing else doesn't work), so here the risk of pressing Enter is lower.

Can I ask what software has conditioned you to expect that Enter in a history list won't execute the history entry? Maybe if I know more about the background of this problem, it might help find a solution that doesn't devolve into great complexity. (The only example I know of is fzf, which it sounds like you haven't used before.)

As for "if they actually arise" -- what about when you install Clink on another computer? Or start a new profile? It'll behave the default way again. So if you reversed the behavior, then they'll behave opposite from what you expect.

But this applies to every option changed to a state other than the default one? If we change options, we know exactly what we are doing and what can happen if we do not have access to the previous configuration files.

My point was that none of the other options control whether something is dangerous. You're right that accidentally executing a history entry can be dangerous. ("clink.ctrld_exits" is the closest to being something that could be considered dangerous.)

What about when you use an instance of Clink where you haven't changed the configuration yet? E.g. on a new machine or in a new profile?

Maybe it's enough to simply add in the footer that Enter=execute and Shift/Ctrl+Enter=insert for those windows where both of these actions are obvious and noticeably different, like history or directory? There is enough space in the footer for additional information. At least we wouldn't have to guess which key is responsible only for insertion (and maybe it would reduce accidentally pressing Enter). This is not ideal because inserting is more difficult than executing (requires a more difficult shortcut), but at least it would be immediately obvious.

I'm only considering adding Enter=Execute, and only for the history list. I'm not adding lots of keys in the footer. The keys are already documented; reading documentation is a good way to find whether any key can insert the entry instead of executing it.

But even doing only that already starts down a slippery slope because then people will complain that Enter= should exist in every single popup list, even in custom Lua scripts. That's not a hypothetical; the expectation has already actually been stated up in other conversations about adding more to the footer.

P.S. clink.popuplist lets the caller specify a specific width. Even just Del=Delete doesn't necessarily fit.

You're raising good points. But there's more to it, and this topic is more complicated than it may appear at first glance.

Commit 729fa89 adds Enter=Execute only in history lists.

v1.6.12 is available with the change.

@chrisant996 Hello,

I see you asked several times:

Can I ask what software has conditioned you to expect that Enter in a history list won't execute the history entry? Maybe if I know more about the background of this problem, it might help find a solution that doesn't devolve into great complexity.

I just want to add my 5 cents onto this topic.

Personally I use clink + fzf on Windows and bash/zsh + fzf on my Linux machines, so probably my vision is polluted.

My opinion is that execution from history is dangerous and it's not always obvious what Enter will do. Despite the fact that I use this configuration like many years, I still forget from time to time what Enter will do (probably, because I use not only my Windows machine). This is actually true even for fzf because unfortunately it also doesn't show any hotkeys on the screen. This makes me to be afraid of pressing the Enter every time. Sometimes I analyze in my head what will happen if I press Enter and the command will be executed as opposed to inserted. And sometimes I even hesitate to press Enter if the command is dangerous enough, and instead I use the mouse to select and copy the command's text from the screen into clipboard, then press Esc, then manually insert the command from the clipboard. Crazy, right? But it is still faster than googling docs about what Enter will do in this specific tool in this specific context.. Often I even don't know what tool exactly is on my screen at the moment. I use several OSes and it's hard to remember that on this specific machine the history is handled by fzf.

Life would be much easier if every history tool would just always insert the history command on Enter and never execute it. Even CTRL + Enter for execution is unnecessary, as if I really want to execute the command, I will just press Enter again. But this time I will do this from command line, where it is obvious that Enter will execute the command, as this behavior is universal between command line interpreters / OSes, therefore no misremembering is possible.

Also, more often than not I need to change the command from history before execution. Even if I don't need to change anything, it is often beneficial to insert the command first to check the full command line (history usually shows trimmed line as it is too long).

So, in my opinion, Enter to insert should be the default and probably the only option in any tool.

Of course, I'm not advocating to change it just because I personally think it will be good. I'm not even a target audience as I don't use clink's history window anyway (I prefer fzf for fuzzy search). I just want to answer your question and make you to better understand why someone could want this.

Cheers and thank you for the continuing the development of this great tool! 👍 Without it, my windows experience with command line would be very bad and I probably would run everything in WSL just like many people that are bringing that trend now.

@xak2000 Thank you for sharing your context. I happen to agree with a lot of what you shared. I'm also interested to know @ArkadiuszMichalski 's context, because that might lead to identifying more options.

My personal view point is similar: in the absence of any other context or pre-existing implementations, I would probably choose for Enter to insert without executing.

But:

• CMD already has a popup history list command, and in it Enter executes.
• 4Dos/4NT/TakeCommand has been famous for decades, and in its popup history list Enter executes.
• Far is also famous, and in its popup history list Enter executes.
• And consider consistency within Clink:
  • The Key Bindings popup list can only execute on Enter; there's no equivalent like "inserting a command".
  • The directories popup list is most convenient if it executes cd somedir on Enter, and that isn't a dangerous operation. If it executes by default, doesn't that make it even more confusing what to expect from Enter in the history popup list?
  • If the history popup list is changed, shouldn't all the other popup lists change as well? But that poses all kinds of different problems...

I receive complaints when Clink is different from bash defaults.
I receive complaints when Clink is different from CMD defaults.
I receive complaints when Clink is different from other programs and shells.
I receive complaints when Clink adds features (like left/right scrolling).
I receive complaints when Clink doesn't add features.

I get it; different people use different software and workflows, and it's natural to want similarity and familiarity. I can't control the fact that a bunch of programs already exist and already behave differently from each other. There's no way to please all competing perspectives, so I try to find reasonable compromises.

• I don't want this specific detail to be configurable, because I know with absolute certainty that I will run afoul of it when I start new profiles or freshly install Clink on a new machine or VM, and so on. And I bet I'm not alone in that.
• Ambiguous predictability has potential to be even worse than a default that's opposite from what some users expect, particularly when the operation can potentially be dangerous.
• If I reverse the behavior now, then that will create problems for everyone who is accustomed to pressing Shift-Enter to insert.

I don't see a good path forward that accommodates all viewpoints and concerns.
For now, I've added Enter=Execute in the footer, to be clear about the behavior.

Fzf is a good alternative approach, which allows insert (but doesn't even allow execute). The OP said they don't want to add another dependency, and that's a very reasonable position.

@xak2000

My opinion is that execution from history is dangerous and it's not always obvious what Enter will do. Despite the fact that I use this configuration like many years, I still forget from time to time what Enter will do (probably, because I use not only my Windows machine). This is actually true even for fzf because unfortunately it also doesn't show any hotkeys on the screen. This makes me to be afraid of pressing the Enter every time. Sometimes I analyze in my head what will happen if I press Enter and the command will be executed as opposed to inserted. And sometimes I even hesitate to press Enter if the command is dangerous enough, and instead I use the mouse to select and copy the command's text from the screen into clipboard, then press Esc, then manually insert the command from the clipboard. Crazy, right? But it is still faster than googling docs about what Enter will do in this specific tool in this specific context..

It sounds like you're describing my experience. After a few unwanted calls commands from history, I started to be afraid of this Enter and was looking for a solution to prevent this. This window is very convenient in everyday use, but the constant thinking before inserting an entry is tiring. I'm surprised that no one has brought this up yet.

@chrisant996
I still don't understand the problem with an additional option that, for example, will reverse or force Enter to only insert. After all, this is an option that will work if the user makes an effort to activate it. For everything else, the default behavior will continue.
What problem is a new profile or a separate machine? It is obvious that each program must be set again relative to the default settings. After all, none of the changed options will work if I don't import my personal settings again in the new environment.
This Enter is really dangerous and inconvenient in everyday work and its control through the option is highly recommended. The fact that something works this way in other programs does not mean that it cannot be improved, after all, that is what Clink does, it improves the weaknesses of other programs.
Personally, I do not encourage changing the default behavior to which most people are certainly accustomed. But that's what the options are for, allowing me to personalize behavior that doesn't suit me personally.

Fzf is a good alternative approach, which allows insert (but doesn't even allow execute). The OP said they don't want to add another dependency, and that's a very reasonable position.

At the moment I don't have time to explore the new tool, but I will try it someday (because maybe in my case it will be more convenient, who knows).

For now, I've added Enter=Execute in the footer, to be clear about the behavior.

It's nice because we immediately know that Enter may cause problems, but would there be any chance to add other simpler shortcut for insertion? Personally, I would prefer to stay away from Enter as much as possible, so the Shift|Ctrl+Enter combination is constantly stuck in my head (what if I don't press Shift or Ctrl enough)? What if only Shift or Ctrl or Space or Tab or some other key which is not used in any way by these windows will also be responsible for the insertion?

If anyone has more interesting observations or simpler solutions, feel free to share them.

It sounds like you're describing my experience. After a few unwanted calls commands from history, I started to be afraid of this Enter and was looking for a solution to prevent this.

I understand that part. I'm interested to know what happened sometime in the past, before ever using Clink, that set the expectation that Enter would not execute. I.e. why was it surprising that Enter executes in the history list? It executes in the command line. It executes in a menu. It executes in dialog box. Etc.

Is there some other specific software experience you're used to where Enter on a selected command does not execute the command? I want to learn about that other experience. I consider it a valid experience, whatever it was -- I'm not going to try to explain it away, instead I want to understand it.

I still don't understand the problem with an additional option that, for example, will reverse or force Enter to only insert. After all, this is an option that will work if the user makes an effort to activate it. For everything else, the default behavior will continue.
What problem is a new profile or a separate machine? It is obvious that each program must be set again relative to the default settings. After all, none of the changed options will work if I don't import my personal settings again in the new environment.

I understand where you're coming from, and I'm examining many more details and considerations. I'm sorry the concerns aren't making sense. I have half a mind to just add an option, without addressing any of the problems it creates, and let the problems become obvious through empirical experience. But I don't think that would be fair to anyone, and that would make it even harder to address the problems later.

This Enter is really dangerous and inconvenient in everyday work and its control through the option is highly recommended. The fact that something works this way in other programs does not mean that it cannot be improved, after all, that is what Clink does, it improves the weaknesses of other programs.

The fact that this exact thing works differently in most other programs means that behaving differently is likely to be unexpected, and needs to be considered carefully. Especially because there is potential for danger. I'm sorry the dangers aren't making sense.

I hear you. But this is not nearly so simple or straightforward as you're suggesting.

It's nice because we immediately know that Enter may cause problems, but would there be any chance to add other simpler shortcut for insertion? Personally, I would prefer to stay away from Enter as much as possible, so the Shift|Ctrl+Enter combination is constantly stuck in my head (what if I don't press Shift or Ctrl enough)? What if only Shift or Ctrl or Space or Tab or some other key which is not used in any way by these windows will also be responsible for the insertion?

For any suggestion about the history popup list, I have to ask "how would this work in all other popup lists in Clink, including custom ones added in custom Lua scripts that I don't even know about?"

I recognize that only the history popup list seems to be of interest in this conversation. But these suggestions affect way more than just the history popup list. Or if they don't, then they create a fragmented experience that causes other problems.

I can't agree quickly to these suggestions, because there's much deeper investigation necessary to avoid creating more problems than it solves. You don't have to engage in the deeper investigation, but arguing against deeper investigation would undermine credibility.

@chrisant996

I understand that part. I'm interested to know what happened sometime in the past, before ever using Clink, that set the expectation that Enter would not execute. I.e. why was it surprising that Enter executes in the history list

Is there some other specific software experience you're used to where Enter on a selected command does not execute the command? I want to learn about that other experience. I consider it a valid experience, whatever it was -- I'm not going to try to explain it away, instead I want to understand it.

I'm a 20+ years long time MC (Midnight Commander) user. It is my main instrument for any Unix system. Previously in the times of DOS and Windows 95 I used Volcov Commander and Norton Commander. So, again, my experience is probably not a main-stream for today's trends. But you asked for a software - this is it. :)

In MC ALT-H brings the history of commands and SHIFT-ALT-H brings the history of directories.

• In the history of directories Enter changes the current location instantly.
• In the history of commands Enter just puts the command into command line, so you can inspect/change/execute or clear the command line.

As you can see the behavior is inconsistent in these 2 lists. This is true, but to me this behavior is totally sane and expected. And what is even more important: even if someone forgot that Enter will not execute the command, this behavior will be obvious after pressing Enter - the command will be insterted in the command line - and the one can just hit Enter again. It is safe-by-default behavior. The other behavior is dangerous by default.

From the tools you described I have used only Far, but very long time ago, so I do not remember how it worked. Never used cmd inbound history list. Didn't even know it exists. I didn't actively used cmd before I discovered clink. Bare cmd is too bad after Unix command line interpreters. So, on Windows I usually just used MinGW with bash. I do not remember how I managed command history in this setup. Probably I used fzf too.

I don't want this specific detail to be configurable, because I know with absolute certainty that I will run afoul of it when I start new profiles or freshly install Clink on a new machine or VM, and so on. And I bet I'm not alone in that.

I'm not sure I understand your concerns about the configuration option. It is a configuration option after all. It's not changing of defaults (that I would prefer, but it's just me 😄). So, if you change some options on PC1 and then do a fresh install on PC2 without your config, then all the options will be default. It is totally expected behavior. I can't imagine someone complaining about it. :) How else configuration options could work?

The only scenario I can think about, is that you just want to protect people from themselves. If someone changes the default settings on PC1 and then will accidentally execute a dangerous command on PC2 because they forgot that on PC2 the settings are not configured the same way as on PC1... then yes, probably, this could be problematic. But with the same logic every existing software should remove the hotkeys configuration, then. :) Most people will not change them anyway. They are supposed for people who want to change them for one reason or another.

Nevertheless, personally I don't think that the option like reverse_enter_in_popups would be the best solution. I don't think that Enter should necessarily do the same thing in different kind of popups. As you mentioned, for history of directories the most convenient behavior is to cd instantly, as there is nothing to check/confirm/change here. Err... probably, change would still be useful (e.g. select cd c:\Users\me\projects\workspace1 and change 1 to 2), but most of the times it is not and what is more important: you can always do cd ..\workspace2 after this - you are still on the safe side.

I don't know what Bindings popup list is, so can't say anything about it.

Anyway, I fully understand that you must consider much more than I or some other peope as you must think about all the functionality as a whole. To my shame, I don’t know even half of the clink’s functionality.

@ArkadiuszMichalski I strongly suggest to try fzf. Especially considering that @chrisant996 kindly provided the integration with clink out of the box. The ability to search the history is priceless. Often I don't remember when exactly I executed the command I need. It feels like 2-3 days ago but it was really 3 months ago. 😄 Sometimes I don't even remember the name of the command - just some arguments of it I used (like the path of the file on the disk or the project name). So, fuzzy search combining with convenient and familiar (if you have a unix background) CTRL-R instead of F7 and as a bonus the behavior of Enter you want. :)

@xak2000 Perfect, thanks, that's exactly the kind of context I wanted to learn.

I assumed that since Far is kind of the spiritual successor to Norton Commander, and Far executes on Enter in the history list, then probably NC also did. My assumption was wrong, and that's very useful to know.

I used NC for a while back in the day, but ultimately settled on using 4Dos/4NT. And in those JPSoft products execute on Enter in the history list.

So my perception had been that execute was predominant.

Why am I asking these questions, and what am I considering?

I'm actually considering removing the ability to execute on Enter ... And maybe even completely removing the ability for any key combo to execute in the history list.

The sole reason I made it execute was for compatibility with CMD and JPSoft and Far. Because some friends who are long time CMD or JPSoft or Far users have expressed strong expectations for 100% behavioral compatibility (which is obviously not fully possible anyway).

But I don't like the risks it poses. So I want to take a deep hard look at feasibility of completely removing the ability to directly execute.

Although, an accidental double tap of Enter would still execute after inserting. And blocking that kind of accident gets prohibitively problematic.

I'm not a fan at all of allowing it to be configurable -- that opens the door to even more problems.

So, I either want to completely remove execute on Enter, or I want to find an in between compromise, like Enter=Execute in the footer. If the footer doesn't do the job well enough, then I'll probably just remove the behavior.

@chrisant996 Just to clear, it is not NC (Norton Commander) that I described at the beginning of the previous comment. It's MC (Midnight Commander) - a spiritual successor of NC, but for Unix.

I hardly remember anything about NC as I used it last time 20 years ago when DOS (and Windows 3.11, 95, 98) was predomintant. With Windows 2000 and later there was no more DOS under the hood - all later Windows systems were NT-based. And NC/VC were superseded by TC (Total Commander) and Far on Windows. And with MC on Unix.

Yes, agreed - in my mind if any of the NC-like breed insert instead of execute, then that strongly undermines the "but compatibility!!!" arguments that pushed for execute.

By the way, a clarification:

Choosing a history item in the popup list and pressing Shift-Enter doesn't "insert" the selected history item.

Instead, it jumps to the selected history item in the command history. As if you pressed Up/Down repeatedly in the input line until you reached the selected history item (i.e. pressed a key bound to previous-history or history-search-backward or other history navigation commands). You can subsequently invoke history navigation commands to continue navigating through the command history (previous-history or next-history or etc).

So, I wouldn't want to make the footer claim that it "inserts", since that's not actually what it does.