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.
Use readline for reading git commit messages
This way, you can use the arrow keys, etc. to edit input, and they work,
rather than outputting control sequences.
It seems this breaks the build. Investigating.
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.
read -e -p 'Git comment: '
I will put something together along the lines of what you suggested that uses the read/vared prompt argument.
Only attempt using readline for input in bash shells
ksh does not support readline with read.
zsh supports readline with varedit, but its input cannot be fed with a
pipe, which causes the test suite to hang, waiting on the tty's stdin.
On line 115 below (originally 105),
I noticed you provide an empty default here. Is this not equivalent?
If there is some nuance I am unaware of, I should also change this line to match that style.
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"
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.
'Git commit: '
sure, let me take a look.
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:
if [ -z "$comment" ]; then
git commit -m "... $comment"
I like that. I'll make the change.
Refactor prompt_cmd() into prompt() to avoid eval
The prompt must be displayed on stderr, or else it will become part of the result,
since stdout is used to pass the result back to the caller of _prompt().
How does this look?
Also, what ksh failures were you referring to?
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!