aboutsummaryrefslogtreecommitdiffstats
path: root/package/readline/readline52-006
blob: fbd06cb233732b0db63ee76bb63a1330f9900e05 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
			   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