Comment 2 for bug 1419339

This is not a gnome-terminal bug, you'll see the same behavior in every terminal.

The problem is that there's no reliable way of querying where the cursor is, so bash assumes it's in the 1st column when it prints the prompt and edits the command line. If it's not there, screen corruption is bound to happen.

I recomment you to accept this and get used to pressing Enter if a command doesn't terminate with a newline -- or if it's one of your commands then alter it accordingly.

One trick I've seen is: from the beginning of the prompt (or maybe using the PROMPT_COMMAND variable) emit a widthful of spaces, followed by a carriage return (but no newine). If the cursor was in the 1st column then it will stay in the same line and this operation will basically have no effect (well, it will fill up the line with spaces which causes different behavior when copy-pasting; after the carriage return you might also output \e[K to remove them). If the cursor was anywhere else than in the first column then it overflows to the next line and then moves back the cursor to the beginning of the next line. So effectively this is a "print a newline unless the cursor is in the 1st column". (I've seen it in a variant where the first character printed is not a space but an inverse-colored % symbol, giving you an obvious clue that the final newline was not printed by the app.)