I am using Eterm in E17. This bug could not be reproduced by developers, but they guided me to reproduce easily on my box. And i know how to fix it, to prevent future problems for comunity. E17 only supports UTF locales; Eterm only supports ISO. So, when Eterm is compiled under Gentoo with the unicode flag, and launched under E17 configured with UTF (some tricky options allow to use ISO under E), Eterm trigers several bugs at a time. as workaround, Eterm must be compiled whith those three options at : --disable-auto-encoding \ --disable-multi-charset \ --disable-xim \ I suggest to make them all 3 explicit when unicode flag is not passed. And also add an ewarn telling that unicode flag is discouraged.
Created attachment 177555 [details] My dirty ebuild My ebuild is dirty because it disables multibyte even when unicode flag is positive. It fixes my problem for sure :) But shows where to put features, and how it works for me. An upstream patch may fix this soon.
SVN has been fixed. A new release should come out soon. I forgot to mention two things in the first report: - having Eterm compiled with unicode flag, under a UTF window manager make Eterm very slow to start: around 7 seconds (with bash inside). - this bug is theoretically reproductible under any UTF enabled WM. Eterm created by my ebuild launches in less than 1s (around 0.9 to 0.8). Version in SVN can speed up, own to 0.65s whith the three features disabled, and, stays fast enough when all features are enabled: 0.85s.
eterm doesnt support unicode and i'm not about to disable random things in eterm to try and address the issue as for the slow startup issue, that's a bug in X, not Eterm ... see Bug 71747
(In reply to comment #3) > eterm doesnt support unicode and i'm not about to disable random things in > eterm to try and address the issue > > as for the slow startup issue, that's a bug in X, not Eterm ... see Bug 71747 > It is *NOT* an X issue: KainX admitted it, and he fixed the problem. SVN version 38477 does fix it. I could not log IRC messages, but the problem is that when UTF is enabled, Eterm waits for an event in /proc, goes sleepy, and is woken up by some timeout. The 3 options I mentionned are the one given by developpers (you usually say "upstream"): the clearly said that just disabling unicode is not enough, two more options are REQUIRED for a safe protection against UTF. That's why even when SVN.r-38477 will fix the issue when UTF is enabled, this will not be enough: problems still may happen when the user discards unicode, and puts USE="-unicode": some multibyte side effects can go through, and slow down Eterm uselessly. I am not asking you to believe me; I am asking you to believe KainX, the developper. It's not "random things", it's what the dev (upstream) told me to do, to test, that I tested, and that changed/fixed the issue. Especially Xim. After multibyte, Xim is the feature that have most impact on runtime. Auto-encoding is just a "security" (<<body guard>>). Fact you do not understand what they are here for does not mean they are random. It *can not* be an X issue, simply because my Xinitrc sets locale to ISO ! it's my WM (E17) that sets locale to UTF internally for applications, that make the problem happen. Dev understood pretty fast that X is not a problem at all. I personally even suspect that what *really* happen in Bug 71747 is not a X problem, but, as for Eterm, an "application specific bug", for all applications badly written by devs who dont care about UTF, and that X has nothing to do with this: with proper strace and ltrace, KainX could fix the problem in 10mn, and I am pretty sure that it could be the same for all applications ... for all bugs you think related with X in bug 71747. And may not be. See comment 7 ... exactly what happened to me. Dev and maint think the problem is due to X, when in fact, NOT ! The proof is that now KainX could and did fix Eterm in 10mn time ! I wont reopen; but please fix.
