A multi-purpose EDITOR variable | Hacker News Reader

A multi-purpose EDITOR variable

brettterpstra.com

69 pointszdw25 comments

To edit several files of one type in one call:

    #!/bin/bash
    case $1 in
        *_EDITMSG | *MERGE_MSG | *_TAGMSG) 
                        /usr/local/bin/vim      "$@" ;;
        *.md | *.txt)   /usr/local/bin/mmdc     "$@" ;;
        *)              /usr/local/bin/subl -w  "$@" ;;
    esac

Don't a lot of programs first check for program-specific EDITOR values? So if you want to change the one for git, set GIT_EDITOR? Seems a lot cleaner than trying to recognize the filename.

Use Emacs, then you don't need several not very good editors. /flamebait

I was just about to post the same thing (mentioning emacsclient though). Does that make me a troll? :-)

apparently, not.

Frankly I don't see the point with Vim either, or any other editor that is capable of some concept of modes. Why doesn't the author find sublime suitable for git commit messages?

I would guess it has something to do with Vim having a console version and Sublime not. Commit messages are so short he probably just wants it to pop up in his shell, rather than in another window.

With Emacs, you get a single not very good editor to rule them all! :P

says the Vim guy.

This is not a multi-purpose EDITOR variable.

This is using a dispatch script as $EDITOR.

Do people not often use "git commit -m" for commit messages? Curious as to the common level of need to launch the full editor.

Writing descriptive commit messages with multiple lines.

  $ commit -m 'This is 
  > my long
  > multi-line message'

Granted, if you really want to write a novel that gets inconvenient, but I try to keep commit message short and reference a story or bug id# for more details when necessary.

i know it was not your point, but pls use a blank line between title and body.

depends. for small commits, a one-liner suffices. For large commits, merge commits, etc., or for repos that require you to sign-off on the commit or whatnot, a one-liner followed by a blank line and then a nice paragraph or bullet-point list is necessary. "launching a full editor" is hardly a problem with emacsclient or vi[m]

The smaller the commit, the more likely that it needs a proper explanation of why it was made.

When you find a commit from two years ago that changes a constant from -1 to -2, and the commit message says "constant change", or "bugfix in floobers" you're left with no context.

If I'm not using some integrated VCS system (which currently happens quite often), it's still mostly the case that I just switched from an editor when I'm writing my CLI commit command. So the mental context switch to transfer back into an editor setting is pretty minimal. And with the editor running (or EDITOR being vi(m)/emacsclient), the startup is negligible, too. So since the time of CVS, and now with either SVN or git, I just don't care too make a difference between small or larger commit messages and completely ignore options of expressing my commit message on the shell, going to the editor all the time.

I found that this also encourages me to be a bit more specific about the reasons for the changes committed. A few lines don't really hurt.

On the other hand, it might be that my commit schedule might still be too influenced by the older VCS systems, and a more frequent git-ish approach would encourage a more in-line approach. But right now I think that my one or two additional lines help more than they hurt.

Even if you do you'll still need EDITOR for interactive rebase.

Please do not do this. Please.

Build up your commit with git add -p (which requires an editor), then git commit -v and check what you are committing again.

Great! Now, how do I get EDITOR (and PAGER, for that matter) on a remote system to refer to an editor on the system I'm sshing in from?

Take a look at bcvi if your preferred local editor is vim: http://sshmenu.sourceforge.net/articles/bcvi/

Your website font on Windows is just plain terrible looking.

Regardless of that... I love this!

Don't blame Windows for Chrome's terrible text rendering there. Firefox and IE don't mangle fonts the same way.

Does Chrome use a different rendering in Linux? It looks fine here and I don't really have issues with fonts. (Except Calibri, people need to stop using it. It looks bad as is, and it looks awful in Linux without a bunch of manual hacks)

Not sure about windows, but Chrome definitely renders differently between Mac and Linux-- which is why Google Drive Presentations are not cross-platform -- spacing between objects gets messed up when you switch.

Reply on news.ycombinator.com