[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [screen-devel] compounding trailing whitespace when using utf8 in ha

From: Sadrul Habib Chowdhury
Subject: Re: [screen-devel] compounding trailing whitespace when using utf8 in hardstatus/caption
Date: Thu, 20 Jan 2011 12:49:18 -0500

On Fri, Jan 14, 2011 at 2:00 PM, Dustin Kirkland <address@hidden> wrote:
> Hi,
> I'm quite interested commit 28c161010579e59ae5d310db277f8978911ac794,
> which fixes the display of multibyte unicode characters in the caption
> and hardstatus lines.
> I can confirm that, in fact, that commit does display utf8 characters,
> such as "☮" correctly.  Thanks!
> However, it does introduce a new bug, though.  It seems that the
> padding introduced by %=, though isn't quite handled correctly.
> You can easily test it like this:
> /tmp/screenrc:
> hardstatus alwayslastline
> hardstatus string '☮%c%=%c'
> Then, building the latest screen from git:
> ./screen -c /tmp/screenrc
> The last line will look like this:
> "☮12:56
>         12:56  "
> Note the two trailing whitespace characters after the final %c (time)
> display.  This will scale linearly with the number of utf8 characters
> you put in your hardstatus.  That is, if I put 4 x ☮, there will be 8
> trailing whitespaces.
> It seems to me that there is some accounting missing somewhere, among
> the various places that string-length is calculated, which might
> involve multi-byte characters.
> I've spent a few hours fiddling with the code, as has my colleague on
> CC, Kees Cook.  He's come up with the attached patch, but it's not
> quite there yet.  Can anyone here give us a few pointers to nudge us
> along?

I would make some change screen.c:pad_expand, for example:

diff --git a/src/screen.c b/src/screen.c
index 3dde3b4..1672af9 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -2239,7 +2239,11 @@ int padlen;
   char *pn, *pn2;
   int i, r;

+#ifdef UTF8
+  padlen = padlen - strlen_onscreen(buf, p);
   padlen = padlen - (p - buf); /* space for rent */
   if (padlen < 0)
     padlen = 0;
   pn2 = pn = p + padlen;

This fixes the amount of padding for me. However, it's still buggy,
because I lose the last two digits (the minute part) of the last %c.
Perhaps you guys would be willing to take a look at that? :-) If not,
I hope I will get to it ... apologies for the delay in reviewing the
patch and general lack of activity, but new job/location etc. eat up a
lot of time :-( .. Things should improve in a couple of weeks, I
think, though!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]