Should Auto-Suggestions be OFF by default?

[chrisant996]

I'm seriously considering turning the Auto-Suggestions feature off by default:

It seems like the Auto-Suggestions feature causes a lot of confusion and questions.
I'm seriously considering turning the feature off by default.

Should it get turned off by default?
Or should it stay on by default?

Please vote, and also please feel welcome to add a reply with your thoughts on the topic.
All thoughts and perspectives are welcome, and can help influence the outcome for the whole Clink community.

[hutcho]

This suggestion feature is the main reasons I use and recommend clink. It is confusing that suggestion and completion are 2 very different ideas in clink, because they are semantically similar concepts. I didn't realise they were different things until I spent hours studying the documentation. I think the wording should change in a way that makes it clear that:

1. suggestions = historical
2. completions = non-historical

So yes, I think the suggestion feature should be left on by default. Without it, clink is not useful out of the box. From following the project for the past few weeks, I have noticed that the expectation is that people who use clink are expert tinkers and settings modifiers, but I don't think that should be the assumption. I think the assumption should be that clink users are people who a new to cmd prompt, and are seeking a friendly and helpful tool to speed up their cmd prompt usage.

A default that should change is exec.enable. exec.enable should be set to false by default, because it drastically changes the cmd prompt default behaviour in unexpected ways.

What is also confusing is Use enhanced defaults. There should be 1 set of defaults, and it should use "windows" defaults. It makes assisting users very hard when there's 2 versions of default settings.

I think the goal should be that clink enhances cmd prompt in 'Windows' like ways. It's basically cmd prompt plus. Clink defaults shouldn't drastically change cmd prompt behavior.

[chrisant996]

I think the wording should change

But Suggestions are not only historical.

• The "history" strategy makes suggestions from history.
• The "completion" strategy makes a suggestion from the first available completion.
• The order in which strategies are listed in autosuggest.strategy specifies the order they are given a crack at offering a suggestion (they're consulted in order, and the first suggestion that gets returned is the one that's shown).
• Other strategies can use other criteria -- for example they could examine syntax of certain commands. I have a custom "doskey" strategy which automatically suggests appending $* to the end of any doskey macro.

The Suggestions feature is lifted almost verbatim from the fish shell. I didn't design it, I just copied the design into Clink.

I have noticed that the expectation is that people who use clink are expert tinkers and settings modifiers, but I don't think that should be the assumption. I think the assumption should be that clink users are people who a new to cmd prompt, and are seeking a friendly and helpful tool to speed up their cmd prompt usage.

I would phrase it differently:

Because there are so many competing preferences about how Clink should behave, it's inherently necessary to have a large amount of customizability. This unfortunately means that anyone who wants behavior other than the defaults needs to make some customizations.

Even worse, Clink has two completely separate configuration systems, and that existed long before I took over as maintainer.

1. It uses the Readline library, and so there's the .inputrc file configuration system -- and if you aren't brand new to Readline or bash, then Clink can read your existing .inputrc file from Unix or Linux (or even Git Bash on Windows) and pick up your existing Readline customizations.
2. Clink doesn't own or define Readline, and Clink needed a way to have additional customizations. So there's the clink_settings file and the clink set configuration system.

What is also confusing is Use enhanced defaults. There should be 1 set of defaults, and it should use "windows" defaults. It makes assisting users very hard when there's 2 versions of default settings.

There are two large and very different audiences who both use Clink:

1. Unix/Linux users who want a bash-like experience in cmd. This was the main user base of Clink.
2. Windows users who want enhancements in cmd, but for it to still be a cmd-like experience in cmd. This is the group I'm in, but this seems to be a much smaller group.

Historically, when Clink was created, Martin made it use Unix bash defaults, to bring bash-like input line editing to Windows.

I can't change the defaults away from Unix bash without enraging the main user base of Clink. Even minor departures have gotten negative feedback. There are many issues saying "I want Windows-like TAB completion!!" where someone installed without "Use enhanced defaults", and many issues saying "I want Unix-like TAB completion!!" where someone installed with "Use enhanced defaults".

There is an inherent sharp and diametrically opposed split in preferences.

I think the goal should be that clink enhances cmd prompt in 'Windows' like ways. It's basically cmd prompt plus. Clink defaults shouldn't drastically change cmd prompt behavior.

I get where you're coming from. That would have been my view as well, if I had been an original author of Clink. But that's actually opposite to the reason Clink exists! Clink was created specifically to drastically change cmd prompt behavior and drastically change cmd input behavior, and make them both behave like Unix bash.

[chrisant996]

Also, if a feature is on by default but generates a large amount of "what is this" or "how do I" or "I'm confused" questions, then that's a bit of a problem because I don't want to be in a position where my role is expected to be someone who spends their time copy/pasting answers out of the documentation. In my view, features should be off by default if they won't make sense without reading documentation first.

