After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580297 - gnome-terminal utf-8 characters issue
gnome-terminal utf-8 characters issue
Status: RESOLVED NOTGNOME
Product: vte
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-26 14:43 UTC by rom
Modified: 2009-04-26 15:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description rom 2009-04-26 14:43:18 UTC
Please describe the problem:


gnome-terminal count bytes instead of chars in prompt for handling the need of new line.

For example, I created a folder "~/Vidéos/ééé".

the char 'é' takes 2 bytes in UTF-8.

When I write something, no problem :
rom@rom-laptop:~/Vidéos/ééé$ echo abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst
uvwxyz

The problem appears when pressing ↑ (up) in the terminal to write again the same command, and editing it : everything is shifted of 4 chars, cursor is not at the right place, and what appears in the command is not the command executed (see attached screenshot).

Steps to reproduce:
1. create a folder with 2-bytes (or more) characters ('é' for example)
2. go into that folder with cd
3. write an echo of more than 1 line, and enter
4. press ↑ (up) to rewrite the echo, and try to edit it : everything is shifted and unusable

Actual results:


Expected results:


Does this happen every time?
yes

Other information:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/367369
Comment 1 Christian Persch 2009-04-26 14:52:01 UTC
This is not a gnome-terminal, or vte bug. If anything, the fault is in the readline library.
Comment 2 Behdad Esfahbod 2009-04-26 15:08:31 UTC
Yep.  bash/readline issues.
Comment 3 rom 2009-04-26 15:35:41 UTC
OK, thank you, I changed in launchpad.

Why doesn't it work like on macos (I just saw it once) :
All new lines are just added on view, not in "model" : when you resize the window, the "false" new lines are recomputed.

While in terminal here, if I resize horizontally after having executed ls command, the result is not "reformatted" : 
rom@rom-desktop:/tmp$ ls
keyring-rjq6qv  pulse-rom
orbit-rom       seahorse-UXMXvE
orbit-root      virtual-rom.UaIlWx

it would be better like this (like on macos) :
rom@rom-desktop:/tmp$ ls
keyring-rjq6qv  orbit-root  seahorse-UXMXvE
orbit-rom       pulse-rom   virtual-rom.UaIlWx
Comment 4 Behdad Esfahbod 2009-04-26 15:43:59 UTC
(In reply to comment #3)
> OK, thank you, I changed in launchpad.
> 
> Why doesn't it work like on macos (I just saw it once) :
> All new lines are just added on view, not in "model" : when you resize the
> window, the "false" new lines are recomputed.

That's a totally different thing.  vte does whatever the incoming stream of bytes tells it to do.

> While in terminal here, if I resize horizontally after having executed ls
> command, the result is not "reformatted" : 
> rom@rom-desktop:/tmp$ ls
> keyring-rjq6qv  pulse-rom
> orbit-rom       seahorse-UXMXvE
> orbit-root      virtual-rom.UaIlWx
> 
> it would be better like this (like on macos) :
> rom@rom-desktop:/tmp$ ls
> keyring-rjq6qv  orbit-root  seahorse-UXMXvE
> orbit-rom       pulse-rom   virtual-rom.UaIlWx

I know what you are talking about, but I highly doubt that it works like that in case of ls.