GNU bug report logs - #11199
24.0.95; killing right-to-left text at eob leads to inconsistent state

Previous Next

Full log

Message #8 received at 11199 <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: 11199 <at> debbugs.gnu.org
Subject: Re: bug#11199: 24.0.95;
	killing right-to-left text at eob leads to inconsistent state
Date: Sun, 08 Apr 2012 10:33:28 +0300

> Date: Sun, 08 Apr 2012 11:26:41 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> 
> Steps to reproduce:
> 
> 1. emacs -Q
> 2. type the following text in the *scratch* buffer:
> 
>   (progn
>     (delete-region (point) (point-max))
>     (insert (substring (get-language-info "Hebrew" 'sample-text) 7)))
> 
> 3. move the cursor to the beginning of the next line of the above text.
> 4. C-x C-e
> 5. C-a
> 6. C-k
> 
> Result:
> 
> The Hebrew text is still shown, though it is internally killed.
> Typing C-p after the last step does not move the cursor.

I cannot reproduce this with today's bzr, neither in the emacs-24
release branch nor with the trunk version.  I cannot run a GUI session
with a GTK build on GNU/Linux where I'm typing this, but I tried GUI
and TTY sessions on MS-Windows and a TTY session on GNU/Linux, and
they all work correctly: the Hebrew text is killed and C-p works as
expected.  (Btw, did you mean C-p or C-n?)

Can you try reproducing this in a clean build, or on another system?

Also, what happens on the system where you see the problem, if you
switch to another buffer and then back to *scratch*, so that it is
completely redrawn? does the killed text re-appear or not?

Thanks.

Previous Next

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