[taf2]

Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things… need a quick syntax check !node -c % , or need to run a command !ruby %

It’s just faster when you are connected shell… and unlike vscode - vim is pushing 30 and the shell environment 40, I see very little reason the shell and vim will substantially change in the next 40 years… but I guarantee vscode will look very different… so learn a tool for life that will be just as powerful tomorrow as it is today

[AdieuToLogic]

> Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things…

Quite true.

Also, partial buffer manipulation can be done with external programs via range constraints. For example, to reverse sort only the first 5 lines of in buffer, one can execute this ex[0] command:

  :1,5 !sort -r

0 - https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sekti...

[schoen]

I like to use vi as a kind of IDE for shell commands, because you can, for example,

!}somecommand

to pipe a paragraph through that command, or

1G!Gsomecommand

to pipe the whole editing buffer through that command, which is also equivalent to

:1,$!somecommand

which I find less obvious as a way to do that, even though it makes sense historically in terms of ed and ex.

You can also, in vim, use u and ^R to undo your pipe transformation and redo it, so you're basically then doing a series of shell pipe transformations with interactive history.

If you need to generate text with a shell command instead of pipe existing text through it, you can use

:r!somecommand

Commands that I like to use in this context include tac, rev, tr, cut, grep, and sed (although using sed this way is a little silly since the substitutions I'm doing are normally also available natively inside of vi itself).

A simple example that I like a lot is

1G!Ggrep .

which removes all empty lines from the current file. ("Line 1 go to line, pipe from here to result of movement go to end of file, command 'grep .' [print lines that match 'any character']")

The classic ed/ex way to do this is

:1,$g/^$/d

which is just as many characters, but which requires lots of explicit thought for me, while the "1G!G grep ." version seems to no longer require explicit thought at all. ("For lines 1 to last line, repeatedly match ^$ [line beginning immediately followed by line end], delete matching lines.")

[tomsmeding]

Does :% not work in vi as an abbreviation of :1,$ ? The classic :%s/foo/bar/ generalises to :%!somecommand .

[schoen]

It does, thanks for the reminder!

[u801e]

> For example, to reverse sort only the first 5 lines of in buffer, one can execute this ex[0] command:

> :1,5 !sort -r

Interestingly enough, you don't even need an external program for that. You can do the same thing with

    :1,5 g/^/ m 0

The g command allows for effectively looping over matching lines as opposed to operating on them all at once. The /^/ matches every line and since I'm using 1,5 for the address, it still only matches the first five lines. The m command moves a line (in this case, 0 which is the beginning of the buffer).

Since it executes it one line at a time, it moves the first line to the beginning of the buffer, then the second line (which places it above the first line), then the third line (placing it above the second line) and so on.

[_TwoFinger]

Your command doesn't sort, only inverses the initial order. It's equivalent to

  :1,5 !tac

[0x0203]

And in newer versions of vim you can even run a terminal inside a vim buffer. Use :term to get started. ^w N to go from terminal insert mode to buffer mode where you can treat all terminal contents as regular text. Useful when you want to grab bits of program/script output and put it into a different buffer, or search the output with / and ?. You can also paste register contents directly into the terminal command line, e.g., if you have a text file with a list of long file names, you can yank one into register a with "ayy, move to the terminal window and do a cat ^w"a to cat the file name. (Or just yy to yank and ^w"" to paste in term if you're in a hurry). Handy in some circumstances.

[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)

[blep-arsh]

vim is still very hostile to multilingual users with multiple keyboard layouts. You have to switch to a Latin layout before using any commands and switch back in order to input command arguments or go back to text input. Yes, remaps do exist but that's still a partial solution that doesn't work in all contexts. Nah. I can use a slightly less capable editor that keeps commands cleanly separated from the input language. Another issue is that commands are utterly unergonomic, requiring lots of rapid Shift presses/releases, and mistakes can lead to destructive consequences.

[drbaba]

> Another issue is that commands are utterly unergonomic, requiring lots of rapid Shift presses/releases

Curious. Unergonomic compared to what? Given your comment about separating commands and input language, I assume you’re using a non-modal editor, which usually rely more on modifiers than Vim.

Personally, I haven’t found any ergonomic non-modal editor, where I by “ergonomic” mean no RSI pain even after heavy usage. For me, the fact that editing in Vim is comfortable is its main selling point (more so than its speed).

> mistakes can lead to destructive consequences

I do often make mistakes, but I can’t remember the last time I accidentally did something so destructive in Vim that I couldn’t just undo it normally.

[blep-arsh]

I'm not referring to keyboard ergonomics in my comment; I just can't input some of the required key sequences reliably and without making mistakes (not good at playing the latest Zelda game with its key combos either).

For example, I'm sometimes transposing characters, e.g. q: instead of :q, or :w! command instead of :w !command, that sort of thing. Undoable, of course, just not with a simple u.

Modifier-based shortcuts in other editors and IDEs appear to be more forgiving.