Use readline for reading git commit messages

[nilbus]

This way, you can use the arrow keys, etc. to edit input, and they work, rather than outputting control sequences.

I believe this is the only instance of reading user input where readline is useful.

[nilbus]

It seems this breaks the build. Investigating.

[nilbus]

That gets close, and I like how you use vared for zsh. The tricky thing though is that read -e in bash acts as if input starts at the beginning of the line, which is why read needs to provide the prompt: read -e -p 'Git comment: '. zsh's vared does the same thing but actually clears the line, so the echo statement actually has no effect.

I will put something together along the lines of what you suggested that uses the read/vared prompt argument.

[erichs]

excellent, thanks!

[nilbus]

On line 115 below (originally 105),

typeset comment="${4:-}"

I noticed you provide an empty default here. Is this not equivalent?

typeset comment="$4"

If there is some nuance I am unaware of, I should also change this line to match that style.

[erichs]

usually, the empty defaults are for explicit non-zero checks later in the code. I don't see that here, so it is either old code, or I changed my mind about the calling semantics and didn't change the variable declaration.

should be safe just to say "$1"

[nilbus]

The test suite hangs here in the zsh test run, which implies varedit does not accept input from stdin via the pipe. The manpage (man zshzle) does not suggest a way to allow this with varedit. Can you think of a different workaround to allow interactive editing for zsh? For now, I am letting zsh fall back to the previous read behavior.

Also, I could not get any combination of quoting and escaping that would pass 'Git commit: ' as a single argument without using eval as I did. Let me know if you are able to make this work a better way.

[erichs]

sure, let me take a look.

[erichs]

Hmm.. looks like there are local ksh test suite failures that are unrelated to this change. I'm going to fix those and commit to master.

perhaps, instead of a _prompt_cmd function, there should be a function whose goal is to do the appropriate thing and return a comment string. Maybe something like:

_add_composure_file(){
...

if [ -z "$comment" ]; then
  comment="$(_prompt_for_git_comment)"
fi

git commit -m "... $comment"
}

[nilbus]

I like that. I'll make the change.

[nilbus]

How does this look?

Also, what ksh failures were you referring to?

[erichs]

Looks good.

Ksh: I was seeing some transient test errors in ksh with the second _add_composure_file test. Not sure what was going on, and I haven't been able to reproduce the problem in a couple of days.

Onward and upward!