Fortunately, GNU Readline offers a couple of constants to mark that a string
should be non-printing:
# readline.h
/* Definitions available for use by readline clients. */
#define RL_PROMPT_START_IGNORE '\001'
#define RL_PROMPT_END_IGNORE '\002'
Bash handles this issue by mapping \[' and ]' to RL_PROMPT_START_IGNORE and
RL_PROMPT_END_IGNORE inside of `PS*' prompt variables. It would be nice to offer
the same feature in IRB, or simply to surround all terminal escape sequences in
the IRB prompt with RL_PROMPT_*_IGNORE.
Note that this bug does not occur with libedit.
=end
At Mon, 26 Jul 2010 14:56:14 +0900,
Sung Pae wrote in [ruby-core:31484]:
Bash handles this issue by mapping \[' and ]' to RL_PROMPT_START_IGNORE and
RL_PROMPT_END_IGNORE inside of `PS*' prompt variables. It would be nice to offer
the same feature in IRB, or simply to surround all terminal escape sequences in
the IRB prompt with RL_PROMPT_*_IGNORE.
Even if it is implemented, you'll have to write as:
Even if it is implemented, you'll have to write as:
:PROMPT_I => "\\[\e[0;1;32m\\]>>> \\[\e[0m\\]"
It doesn't seem nice.
Yes, I agree. That is very ugly. I think it's appropriate to simply surround all
terminal escape sequences with the special RL values. Also, \001 and \002 do not
seem to affect libedit at all.
It is relatively simple to patch, so if the maintainer does not wish to bother,
I can supply a patch later in the week after my own deadlines are past.
At Tue, 27 Jul 2010 08:34:08 +0900,
Sung Pae wrote in [ruby-core:31509]:
Yes, I agree. That is very ugly. I think it's appropriate to simply surround all
terminal escape sequences with the special RL values. Also, \001 and \002 do not
seem to affect libedit at all.
OK. I'll yield this ticket to the maintainer of ext/readline.
diff --git a/ext/readline/readline.c b/ext/readline/readline.c
index 3ecea94..9b154bc 100644
--- a/ext/readline/readline.c
+++ b/ext/readline/readline.c
@@ -43,10 +43,20 @@
static VALUE mReadline;
=begin
This issue was solved with changeset r30496.
Sung, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.