| Summary: | Certain Encoding settings produce invalid results | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | Alexey A. Kiritchun <kaa> |
| Component: | general | Assignee: | Konsole Developer <konsole-devel> |
| Status: | RESOLVED REMIND | ||
| Severity: | normal | CC: | kde |
| Priority: | NOR | ||
| Version: | 1.6 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | crude attemt at fixing | ||
|
Description
Alexey A. Kiritchun
2006-02-26 19:41:44 UTC
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. |