problem with combining characters in UTF-8

[kavol]

Hi.
I have noticed that some of my files are listed without diacritics in name while they do appear correctly in graphical file managers.
So far, it looks to me that qterminal (text console behaves differently, so I accuse qterminal) just eats the combining marks.
Trying e.g.
echo -e "\x63\xcc\x8c"
I get plain "c" while I should get "č" (i.e. "c" with caron).
I'm using version 0.7.1.

[yan12125]

So far, it looks to me that qterminal (text console behaves differently, so I accuse qterminal) just eats the combining marks.

Unfortunately, you're right. https://github.com/lxde/qtermwidget/blob/72ffc262eb6cd5deaf3489068f7fe6a91f734998/lib/Screen.cpp#L634 disposes it.

It's fixed in Konsole: KDE/konsole@c335324, https://bugs.kde.org/show_bug.cgi?id=96536

[kavol]

Thanks for the analysis ... so we're just one little step away from the patch and I can look forward for the fix soon, right? :-)

[yan12125]

That patch is not a little step :)

Actually, there's a plan to split Konsole into two parts and upstream QTermWidget changes instead of backporting patches one by one. (#320) I'll see whether it's easy to merge the patch into qtermwidget or not. If there are too many merge conflicts, I'll turn to #320.

[kavol]

okay, okay

BTW, I see that dependencies are discussed on the other ticket ... I won't participate in that, but just to give you some datapoint - user's POV:
I switched away from KDE some time ago for many reasons, and one of them that it became too bloated, despite all the component splits. One example being the hard dependency on running Baloo. And I really do not like the way LxQt is taking, depending on KDE components instead of plain Qt - for example, trying to install lxqt-meta on Gentoo pulls kscreen which pulls all the wayland nonsenses[*]. On Gentoo, I have the uncomfortable choice to avoid this, at least for now, but on Fedora, it just gets thrown on me. Well, I didn't quit using KDE just to have it back on my system this way ...

[*] Ok, some consider Wayland being step in the right direction but for me it is unusable, I work on multiple systems, I rely on X's network transparency all the time; Wayland just adds another software layer that eats my resources without any benefit, well, in fact with many cons, like no longer supporting the classic system tray, so breaking icons docking.

[jleclanche]

@kavol wayland is required as a library set by many things nowadays even on X11.

To address your comment, I was the main advocate behind keeping dependencies light (still am) and I personally suggested and approved the kscreen dependency; that was a few years ago now.

kscreen is light, a perfect example of a good KDE Framework lib. Last I checked, it doesn't hard depend on wayland (neither the server nor the libs), so maybe your packagers are being too aggressive.
These are qt libraries that are used by KDE; they're not pulling in all of KDE. Don't freak out just because you end up with more packages that start with the letter k.

LXQt is an organization lacking both manpower and users. Duplicating work only leads to more and longer-lasting bugs. QTermWidget is a perfect example of that: Its only user is QTerminal. If instead we used a part shared between Konsole and QTerminal, we wouldn't be in a situation with a super messy code, unsupported wide chars, rendering issues left and right etc.

As for wayland, it's always been the plan to move to it. The only reason it hasn't been done yet is because we don't have devs stepping up to work on it.

[yan12125]

Don't worry - I jumped to LXQt for exactly the same reason. I'm also getting sick of heavy desktops like Gnome or KDE. Before Konsole finds its way towards a lightweight framework (e.g., depending on only Qt and terminal-related libraries), I won't switch QTerminal to it. Fixing bugs and adding new features are important, while holding the philosophy is more important.

[egolep]

Is there any update on that? I'm switching to qterminal from kitty because I do not need all that features (read: bloat) from a terminal emulator, but at the same time complete unicode support is a very useful feature for me: I code a lot in Julia, where unicode is strongly supported and used, and the difference between, for example, y and ŷ could be huge (in machine learning, y is usually the target, while ŷ could be the values predicted from a model or even the predicting model itself).

[khumba]

I just want to note that this pretty significantly breaks rendering of Thai (and probably similar languages') text, which relies on combining characters all the time to indicate vowels, tone, and other things. A bit unfortunate given that LXQt has Thai localization (which I'm enjoying otherwise!).