And that's why I'm wondering about turning Auto-Suggestions off by default. There seems to be a large amount of confusion about them.

I tried adding the [Right]=Accept Suggestion hint as a way to help make the feature more discoverable. And in Windows Terminal that hint is actually an underlined hyperlink, and Ctrl-Click on it opens the documentation on the feature. But it still seems to be highly confusing.

[hutcho]

The [right]=Accept Suggestion idea is good and still is. I think the wording is an issue. One isn't really "accepting" the suggestion because you can edit it after pressing right. The action of pressing right feels more like "take suggestion" than "accepting" the suggestion.

And without suggestions on by default, clink isn't clink. Instead of disabling it as default I think experiments need to be done to try improve new user understanding. Do you have a list of issues raised regarding suggestion confusion? The first question I have is "why are new users installing clink"?

You mention windows terminal as well. It's what I use, and I consider it the first step to improving cmd. I think clink is the second step. Maybe the clink documentation about install should recommend windows terminal be installed too?

[chrisant996]

The [right]=Accept Suggestion idea is good and still is. I think the wording is an issue. One isn't really "accepting" the suggestion because you can edit it after pressing right. The action of pressing right feels more like "take suggestion" than "accepting" the suggestion.

The word in the hint is not the problem. That's not something I'm going to focus on. And there is value in using the same terminology and behavior as the fish shell where the feature was invented.

If I were going to change the word, it would be "insert", not "take".

And without suggestions on by default, clink isn't clink.

I hear the compliment you're giving about the feature, and I'm glad you find it very useful!

But Clink existed for many years before that feature was added. I'm sorry, but no -- Clink is Clink independently from that feature, and Clink adds much (much, much) more than that feature.

Instead of disabling it as default I think experiments need to be done to try improve new user understanding. Do you have a list of issues raised regarding suggestion confusion? The first question I have is "why are new users installing clink"?

We're getting off topic. But as I said, auto-suggestions are not -- at all -- a main reason why Clink gets installed. Clink was popular long before that feature was added. The reason Clink was created was to change Cmd to behave like Bash from Unix/Linux. That and customizable prompt are the main reasons it became popular. And Cmder includes it by default, and thus anyone who uses Cmder gets Clink automatically -- and the reason Cmder included Clink is for the customizable prompt, so that the prompt can look and behave the same in all of the shells that Cmder supports.

The problems that occur from the auto-suggestions feature are many different forms of confusion about the difference between auto-suggestions and completions. There have been many proposals to improve auto-suggestions that actually involve removing both auto-suggestions and the completion commands, and replacing them all with a much more limited version of completion that has usability problems and is incompatible with bash-style completion (which inserts the longest matching substring -- if you're not familiar with bash-style completion, read up on how that works).

The confusion costs me a lot of time explaining the same things, over and over. If people aren't going to read the documentation, that's a personal choice and I respect that choice. But I'm not going to spend my time copy/pasting answers out of the documentation; that's not how I want to spend my life. That's my choice about my time, and I believe it deserves respect. The easiest way to halt that drain on my time is to make the confusing things be off by default. That naturally leads to learning about a feature before enabling it, or enabling it with the intent of exploring how it works -- both of those involve a different mindset than when a confusing feature is forced upon people without any warning.

Even you yourself said you found the feature confusing and spent hours studying the documentation. Simply put, defaults in software should not require that from users!

You mention windows terminal as well. It's what I use, and I consider it the first step to improving cmd. I think clink is the second step. Maybe the clink documentation about install should recommend windows terminal be installed too?

Clink is Clink. Clink is not a collection of recommendations for what software to install and how to configure your workstation.

[chrisant996]

It is confusing that suggestion and completion are 2 very different ideas in clink, because they are semantically similar concepts.

They're very different because their usage models are very different. The more one looks at their capabilities and usage models, the more starkly and significantly different they are.

Completions are invoked when you specifically ask for them.
Completions help fill in the next argument in a command line, from a list of options based on context-aware parsers, or from a list of files if no parser is available for the specific context at hand.
There are 3 very different usage models for completions -- bash-style completion of longest matching substring, cycling through inserting each match in succession, or an interactive grid navigable via arrow keys etc (and for example using fzf introduces a fourth usage model).

Auto-suggestions are offered automatically without you asking for them.
Auto-suggestions can be about more than just the next argument, and they are not constrained to a list of options.
They're meant to be used as "yes that's what I want" or "that's not what I want, so I'll ignore it keep typing" -- but they have to not break any of the 3 (4) usage models for completion, which is why auto-suggestions can't be connected to Tab.