Hacker News Reader

Comment by simias | Hacker News Reader

Thank you for that tip, that would've saved me some annoying copy/pasting in the past!

I'd just C-x C-e and open the command line buffer in an editor to work on it there.

This isn't enabled by default. You have to configure zsh with some optional features. I found this on Stack Overflow:

    autoload -z edit-command-line
    zle -N edit-command-line
    bindkey "^X^E" edit-command-line

[1] https://unix.stackexchange.com/questions/6620/how-to-edit-co...

> This isn't enabled by default.

It is in Bash.

Oh man nice tip. I've been using bash for 30 years and never noticed that binding.

    "\C-x\C-e": edit-and-execute-command

That's right. If anyone wants to check their bindings, use:

    bind -p

    bind -P

For example:

    $ bind -P |grep execute
    edit-and-execute-command can be found on "\C-x\C-e".
    $

The "bind" shell built-in is detailed in the SHELL BUILTIN COMMANDS section of the "bash" manual.

C-x C-e doesn't do anything in my configuration but beyond that I find that editing long freeform text on the command line gets annoying fast if only because of the careful escaping you have to do, especially for nested quotes.

In zsh (and bash I think) it opens the entire line in a buffer, making it easy to edit it in ways which wouldn't really work well at the shell.

> beyond that I find that editing long freeform text on the command line gets annoying fast if only because of the careful escaping you have to do, especially for nested quotes.

Oh I agree. Here I'd suggest it for the rare case where I was expecting to write a simple commit message and end up needing a much longer one, though usually I'd just create the commit and immediately "amend" into a proper text editor (and most of the time I use a text editor directly, because rare are the commits where the short desc is sufficient).

Sure, but how would you format your message so the lines aren't longer than 80 chars? I guess you can edit the command to read from STDIN, but that sounds much more cumbersome than passing -e:

    git commit -F- <<EOF
    Fix issue

    Hello world...
    EOF

> Sure, but how would you format your message so the lines aren't longer than 80 chars?

Put linebreaks and fill-paragraph for the later lines? You can put linebreaks in quoted shell strings, so once it's in an editor buffer there's no issue with that.

> I guess you can edit the command to read from STDIN

The use case here is "I've already started writing a commit message inline, I now realise I need more room, I don't want to bother copy/pasting stuff around".

If I know from the start that I will need more than just a shortdesc, I'll obviously be crafting the message in my editor in the first place.

Maybe something like

  fold -c -s -w 80 | git commit -F - <<EOF
  Fix issue

  Hello world...
  EOF

I typically just do the commit, then afterwards use `git commit --amend` to open the previous commit message in $EDITOR for updating.

Reply on news.ycombinator.com