6 ms·

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

by taf2 3y ago

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 3y ago
> 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&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sekti...
- schoen 3y ago
  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 3y ago
    Does :% not work in vi as an abbreviation of :1,$ ? The classic :%s/foo/bar/ generalises to :%!somecommand .
    - schoen 3y ago
      It does, thanks for the reminder!
- u801e 3y ago
  > 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 3y ago
    Your command doesn't sort, only inverses the initial order. It's equivalent to :1,5 !tac
eviks 3y ago
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)
- endorphine 3y ago
  changing != improving And a program can be improved even without it being changed substantially.
  - eviks 3y ago
    but not changing = !improving (that's why you had to add the "substantially" qualifier)
    - endorphine 3y ago
      > 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 https://github.com/vim/vim/pulse
      - eviks 3y ago
        > 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)
0x0203 3y ago
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.
blep-arsh 3y ago
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 3y ago
  > 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 3y ago
    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.

by taf2 3y ago

AdieuToLogic 3y ago

> 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&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sekti...

schoen 3y ago
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 3y ago
  Does :% not work in vi as an abbreviation of :1,$ ? The classic :%s/foo/bar/ generalises to :%!somecommand .
  - schoen 3y ago
    It does, thanks for the reminder!
u801e 3y ago
> 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 3y ago
  Your command doesn't sort, only inverses the initial order. It's equivalent to :1,5 !tac

eviks 3y ago

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)

endorphine 3y ago
changing != improving And a program can be improved even without it being changed substantially.
- eviks 3y ago
  but not changing = !improving (that's why you had to add the "substantially" qualifier)
  - endorphine 3y ago
    > 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 https://github.com/vim/vim/pulse
    - eviks 3y ago
      > 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)

0x0203 3y ago

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.

blep-arsh 3y ago

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 3y ago
> 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 3y ago
  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.