--- Begin Message ---
|
Subject: |
24.5.50; cursor not updated after yank of non-ASCII string from the clipboard |
|
Date: |
Thu, 23 Apr 2015 18:59:45 +0900 |
|
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
Steps to reproduce:
1. Copy some non-ASCII string (say, "あ") to the clipboard.
2. $ emacs -Q -D &
3. C-x C-b
4. C-y
5. C-p
Expected Result:
The cursor moves upward by Step 5.
Actual Result:
The display is not changed between Step 4 and 5.
Moreover, if you make the Emacs frame expose by obscuring and
revealing it with another window after you turn off your X11
compositing manager, then you'll see the parts other than the upper
mode-line and the echo area are not redrawn (see the attachment).
YAMAMOTO Mitsuharu
address@hidden
In GNU Emacs 24.5.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.4)
of 2015-04-23 on localhost.localdomain
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
System Description: CentOS release 5.11 (Final)
Important settings:
value of $LANG: ja_JP.UTF-8
value of $XMODIFIERS: @im=SCIM
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#20410: 24.5.50; cursor not updated after yank of non-ASCII string from the clipboard |
|
Date: |
Mon, 27 Apr 2015 18:17:39 +0300 |
> Date: Mon, 27 Apr 2015 12:28:58 +0900
> From: YAMAMOTO Mitsuharu <address@hidden>
> Cc: address@hidden
>
> >>>>> On Sun, 26 Apr 2015 18:04:56 +0300, Eli Zaretskii <address@hidden> said:
>
> >> Yes, it solves the problems as far as I tested. But because
> >> adjust_frame_glyphs are called from many places other than font
> >> changes, I wonder if it might disable some cases where some
> >> optimizations were applied successfully otherwise (sorry, I don't have
> >> any ideas about concrete examples). Some calls to adjust_frame_glyphs
> >> are already accompanied by SET_FRAME_GARBAGED, but not always.
>
> > Hmm... you are right, we could be more selective. Does the
> > alternative patch below work for you?
>
> Yes, this works fine. Thanks a lot.
>
> The previous one (for src/dispnew.c) caused redraw on another window
> on the same frame when I scrolled one window using set-window-vscroll,
> which may call adjust_frame_glyphs. But the current one (for
> src/xdisp.c) doesn't have such a problem.
Thanks, pushed as commit d89687b.
--- End Message ---