! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Terminal gets confused when editing history with line breaks involved
Status:
RESOLVED: MOVED
Product:
Xfce4-terminal
Component:
General

Comments

Description Clemens Eisserer 2014-07-19 07:50:03 CEST
I often use the history-feature of Terminal (or bash), where I can navigate to previous commands using the arrow keys.
Often this is quite helpful when the previous command was somehow wrong, and you just wand to correct this small error, instead of re-writing the whole command again.

However when line-breaks are involved, I quite often experience that Terminal gets confused. Once I've edited a command in the history-buffer and press the enter-key, the command executed does not equal the command I was shown on screen while editing it.

I'll try to find illustrative examples and ways to reproduce this issue.
Comment 1 Clem Taylor 2014-10-29 05:48:30 CET
I see this problem far too often, you hit the up arrow on a command that spans more then 1 line, move into the line to edit and press return. The command that you saw and edit does not match the command that is edited. The insertion point the terminal shows is not the same as the insertion point the tty sees. I haven't been able to figure out what the trigger is.

It is not something like utf-8 handling, it happens when editing strings with only 7-bit characters. Issuing a refresh with 'ctrl-l' will repaint the line and the repaint will be correct, but the only way to know there was a problem is to execute the command and have it do something wrong.

In my opinion this is a *very* serious bug, because it could easily result in something nasty (think editing a command with 'rm -rf').

I think there are a number of refresh/repaint related bugs in xfce4-terminal, I have noticed when splitting the screen in vile or vim that sometimes the screen will not repaint correctly, a ctrl-l is needed to recover. I don't ever recall having issues with this with xterm, gnome-terminal or xwsh.
Comment 2 Egmont Koblinger 2015-03-01 15:03:49 CET
I don't think it's a bug with Vte-2 (the one current xfce4-terminal uses), and I'm quite certain there's no such bug in Vte-3 (to which xfce should upgrade).

The issue usually boild down to one of these:

- The previous command's output didn't end with newline. Either get used to pressing an Enter, or see a workaround here: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1419339

- Your bash prompt contains unprintable characters (e.g. ANSI color escape sequences) but you forgot to enclose them between \[ and \], as bash documents that it requires so that it can keep track of the cursor position.
Comment 3 Git Bot editbugs 2020-05-24 23:40:49 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/6.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #11032

Reported by:
Clemens Eisserer
Reported on: 2014-07-19
Last modified on: 2020-05-24

People

Assignee:
Nick Schermer
CC List:
3 users

Version

Version:
unspecified

Attachments

Additional information