Bug#782043: yafc: Colored prompt doesn't work

[Sebastian Ramacher]

Control: reassign -1 libedit2 3.1-20140620-2

On 2015-04-07 11:45:59, Sebastian Ramacher wrote:
> On 2015-04-06 22:57:37, Celelibi wrote:
> > Package: yafc
> > Version: 1.3.5-2
> > Severity: minor
> > 
> > Hello,
> > 
> > Here are my prompt strings defined in .yafc/yafcrc:
> > prompt2 "yafc %{\e[33;37;1m%}%h%{\e[0m\e[33;33;1m%}%#%{\e[0m%} "
> > prompt3 "yafc %{\e[33;34;1m%}%u%{\e[0m\e[33;33;1m%}@%{\e[0m\e[33;37;1m%}%h%{\e[0m%} %{\e[33;32;1m%}%42~%{\e[0m\e[33;33;1m%}%#%{\e[0m%} "
> > 
> > The \e seems to be ignored by yafc, here is the result:
> > yafc [33;34;1muser[0m[33;33;1m@[0m[33;37;1mhosname[0m [33;32;1m/path[0m[33;33;1m$[0m 
> 
> This looks like a regression from libedit:
> 
> libedit (3.1-20140620-2) unstable; urgency=medium
> 
>   * Upload in unstable with the UTF-8 changes.
>     In theory, this should be painless because it just adds new symbols.
> 
> It works fine with -1.

Yes, it's a libedit regression. The following minimal example produces a green
colored "cmd> " with 3.1-20140620-1, but prints "[1;32mcmd>[0m " with
3.1-20140620-2.

$ cat test.c
#include <editline/readline.h>

int main()
{
  readline("\001\033[1;32m\002cmd>\001\033[0m\002 ");
}


Cheers
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-llvm-team/attachments/20150407/a1002863/attachment.sig>