[eviks]

It's better to learn tools that will improve over time rather than being stuck with all the design mistakes of the past (for your example, selecting "synt" from a command palette that autoselects node or ruby depending on your file is more powerful than having to remember individual invocations)

[deredede]

I used Vim almost exclusively for a long time but am currently using vscode and I actually low-key hate the command palette. It's not always consistent (if you type return too fast you sometimes get a different command! Crazy) and I am never quite sure what it will execute, which means I lose time and focus waiting and double-checking.

[eviks]

Return issue seems like VSCode specific? Does it manifest in Sublime?

You also lose time on double checking typos in the term command (and it's harder to focus since unlike front&center palette this command is tucked away at the bottom), except you have no additional validation from a preselected set, so you need to remember the full command invocation precisely

And you can add special unique symbols to command names to make search unambiguous

You also get a hint re keyboard shortcut, unlike with the term command, so if you execute it often enough, you might switch to a faster and more predictable method

[deredede]

I think the return thing is a classic issue of autocomplete systems: what do you do if the user hits return (or decides to) and some characters are not yet reflected in the UI showing the current suggestion? Whatever you do there'll be misunderstandings.

I have a fairly high typing accuracy on physical keyboards, in particular when I'm in a focused state, so I actually don't double-check editor commands most of the time -- I let them fail, which happens rarely, and only double-check them the second time.

And yes, in practice I use shortcuts mostly (although either vim extension shortcuts or custom ones, usually, because many shortcut don't work as is in the vim extension, so the command palette hint is useless to me as well - but I don't hold vscode responsible for that).

[eviks]

It's a classic issue of slow autocomplete systems, why should there be any perceptible delay for such tiny data sets?

If you don't double check, it's most likely that you use it for something you're certain about, so it's more like a key chord rather than a search bar? In that case for these frequent commands it might make sense to add those unique symbols/letter combos (some extra Unicode symbols can help here) so that the fuzzy algo will never trip

And not showing currently active shortcut for a palette command is just another bad UI implementation, that kind of info should be centralized/anyways up-to-date so you can use it in palettes or menus or what not

[endorphine]

changing != improving

And a program can be improved even without it being changed substantially.

[eviks]

but not changing = !improving

(that's why you had to add the "substantially" qualifier)

[endorphine]

> but not changing = !improving

Correct, but vim is changing. Latest release happened 9 hours ago, and in the past week there have been 17 commits pushed to master by 7 authors[1].

Also, there are a dozens of high-quality plugins that are in constant development.

> (that's why you had to add the "substantially" qualifier)

I was quoting the parent comment in which you originally replied (quoting again):

    I see very little reason the shell and vim will substantially change in the next 40 years…

[1] https://github.com/vim/vim/pulse

[eviks]

> there have been 17 commits pushed to master by 7 authors[1].

And there are 17 thousand commits overall, yet a lot of fundamental issues remain unresolved, so I guess I'd argue that in many cases a program can NOT be substantially improved without substantial changes (again, not universally!, some crash/perf wins are "free" in that they can change nothing in the program's user-facing behavior)

So I see a lot of reasons for the shell/vim to substantially change, and thus stability in this regard is a negative, not a positive, hence my comment that it's better to use tools that improve better (though you're right that improvement is not a given for a change)