On Wed, Jan 28, 2009 at 03:45:25PM +0100, Carsten Hey wrote:
> On Tue, Jan 27, 2009 at 10:22:53PM +0100, Martijn van Oosterhout wrote:
> > On Tue, Jan 27, 2009 at 09:26:31AM +0100, Carsten Hey wrote:
> > > When fixing this bug we should consider that one UTF-8 characters might
> > > need two columns to be displayed properly, e.g. some Chinese signs.
> > > wcwidth(3) and wcswidth(3) look good under this aspect to determine the
> > > display width of one wide character or one wide-character string.
> >
> > I don't think we need to go that far, glib has g_unichar_iswide() and
> > g_unichar_iszerowidth(). I think using that we can easily make a
> > fuction that does what we want.
>
> Yes, this sounds better than using wcswidth().
Correctly handling characters like リヒター シィモン (thanks Simon for
using such chars in one of your GPG uids, this makes copy and pasting
them easy) seems to be more complicated as I thought. I used pal -m to
add events which include such double wide characters and it leaded to
missing characters in the pal file. Since until now nobody using double
wide characters complained and is seems to be a lot of work, I'm not
sure if this is worth the effort. Maybe we should wait for a bug report
to be sure somebody needs this.
I got a fix for correctly handling "normal" UTF-8 characters. I'll
prepare a package including this fix and one for using default colors
(e.g. when running pal -m on a terminal with white background) after
Lenny has been released.
To detect whether the terminal supports colors using the following seems
to be more sane than checking $TERM, e.g. screen can be compiled without
color support and pal would falsely assume that it supports colors when
it is only checking the value of $TERM. I will not change color_term()
in colorize.c myself since I don't consider this to be a problem in
Debian and a very rare issue outside of Debian.
init_pair(3ncurses):
| The has_colors routine requires no arguments. It returns TRUE if
| the terminal can manipulate colors; otherwise, it returns FALSE. This
| routine facilitates writing terminal-independent programs. For
| example, a programmer can use it to decide whether to use color or
| some other video attribute.
|
| The can_change_color routine requires no arguments. It returns TRUE
| if the terminal supports colors and can change their definitions;
| other, it returns FALSE. This routine facilitates writing
| terminal-independent programs.
Regards
Carsten
diff --git a/src/rl.c b/src/rl.c
index 0c88517..7d9a61b 100644
--- a/src/rl.c
+++ b/src/rl.c
@@ -204,7 +204,7 @@ void pal_rl_ncurses_hack(void)
printw( "%s", rl_line_buffer + start );
/* Place cursor, taking into account marker */
- move(readline_y, readline_x + rl_point - start + (start > 0) );
+ move(readline_y, readline_x + g_utf8_strlen ( rl_line_buffer, -1 ) - start
+ (start > 0) );
refresh();
}
diff --git a/src/manage.c b/src/manage.c
index 96f05b3..98b8a6b 100644
--- a/src/manage.c
+++ b/src/manage.c
@@ -429,14 +429,15 @@ void pal_manage(void)
if(has_colors())
{
start_color();
- init_pair(COLOR_BLACK, COLOR_BLACK, COLOR_BLACK);
- init_pair(COLOR_GREEN, COLOR_GREEN, COLOR_BLACK);
- init_pair(COLOR_RED, COLOR_RED, COLOR_BLACK);
- init_pair(COLOR_CYAN, COLOR_CYAN, COLOR_BLACK);
- init_pair(COLOR_WHITE, COLOR_WHITE, COLOR_BLACK);
- init_pair(COLOR_MAGENTA, COLOR_MAGENTA, COLOR_BLACK);
- init_pair(COLOR_BLUE, COLOR_BLUE, COLOR_BLACK);
- init_pair(COLOR_YELLOW, COLOR_YELLOW, COLOR_BLACK);
+ use_default_colors();
+ init_pair(COLOR_BLACK, COLOR_BLACK, -1);
+ init_pair(COLOR_GREEN, COLOR_GREEN, -1);
+ init_pair(COLOR_RED, COLOR_RED, -1);
+ init_pair(COLOR_CYAN, COLOR_CYAN, -1);
+ init_pair(COLOR_WHITE, COLOR_WHITE, -1);
+ init_pair(COLOR_MAGENTA, COLOR_MAGENTA, -1);
+ init_pair(COLOR_BLUE, COLOR_BLUE, -1);
+ init_pair(COLOR_YELLOW, COLOR_YELLOW, -1);
}
else
set_colorize(-2);
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
