Version: 1.6 (using KDE KDE 3.5.1) Installed from: Fedora RPMs OS: Linux Encoding submenu in Setting has a checked item, indicating currently assumed codepage of a session. However, when multiple tabs are open, this indication is wrong: the item that was manually selected last time is 'checked', not the actual encoding. Reproduce: - open konsole - select non-default encoding (for a more visible effect - UTF-16). type smth - the echo output is garbled (chineese glyphs for me) - open new tab - type smth - it's your default encoding, but settings->encoding has 'UTF-16' set. The nastier thing with this bug is that it's irritatingly hard to force the same non-default encoding to two subsequently open tabs: clicking on a checked menu item in Encoding has no effect, so you have to select any other encoding first, then the desired one.
On my system, this happens with Unicode iso-10646-ucs-2, ucs2 and utf16. The other encoding seems to work as is. Select the encoding you want; select Save as Default. When you restart Konsole, all new sessions will have the Encoding you saved.
The other encodings are 7-bit-safe, i.e. you can't see the implications of this bug unless you use non-Latin-1 chars (try creating a file with a single utf-8 encoded euro sign or a letter with diacritic, and then 'cat' it). This problem is worse for me for rather esoteric reason: here in Russia we have at least 3 more or less popular encodings for Cyrillic (koi8-r, windows-1251, UTF-8, and a couple of more exotic, like cp866), and I have to work remotely on systems that use all of them (utf-8 locally on Fedora 4, koi8-r historically the default Russian codepage on FreeBSD/Linux, and cp1251 in HTML code for $work because it's what Windows users have), so your advice does not suite me. By the way, this is introduced in 3.5 line - 3.4.3 had correct per-tab memory, at least in kde-redhat.sf.net builds I use.
My KDE 3.4.2 system produces the same invalid results. What you want is a 'duplicate tab' option, which Konsole doesn't have yet.
1) True, I just retested on an older system (3.4.3) - the bug is also present there. 2) Yes, such an option would be nice (but not really _that_ useful for me. A customizable shortlist of encodings, like the one gnome-terminal has, would be much nicer). But all that is not really relevant to the bug itself: incorrect behavior of Encoding submenu.
Created attachment 15250 [details] crude attemt at fixing Tired of waiting, I spent an evening setting up KDevelop environtment to work on Konsole, and glancing through the code. The result is this patch (against 3.5 branch). This patch seems to fix the problem, though I guess the root of it is somewhere else (i.e., new sessions should have encoding_no == 0, not '1 after last known').
This bug is really annoying and I keep waiting for a fix since so many versions of KDE- the selected default encoding is saved, but not applied. One has to choose another encoding and then the intended one (in my case, iso-8859-1 and iso-8859-15 do nearly the same thing, so I save one step, switching between those two every time I open a new terminal). Since KDE 3.5 or so, the encoding is also reset to the old/default one after a remote (ssh) connection is terminated, requiring me to step through this every time I resume working on my remote shell (mutt+screen). This is my No.1 annoyance with KDE (although gnome-terminal has the same problem).
KDE3 is no longer maintained. I'll leave this as REMIND in case anyone releases another KDE3 version. This works in KDE4.