GNU bug report logs - #20410
24.5.50; cursor not updated after yank of non-ASCII string from the clipboard

Previous Next

Full log

Message #20 received at 20410 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 20410 <at> debbugs.gnu.org
Subject: Re: bug#20410: 24.5.50;
 cursor not updated after yank of non-ASCII string from the clipboard
Date: Sat, 25 Apr 2015 13:09:07 +0300

> Date: Sat, 25 Apr 2015 18:49:56 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: 20410 <at> debbugs.gnu.org
> 
> >> > What does "C-x =" report before and after step 5?
> >> 
> >> It says
> >> 
> >> Char: C-j (10, #o12, #xa) point=191 of 192 (99%) column=0
> >> 
> >> So, the cursor is actually moved internally, but display is not
> >> updated accordingly.
> 
> > You show only one result of "C-x =", so it's hard to interpret it,
> > especially since you didn't show what was displayed after the paste.
> 
> I thought it was clear from the screenshot attached in the first mail.

Since the issue is with incorrect display of cursor, I generally don't
believe my eyes, since the place where the cursor is drawn might not
be the place where Emacs thinks it is.

> > Does the cursor move to the correct place if you type C-l or invoke
> > redraw-display, after performing the recipe?
> 
> The cursor appears.  But the cursor at the old position is not
> cleared.  See the attached screenshot.

Thanks, this is important information.

> I could reproduce it without yank.
> 
> 1. Create a file named a.el with the following contents:
> 
>   (global-set-key "a" (string #x3042))	; HIRAGANA LETTER A
> 
> 2. $ emacs -Q -D -l a.el &
> 3. Type "a" to insert a Japanese character.
> 4. Type "C-p" to move the cursor upward.
> 
> Display is updated correctly until Step 3.  But Step 4 does not change
> the display from the previous one.

I succeeded in reproducing this, after changing the default fontset to
use a specific font for the u+3042 character.  Thanks, I will look
into this.

> As for expose events, I suspect the current matrices get corrupted,
> because the result of git bisect implies that it has something to do
> with adjustment of glyph matrices triggered by font loading.

Sounds plausible, thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.