Bug 117140 - Backspace recover deleted text
Summary: Backspace recover deleted text
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Canna   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-02-29 09:28 UTC by Nakai
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version: 3.7p1-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-17 11:27:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Nakai 2004-02-29 09:28:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115

Description of problem:
Backspace on Canna clients sometimes recover deleted text instead
of cut tail of the input.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start kinput2
2. Press 'b' 10 times.
3. Press backspace key 5 times.
4. Press 'b' 1 time.
5. Press backspace key 1 time.


Actual Results:  Recover deleted text.

Expected Results:  Delete 1 char at tail.

Additional info:

This bug happen on all Canna clients. kinput2-canna,
nvi-canna(RHL9), xemacs, im-canna(http://bonobo.gnome.gr.jp/~nakai).

Comment 1 Eido Inoue 2004-03-02 00:05:56 UTC
I can't seem to reproduce with with a stock RHEL 3 WS (Japanese
Install with all RHN updates). Maybe I don't understand your
instructions to reproduce. Using it's gnome-terminal, and typing the
sequence after an "echo" command, and pressing return (which commits
the pre-edit sequence), it seems output only five "ã£", which is what
I expected the pre-edit buffer to contain.



Comment 2 Akira TAGOH 2004-03-02 01:45:14 UTC
Hmm, I could reproduce this problem once, but it seems not always,
because I can't reproduce it right now.

Comment 3 Nakai 2004-03-02 06:28:43 UTC
OK, if I remove ~/.canna, it works correctly. So if Adrian had ~/.canna,
you would see the same problem. If user don't have ~/.canna, the
kinput2 candidate for 'shou' is 12 line, buf with ~/.canna, which
useradd generates, 24 line.

The default ~/.canna might have the problem.
I think Tagoh also changed it to use kana key binding, right?

Comment 4 Nakai 2004-03-02 06:29:29 UTC
(bhuang@redhat.com is still in QA contact...)

Comment 5 Akira TAGOH 2004-03-02 06:57:13 UTC
It seems to happen if you enable break-into-roman. and if .canna is
missing, it doesn't appear so that break-into-roman is disabled by
default.

Comment 6 Eido Inoue 2004-03-02 15:32:01 UTC
comment 3: Nakai, could you attach a sample .canna file to this bug so
other QA testers can easily reproduce? Thanks!

Comment 7 Akira TAGOH 2004-03-03 01:25:13 UTC
make sure your .canna file includes (setq break-into-roman t) to
reproduce this problem.

Comment 8 Nakai 2004-03-03 14:58:41 UTC
Sane guys would use /etc/skel/.canna for test instead of my copy.

Comment 9 Akira TAGOH 2004-03-17 11:27:30 UTC
Fixed in 3.7p1-5.


Note You need to log in before you can comment on or make changes to this bug.