bug-bash
[Top][All Lists]
Advanced

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

Readline-5.2 Official Patch 6


From: Chet Ramey
Subject: Readline-5.2 Official Patch 6
Date: Fri, 24 Aug 2007 15:40:01 -0400

                           READLINE PATCH REPORT
                           =====================

Readline-Release: 5.2
Patch-ID: readline52-006

Bug-Reported-by:        Peter Volkov <torre_cremata@mail.ru>
Bug-Reference-ID:       <1178376645.9063.25.camel@localhost>
Bug-Reference-URL:      http://bugs.gentoo.org/177095

Bug-Description:

The readline display code miscalculated the screen position when performing
a redisplay in which the new text occupies more screen space that the old,
but takes fewer bytes to do so (e.g., when replacing a shorter string
containing multibyte characters with a longer one containing only ASCII).

Patch:

*** ../readline-5.2/display.c   Thu Apr 26 11:38:22 2007
--- display.c   Thu Jul 12 23:10:10 2007
***************
*** 1519,1527 ****
        /* Non-zero if we're increasing the number of lines. */
        int gl = current_line >= _rl_vis_botlin && inv_botlin > _rl_vis_botlin;
        /* Sometimes it is cheaper to print the characters rather than
         use the terminal's capabilities.  If we're growing the number
         of lines, make sure we actually cause the new line to wrap
         around on auto-wrapping terminals. */
!       if (_rl_terminal_can_insert && ((2 * col_temp) >= col_lendiff || 
_rl_term_IC) && (!_rl_term_autowrap || !gl))
        {
          /* If lendiff > prompt_visible_length and _rl_last_c_pos == 0 and
--- 1568,1596 ----
        /* Non-zero if we're increasing the number of lines. */
        int gl = current_line >= _rl_vis_botlin && inv_botlin > _rl_vis_botlin;
+       /* If col_lendiff is > 0, implying that the new string takes up more
+        screen real estate than the old, but lendiff is < 0, meaning that it
+        takes fewer bytes, we need to just output the characters starting
+        from the first difference.  These will overwrite what is on the
+        display, so there's no reason to do a smart update.  This can really
+        only happen in a multibyte environment. */
+       if (lendiff < 0)
+       {
+         _rl_output_some_chars (nfd, temp);
+         _rl_last_c_pos += _rl_col_width (nfd, 0, temp);
+         /* If nfd begins before any invisible characters in the prompt,
+            adjust _rl_last_c_pos to account for wrap_offset and set
+            cpos_adjusted to let the caller know. */
+         if (current_line == 0 && wrap_offset && ((nfd - new) <= 
prompt_last_invisible))
+           {
+             _rl_last_c_pos -= wrap_offset;
+             cpos_adjusted = 1;
+           }
+         return;
+       }
        /* Sometimes it is cheaper to print the characters rather than
         use the terminal's capabilities.  If we're growing the number
         of lines, make sure we actually cause the new line to wrap
         around on auto-wrapping terminals. */
!       else if (_rl_terminal_can_insert && ((2 * col_temp) >= col_lendiff || 
_rl_term_IC) && (!_rl_term_autowrap || !gl))
        {
          /* If lendiff > prompt_visible_length and _rl_last_c_pos == 0 and

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/




reply via email to

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