Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday December 25 2016, @11:38PM   Printer-friendly
from the interview-was-done-via-emacs dept.

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:

  1. 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.
  2. 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. ...
  3. 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.
  4. 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.
  5. 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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by mtrycz on Monday December 26 2016, @11:38AM

    by mtrycz (60) on Monday December 26 2016, @11:38AM (#446038)

    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!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by TheRaven on Monday December 26 2016, @12:46PM

    by TheRaven (270) on Monday December 26 2016, @12:46PM (#446054) Journal
    How does revision control help in any way? We are using revision control (git for most things), but that's solving a completely orthogonal problem.
    --
    sudo mod me up
    • (Score: 2) by schad on Monday December 26 2016, @04:01PM

      by schad (2398) on Monday December 26 2016, @04:01PM (#446088)

      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

        by TheRaven (270) on Monday December 26 2016, @08:58PM (#446146) Journal
        Except that if you're doing your building and testing on another machine (i.e. the reason you need a network filesystem) then git is a terrible network filesystem, because you have to commit and push all of your changes just to build test them, then interactive rebase them locally to remove all of the trivial buggy commits, then force push the result so that you can push the next set. Meanwhile, with vim ssh'd to the server I can just hit save (three keystrokes).
        --
        sudo mod me up
  • (Score: 2) by VLM on Monday December 26 2016, @02:02PM

    by VLM (445) on Monday December 26 2016, @02:02PM (#446067)

    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.