Re: [dev] [dmenu] 4.9 segfault on input

From: Ivan Tham <pickfire_AT_riseup.net>
Date: Sun, 17 Feb 2019 21:35:45 +0800

On Sat, Feb 16, 2019 at 04:37:31PM +0100, Hiltjo Posthuma wrote:
>On Sat, Feb 16, 2019 at 11:08:40PM +0800, Ivan Tham wrote:
>> On Sat, Feb 16, 2019 at 12:12:31PM +0100, Hiltjo Posthuma wrote:
>> > On Sat, Feb 16, 2019 at 04:46:23PM +0800, Ivan Tham wrote:
>> > > On Fri, Feb 15, 2019 at 11:45:59PM -0800, Patrick Smith wrote:
>> > > > On Fri, Feb 15, 2019 at 11:33 AM Silvan Jegen <s.jegen_AT_gmail.com> wrote:
>> > > > > With the suggested patch applied, everything worked for me when using
>> > > > > IBus and in st we use a similar pattern to what this patch is proposing
>> > > > > (x.c:1007-1014). I am not sure why Patrick's IME (SCIM) is working in
>> > > > > st but not in dmenu with the patch applied...
>> > > >
>> > > > To be clear... the terminal I normally use is termite, not st. In
>> > > > termite, scim+anthy works fine for me. As a test, I just now did a git
>> > > > clone of st and built it. Result: scim+anthy does not work in st for
>> > > > me. It doesn't crash; it just doesn't do anything.
>> > > >
>> > > > If I were looking for a terminal program, I probably would not
>> > > > consider st because of this. But in a menu program such as dmenu, I
>> > > > don't care whether I can use non-ASCII characters or not.
>> > > >
>> > >
>> > > st was fixed with some patches for IME recently but I am surprised that
>> > > dmenu could be used with IME, the reason I stopped using surf because of
>> > > the reason not being able to search using dmenu for chinese text.
>> > >
>> > > By the way, Patrick. Why use anthy instead of mozc for japanese input? I
>> > > heard anthy is a dead project (from arch wiki).
>> > >
>> > Could you perhaps give feedback if IME works with dmenu correctly for you or
>> > any improvements?
>> >
>> > In my testing the input position is fixed and the dmenu window may overlap over
>> > this, however this can be changed in a setting in fcitx so might be a
>> > non-issue.
>> >
>> > _AT_patrick:
>> > In my testing scim and fcitx seems to work for me in st though (latest git).
>>
>> IME works correctly but the pre-edit area initial position is correct to
>> be right below the cursor, however it does not move to the latest
>> position after selecting the characters to be inserted. An improvement
>> is to hint the IME using a patch similar to the st patch to allow that.
>>
>> Should I send in a patch for that? For me, the pre-edit not following
>> the cursor is fine as my font is small and only few characters are
>> inserted so the gap is insignificant, not sure about others.
>>
>> I had also sent in another patch to allow switching to another input
>> method by key release passthrough to be processed by IME.
>>
>
>Thanks, I'll look look at it. However there was a (vague) report on IRC for
>this broke keyrelease input in some cases for st in commit
>e85b6b64660214121164ea97fb098eaa4935f7db .

Okay, I haven't seen any issues so far, what are the steps to reproduce?

>> By the way, what do you mean by changed in a setting in fcitx?
>>
>
>In some editors there is a setting to show the displayed input at a fixed
>position, so in my opinion this makes the patch to set the pre-edit area less
>relevant.

Yes but I don't think fixed pre-edit area are useful, that reduces focus
when editing, inserting CJK characters are unlike typing latin
characters, even though one can touch type but most of the time needs a
few page scroll to insert a rarely used character, especially when
inserting chinese characters as compared to japanese characters.
Received on Sun Feb 17 2019 - 14:35:45 CET