I really wish that people would stop saying this. You're really not that likely to need to ssh into some random system unless you're a system administrator of some sort - in which case you'll...
Wherever you SSH today, you can start the Vim session, or at least Vi session. That is a strong (if not the strongest) point to learn it nowadays.
I really wish that people would stop saying this. You're really not that likely to need to ssh into some random system unless you're a system administrator of some sort - in which case you'll likely have permissions to install whatever editor you want. And even without that there are plenty of tools that allow you to locally edit remote files with the editor of your choice. You really are not going to find many times you are 'forced' to use vi.
In any case, I find it strangely relieving to see the reason why vi uses escape to return to command mode. That's easily my biggest gripe with vi, since it's so far away from everything else with most modern keyboards.
It's a lot more common than that for people beyond sysadmins, in my experience. Older systems without nice tooling where it's the only real way to debug a situation in production, contractors...
You're really not that likely to need to ssh into some random system unless you're a system administrator of some sort - in which case you'll likely have permissions to install whatever editor you want.
It's a lot more common than that for people beyond sysadmins, in my experience. Older systems without nice tooling where it's the only real way to debug a situation in production, contractors given access to certain boxes, going through jump servers and bastions, (usually smaller) organizations without completely siloed engineering and dba / ops departments, etc.
Even for sysadmins, it's rare that an organization will let arbitrary software of your preference be installed on their servers; usually it's either "this is the tooling we use across the organization" or "your personal preference doesn't justify the risk when we already have X".
Sure, but those situations are shrinking away with time. And like I said before you still can edit the files locally with whatever editor you prefer, so you still have no need to learn vi.
Sure, but those situations are shrinking away with time. And like I said before you still can edit the files locally with whatever editor you prefer, so you still have no need to learn vi.
I wouldn't necessarily say that's true anymore. Even beyond the scenarios @DrStone mentioned, the rise of microcontroller, microcomputer and IoT devices, and the "maker" community's widespread use...
You're really not that likely to need to ssh into some random system unless you're a system administrator of some sort
I wouldn't necessarily say that's true anymore. Even beyond the scenarios @DrStone mentioned, the rise of microcontroller, microcomputer and IoT devices, and the "maker" community's widespread use of them, has brought on a whole new wave of linux based products often only accessible via ssh. Though admittedly most of those devices don't usually force you to use vim (even though it's often still the most convenient)... so I guess your other point about not really needing to know it still stands. :P
So the setup is very simple and you can find it here. It only took some trial and error—keymaps on Linux are not super intuitive IMHO. The main script is init_keys. Replace the br with your...
So the setup is very simple and you can find it here. It only took some trial and error—keymaps on Linux are not super intuitive IMHO.
The main script is init_keys. Replace the br with your keyboard layout on setxkbmap -option -layout br.
Run init_keys on startup either manually or automatically. On Linux I use i3wm, so I just call it from ~/.config/i3/config (which i3 runs on startup).
This sets my keyboard layout just to make sure (not really necessary, but useful to reload my settings when I'm messing with keymappings), sources xmodmap changes (you could do that on single file too, I just like it that way), kill xcape if it's running (again, useful when I'm messing with stuff, not required on first run), starts xcape and sets my keyboard repeat rate (I like it extra fast).
I appreciate the advice! Been away from Linux for a while and currently heading back, so reminders of things I've forgotten or not used much before are awesome.
I appreciate the advice! Been away from Linux for a while and currently heading back, so reminders of things I've forgotten or not used much before are awesome.
I just had to do this last week. I had to connect to an EC2 instance and modify a file but nano wasn't installed. My next best guess was vim which worked. It's common enough I feel a pressure to...
I just had to do this last week. I had to connect to an EC2 instance and modify a file but nano wasn't installed. My next best guess was vim which worked. It's common enough I feel a pressure to learn the basics of it.
I've never felt the need to become more proficient in vi/vim (or even emacs). The extent to which i've ever had to use an editor on a remote machine was simple or infrequent enough that I've...
I've never felt the need to become more proficient in vi/vim (or even emacs). The extent to which i've ever had to use an editor on a remote machine was simple or infrequent enough that I've always been able to get by only with nano (or in many earlier unix years pico)...but i've never used/had access to (or even heard about) a unix or linux machine that lacked either nano or pico...so, this is quite an interesting anecdote! If this is a possibility (I've never used EC2 machiens from say AWS), then i guess i better brush up on at least vi, since that is supposed to be installed "everwhere".
My SO's job is to literally ssh into clients servers and debug her companies software, while it's pretty unusual these days to have no alternatives to vi(m) it's still by far the most likely to be...
My SO's job is to literally ssh into clients servers and debug her companies software, while it's pretty unusual these days to have no alternatives to vi(m) it's still by far the most likely to be on that system . As part of my job I submit long running jobs on a fairly locked down server, the server only has vi as an editor so if I want to do any scripting I'm using vi, sure I could email the sysadmins and request they give me nano or something, but they will also reply "learn vi".
You are the second person to ignore my point that you can use your local editors. Listen, I get that you use vi and maybe even prefer it over other editors. There's no judgement here. I use vi...
You are the second person to ignore my point that you can use your local editors.
Listen, I get that you use vi and maybe even prefer it over other editors. There's no judgement here. I use vi from time to time as well. I'm just saying that "you might need to know it" is not really true any more. This does not affect how you choose to edit files.
Setting up local editors for remote editing is generally not easy either. Easier than learning all the ins and outs of vi, sure - but probably not easier than learning the few commands needed to...
Setting up local editors for remote editing is generally not easy either. Easier than learning all the ins and outs of vi, sure - but probably not easier than learning the few commands needed to make small changes.
I respectfully disagree. If you are using an editor with sftp built in, all you have to do is give it your credentials to access the server. If you are already using a dedicated sftp tool, chances...
I respectfully disagree. If you are using an editor with sftp built in, all you have to do is give it your credentials to access the server. If you are already using a dedicated sftp tool, chances are it has an edit option which will download the file to a temporary location and automatically upload it whenever it changes, which lets you use any arbitrary editor you want. And in either case, once you set it up it's done. There's no need to learn anything except where to get to the connection settings.
While Kakoune is interesting, I prefer neovim with vim-visual-multi. Personally I don't think Kakoune's editing model is that much of an improvement, here's a good writeup. vis is also really cool...
While Kakoune is interesting, I prefer neovim with vim-visual-multi. Personally I don't think Kakoune's editing model is that much of an improvement, here's a good writeup. vis is also really cool and I really like the structural regular expressions approach to multiple cursors, however it lacks vim/neovim's great ecosystem.
Can't really argue about it. I'm not deep into programming yet so maybe i will stumble with some issues in kakoune, but in the end i think everyone adapts to the tools they keep using. I'm sure...
Can't really argue about it. I'm not deep into programming yet so maybe i will stumble with some issues in kakoune, but in the end i think everyone adapts to the tools they keep using.
I'm sure someone who've been using vim/neovim for years and have a very specific config and plugins will have problems with kakoune and vice-versa.
I keep kakoune plugin-free and i love the way it integrates with external tools, piping in and out, etc... I'll try to keep it that way, but i'll see what the future holds. For programming in Go for now it's been delightful.
It’s quite possible to outperform Vim and Emacs when it comes to the basics, the problem is competing with hundreds of external packages that grant astounding functionalities to the users.
It’s quite possible to outperform Vim and Emacs when it comes to the basics, the problem is competing with hundreds of external packages that grant astounding functionalities to the users.
Interesting post. I mainly use vim for all my text editing work. I started with vi when I was a sysadmin of the first internet provider in Bolivia back in 1998.
Interesting post. I mainly use vim for all my text editing work. I started with vi when I was a sysadmin of the first internet provider in Bolivia back in 1998.
It was mainly dail-up accessed for homes. Banks and other companies had dedicated circuits at 32 or 64 Kbps symetric. Two years before that, we only had email service, you had to dial-in to an...
It was mainly dail-up accessed for homes.
Banks and other companies had dedicated circuits at 32 or 64 Kbps symetric.
Two years before that, we only had email service, you had to dial-in to an SMTP server which received all emails, and let you download yours via POP3.
Once a day, that company made a long distance call to U.S. to communicated with a relay email server, and exchange emails.
To better understand why and how Vim got (and is) so popular, it is best to look into the roots of how it all started. Before vim, there was vi, before vi there was ed. What are all these two or three letter words, and what is the story behind it? Let us dive in and figure out.
I really wish that people would stop saying this. You're really not that likely to need to ssh into some random system unless you're a system administrator of some sort - in which case you'll likely have permissions to install whatever editor you want. And even without that there are plenty of tools that allow you to locally edit remote files with the editor of your choice. You really are not going to find many times you are 'forced' to use vi.
In any case, I find it strangely relieving to see the reason why vi uses escape to return to command mode. That's easily my biggest gripe with vi, since it's so far away from everything else with most modern keyboards.
It's a lot more common than that for people beyond sysadmins, in my experience. Older systems without nice tooling where it's the only real way to debug a situation in production, contractors given access to certain boxes, going through jump servers and bastions, (usually smaller) organizations without completely siloed engineering and dba / ops departments, etc.
Even for sysadmins, it's rare that an organization will let arbitrary software of your preference be installed on their servers; usually it's either "this is the tooling we use across the organization" or "your personal preference doesn't justify the risk when we already have X".
Sure, but those situations are shrinking away with time. And like I said before you still can edit the files locally with whatever editor you prefer, so you still have no need to learn vi.
I wouldn't necessarily say that's true anymore. Even beyond the scenarios @DrStone mentioned, the rise of microcontroller, microcomputer and IoT devices, and the "maker" community's widespread use of them, has brought on a whole new wave of linux based products often only accessible via ssh. Though admittedly most of those devices don't usually force you to use vim (even though it's often still the most convenient)... so I guess your other point about not really needing to know it still stands. :P
I work in an embedded linux sector and nano is readily available on those machines as well if you want to avoid vi.
I have CAPS mapped to ESC on tap and CONTROL on hold. Works well for me.
That's a great idea! Would solve my big
vimgripe. Any chance you could share what software you're using to map keys based on time pressed?So the setup is very simple and you can find it here. It only took some trial and error—keymaps on Linux are not super intuitive IMHO.
The main script is
init_keys. Replace thebrwith your keyboard layout onsetxkbmap -option -layout br.Run
init_keyson startup either manually or automatically. On Linux I use i3wm, so I just call it from~/.config/i3/config(which i3 runs on startup).This sets my keyboard layout just to make sure (not really necessary, but useful to reload my settings when I'm messing with keymappings), sources
xmodmapchanges (you could do that on single file too, I just like it that way), killxcapeif it's running (again, useful when I'm messing with stuff, not required on first run), starts xcape and sets my keyboard repeat rate (I like it extra fast).reset_keysis useful for when you mess things up.Put them all in your
$PATH.Let me know if you want more details.
Thanks for the detailed explanation. Definitely going to try it out sometime soon.
Forgot to say, I think keycodes may different on your machine. I use
xbindkeys -kto find them.I appreciate the advice! Been away from Linux for a while and currently heading back, so reminders of things I've forgotten or not used much before are awesome.
Yes, xcape and xmodmap on Linux, Karabiner on macOS. I’m not sure if I have my Linux script on repo, I’ll check when I’m on the computer.
Same, but xcape been failing to autostart right sometimes.
Are you using xcape for this?
I can't live without this anymore.
I use xcape on Linux but I’m now stranded on MacOS so I’m using Karabiner.
I just had to do this last week. I had to connect to an EC2 instance and modify a file but nano wasn't installed. My next best guess was vim which worked. It's common enough I feel a pressure to learn the basics of it.
I've never felt the need to become more proficient in vi/vim (or even emacs). The extent to which i've ever had to use an editor on a remote machine was simple or infrequent enough that I've always been able to get by only with nano (or in many earlier unix years pico)...but i've never used/had access to (or even heard about) a unix or linux machine that lacked either nano or pico...so, this is quite an interesting anecdote! If this is a possibility (I've never used EC2 machiens from say AWS), then i guess i better brush up on at least vi, since that is supposed to be installed "everwhere".
My SO's job is to literally ssh into clients servers and debug her companies software, while it's pretty unusual these days to have no alternatives to vi(m) it's still by far the most likely to be on that system . As part of my job I submit long running jobs on a fairly locked down server, the server only has vi as an editor so if I want to do any scripting I'm using vi, sure I could email the sysadmins and request they give me nano or something, but they will also reply "learn vi".
You are the second person to ignore my point that you can use your local editors.
Listen, I get that you use vi and maybe even prefer it over other editors. There's no judgement here. I use vi from time to time as well. I'm just saying that "you might need to know it" is not really true any more. This does not affect how you choose to edit files.
Setting up local editors for remote editing is generally not easy either. Easier than learning all the ins and outs of vi, sure - but probably not easier than learning the few commands needed to make small changes.
I respectfully disagree. If you are using an editor with sftp built in, all you have to do is give it your credentials to access the server. If you are already using a dedicated sftp tool, chances are it has an edit option which will download the file to a temporary location and automatically upload it whenever it changes, which lets you use any arbitrary editor you want. And in either case, once you set it up it's done. There's no need to learn anything except where to get to the connection settings.
What other terminal text editor is better than Vim?
Kakoune
While Kakoune is interesting, I prefer neovim with vim-visual-multi. Personally I don't think Kakoune's editing model is that much of an improvement, here's a good writeup. vis is also really cool and I really like the structural regular expressions approach to multiple cursors, however it lacks vim/neovim's great ecosystem.
Can't really argue about it. I'm not deep into programming yet so maybe i will stumble with some issues in kakoune, but in the end i think everyone adapts to the tools they keep using.
I'm sure someone who've been using vim/neovim for years and have a very specific config and plugins will have problems with kakoune and vice-versa.
I keep kakoune plugin-free and i love the way it integrates with external tools, piping in and out, etc... I'll try to keep it that way, but i'll see what the future holds. For programming in Go for now it's been delightful.
It’s quite possible to outperform Vim and Emacs when it comes to the basics, the problem is competing with hundreds of external packages that grant astounding functionalities to the users.
Wow, I didn't realize Kakoune was a terminal text editor. That's so awesome!
Nano?
I can't say that I've done a lot of in-line text editing, but I got to grips with nano fairly easily.
I can't believe I forgot about Nano when I asked that question.
I really dislike Nano, but I can't really pinpoint why.
It's ok for simple tasks, but if you are programming or doing a lot of complex editing it lacks a lot of features.
I wasn't suggesting better alternatives, merely that vi is not a requirement.
Interesting post. I mainly use vim for all my text editing work. I started with vi when I was a sysadmin of the first internet provider in Bolivia back in 1998.
How was the internet in Bolivia, 1998?
It was mainly dail-up accessed for homes.
Banks and other companies had dedicated circuits at 32 or 64 Kbps symetric.
Two years before that, we only had email service, you had to dial-in to an SMTP server which received all emails, and let you download yours via POP3.
Once a day, that company made a long distance call to U.S. to communicated with a relay email server, and exchange emails.
Considering the article topic, I think we should make sure to avoid the classic mistake and FIRST read up on how we get out before we dive in.
That was really great!
Of course it's great,
edis the standard text editor.