SoylentNews is people
SoylentNews
Early developers were struggling. They loved the landmark text editor vi but needed something that was available on more than just Unix.
They needed something more tailored to programmers, something that supported syntax highlighting for various languages and remote editing via SSH. They needed to fine-tune their development environments with plugins to maximize their efficiency.
Dutch programmer Bram Moolenaar created his own solution and shared it for free, eventually asking only that users make a donation to a charity caring for children and families in Uganda.
...Proponents of Vim commonly point out the same features as reasons why they use the program:
- Light and portable: Commonly used as a command line interface, Vim can be launched with a terminal, run through a GUI, or used remotely through an SSH connection. Vim is widely used on Windows, Linux, and macOS.
- Highly customizable and full of plugins: As with so many other open-source platforms, users have run amok with creating custom configurations, features, and plugins. ...
- Modality and no mouse functionality: It seems frustrating, but your fingers never need to leave your keyboard. Maximize productivity and coding time by using keystrokes to switch among normal, insert, command line, and visual modes. Keys have different commands based on which mode you’re in.
- Registers: Think of these as multiple clipboards. You can store copied text and macros, which record keystrokes for playback, in different registers. Registers, which persist between uses of Vim, help you save time by executing certain text in a fraction of the time.
- Motions and text-objects: Arguably our team’s favorite facets of Vim, motions and text-objects serve as the verbs and adjectives of the Vim language, allowing you to write your code über-productively. Motions allow you to tack on an action to built-in commands, so you can, say, delete from the current cursor position until the next occurrence of a letter. Meanwhile, text-objects are used in the context of motions, allowing you to declare commands inside or around words, paragraphs, HTML tags, and even current function blocks.
This submission prepared using the Firefox vim plugin, Vimperator.
This discussion has been archived.
No new comments can be posted.
Vim Creator Bram Moolenaar Discusses Developing the Popular Text Editor, How He Uses It
|
Log In/Create an Account
| Top
| 52 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Anyone who considers protocol unimportant has never dealt with a cat.
-- R. Heinlein
(Score: 0) by Anonymous Coward on Monday December 26 2016, @12:25AM
... but it also sucks ass (figuratively speaking).
(Score: 1, Interesting) by Anonymous Coward on Monday December 26 2016, @01:22AM
I'd reply to you and tell you how wrong you are if only I could figure out how to exit this darned text editor.
^C - no... ^X - no... ESC - no... ESCESCESCESCESC - no... F1 - no... F2 - no... F3 - no... ...
(Score: 4, Informative) by coolgopher on Monday December 26 2016, @02:30AM
Open new terminal, then
killall -9 vim
Done!
I may have done this a time or two to weird editors that don't understand :q! or ZZ...
(Score: 3, Informative) by Techwolf on Monday December 26 2016, @06:33PM
Back when I started to play with Linux, there was this program that did a system check, one thing it did as part of this process was to dump you into this strange editor, you had to make any changes as needed. None was needed, but as the parent pointed out, I did literally tried all the above. I eventually discovered how to switch to another terminal, find the offending program and kill it. The result was a properly finished system scan.
Yes, I literally did hit the keys : and q to no avail like all the fucking docs said to do.
(Score: 2) by TheRaven on Monday December 26 2016, @11:19AM
I completely agree. The big problem with vim is that it's just about good enough. It's the LaTeX of the editor world: it mostly works and has a huge number of extensions built on top of it that are too hard to completely rewrite, which discourages anyone from creating something that's actually good. The killer feature for editors like vim and emacs is their ability to run over ssh in a tmux (or screen, if you're that way inclined) session, so you can editor remotely and not worry about network disconnections.
With YouCompleteMe, vim is a pretty reasonable code editor and lets me edit code directly on a big server. What I actually want is a nice IDE, a network filesystem that handles disconnections gracefully, a mechanism for invoking the build on the nice fast servers, and a way of tunnelling the gdbserver protocol over ssh so that the IDE can give me graphical debugging for a remote process, with minimal setup. What I actually have is ssh, tmux, vim, and lldb running on the server.
sudo mod me up
(Score: 2) by mtrycz on Monday December 26 2016, @11:38AM
Wouldn't you be using (any kind of) source/version control these days, instead of editing/recompiling on the server?
In capitalist America, ads view YOU!
(Score: 2) by TheRaven on Monday December 26 2016, @12:46PM
sudo mod me up
(Score: 2) by schad on Monday December 26 2016, @04:01PM
It's not completely crazy to think of git as a network filesystem with excellent disconnected-mode operation.
(Score: 2) by TheRaven on Monday December 26 2016, @08:58PM
sudo mod me up
(Score: 2) by VLM on Monday December 26 2016, @02:02PM
Lately I've been playing with a chromebook having 64 GB of memory and several TB of partially SSD database storage. Well, the chromebook is actually very weak and running VNC to a really big openstack image on a rack somewhere near the NAS racks.
Its pretty fast.
VNC means no weird font/UTF-8 problems, its exactly the way I want it no matter where I access it. Rdesktop is supposedly more secure than VNC but on an internal only LAN it doesn't matter and VNC is just so easy to set up and use whereas rdesktop server side was providing some interesting headaches.
The openstack "horizon" web interface gives you a console via VNC but I run in parallel because I need to keep horizon as an emergency backup if even ssh can't fix an image. If an image is unfixable in a couple minutes I just spin up a new one and let ansible do its thing and I'm back up in ten minutes or so anyway.
emacs on ssh can work but often is weird. My helm sessions want to go monochrome and not show my "bar" so I can't actually use helm prompts which is a little bit of a problem, I'm sure I could fix the color scheme but... I don't remember exactly how flycheck responded to text mode but I remember it wasn't good. vi is totally a text mode editor but emacs is pushing the boundary of unless you put in some work around aggravations it more or less eventually requires a graphical display.
Giving up on the whole "I can't work when the network is down" feels very freeing, like when you give up on 80 columns.
Something I like about developing and debugging on the same machine is there isn't much of a "bump" in mode switching. Some bugs simply require access to a prod system to verify and often for simpler bugs its not worth the effort to image a test system or its a production load or weird data input situation where I can't really replicate without cloning the userbase of the prod systems which isn't happening. You gotta be really careful while debugging on a prod system of course.