Unable to select \approx from LaTeX table

[arbitrary-dev]

When I type \approx<Space> nothing happens, selection window just closes without any "≈" being inserted in the text input.

[arbitrary-dev]

Other characters seems to work fine.

[McSinyx]

I cannot seem to reproduce, could you please check you're typeface for support for ≈?

[arbitrary-dev]

How can I check typeface support? When I copy-paste "≈", it's visible in input fields.

[McSinyx]

How can I check typeface support? When I copy-paste "≈", it's visible in input fields.

That means it is supported I think. Can you provide more information on versioning?

[arbitrary-dev]

Sorry, forgot…

ibus-1.5.20
ibus-table-1.9.18-r1
ibus-table-others-1.3.9

[mike-fabian]

I can type \approx and get ≈ without problems.

\approx has not been recently added to the latex.txt table source, it has always been there, since latex.txt was added by the very first commit in this repo here.

You ibus-table seems a bit old (I have ibus-table-1.9.25-1.fc31.noarch). What distribution are you using?

[mike-fabian]

When I type \approx<Space> nothing happens, selection window just closes without any "≈" being inserted in the text input.

Before the selection window closes, i.e. before you type the space, you see the ≈ in the selection window?

[arbitrary-dev]

Yes I do.

[arbitrary-dev]

What distribution are you using?

Gentoo

[mike-fabian]

Is there anything interesting in the log file whey you do this?:

~/.cache/ibus-table/debug.log

You can increase the debug level by editing:

/usr/libexec/ibus-engine-table (might be /usr/lib/ibus/ibus-engine-table on gentoo)

Edit this and set the debug level to 3:

# Set this variable to something > 0 to get more debug output.
# (Debug output may show up in the log file and/or in the lookup table):
# export IBUS_TABLE_DEBUG_LEVEL=1

[mike-fabian]

Does this still not work for you? I cannot reproduce the problem.

[arbitrary-dev]

Nope, still not working.

$ equery l ibus*
 * Searching for ibus* ...
[IP-] [  ] app-i18n/ibus-1.5.22:0
[IP-] [  ] app-i18n/ibus-table-1.12.1:0
[IP-] [  ] app-i18n/ibus-table-others-1.3.9:0

debug.log

[mike-fabian]

grepping in in your debug.log I find:

$ grep 'commit_string\|_do_process_key_event.*release=False' debug.log | head -n 11
2021-05-15 18:52:27,078 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=92 code=43 state=0x00000000 name='backslash' unicode='\' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:27,448 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=97 code=30 state=0x00000000 name='a' unicode='a' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:28,398 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=112 code=25 state=0x00000000 name='p' unicode='p' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:28,543 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=112 code=25 state=0x00000000 name='p' unicode='p' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:29,257 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=32 code=57 state=0x00000000 name='space' unicode=' ' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:29,258 table.py line 2851 commit_string DEBUG: phrase=≈
2021-05-15 18:52:30,156 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=92 code=43 state=0x00000000 name='backslash' unicode='\' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:33,091 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=112 code=25 state=0x00000000 name='p' unicode='p' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:33,327 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=105 code=23 state=0x00000000 name='i' unicode='i' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:33,664 table.py line 3529 _do_process_key_event DEBUG: KeyEvent object: val=32 code=57 state=0x00000000 name='space' unicode=' ' shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod5=False release=False
2021-05-15 18:52:33,664 table.py line 2851 commit_string DEBUG: phrase=π
$ 

i.e. you typed '\app ' and then '≈' was committed, then you typed '\pi' and 'π' was committed.

That looks perfectly fine.

There is clearly the line

2021-05-15 18:52:29,258 table.py line 2851 commit_string DEBUG: phrase=≈

showing the commit of '≈'.

If that doesn’t appear in your application then, I suspect some problem with your application.

In what program/application are you typing into?

[mike-fabian]

Did the 'π' appear correctly?

[arbitrary-dev]

It's application independent for me, reproduces in all the apps.

'π' appears correctly.

Here's how I initialize ibus, by the way:

export GTK_IM_MODULE=xim
export QT_IM_MODULE=xim
export XMODIFIERS=@im=ibus
ibus-daemon -drx

[mike-fabian]

The line

2021-05-15 18:52:29,258 table.py line 2851 commit_string DEBUG: phrase=≈

in your debug log clearly shows that the ≈ was committed, i.e. send to the application.

here is the commit_string() function:

https://github.com/mike-fabian/ibus-table/blob/master/engine/table.py#L2822

According to the debug.log, it was called with the argument phrase=≈. Then it clears the input and remembers phrase (which is important only for some Chinese input methods which may give a suggestion depending on the just committed phrase).

And the next thing is already:

super(TabEngine, self).commit_text(IBus.Text.new_from_string(phrase))

I.e. it calls the commit function of IBus with the argument phrase. If that doesn't make ≈ appear in your application, it cannot really have anything to do with ibus-table.

Could you try what happens when you use ibus-m17n or ibus-typing-booster to type the ≈ ?

ibus-typing-booster should be available on Gentoo as well.

This file should be available on Gentoo as well:

$ rpm -qf  /usr/share/m17n/math-latex.mim 
m17n-db-1.8.0-12.fc34.noarch

(On Fedora it is in the m17n-db package, probably it is in the same package on Gentoo).

If that file is there, ibus-typing-booster and ibus-m17n can use it.

In the setup tool of ibus-typing-booster you can add the t-math-latex input method, like this:

And move the t-math-latex input method to the top priority (There are also keybindings to change the priorities of the configured input methods, see the keybindings tab in the setup tool, next_input_method is ['Control+Up', 'Control+KP_Up'] by default).

To use t-math-latex with ibus-m17n you need to add the m17n:t:math-latex - math-latex (m17n) input method either in the Gnome control center or with ibus-setup if you don't use Gnome.

Can you try whether you have the same problem that "≈" disappears on commit when using ibus-m17n or ibus-typing-booster?

[mike-fabian]

🏓 Ping

[mike-fabian]

I am closing this because there was no answer and I cannot reproduce this. You can reopen if you can add more information or give a procedure to reproduce the problem.

[narpfel]

I’m affected by something similar to this. I’m using Arch, Gnome, ibus with --xim (which is apparently the default on Gnome?) and X11.

I can also see in the log file that ≈ is committed regardless of the application, however in most (?) applications, ≈ works fine. Firefox, Chromium, gnome-terminal, LibreOffice, and Qt Creator all work fine.

The only application I can reproduce this in is Alacritty.

There are a couple more symbols that don’t work in Alacritty: ≤ (\leq) ≥ (\geq) √ (\sqrt).

Using the compose key to input these symbols also does not work in Alacritty, but works in the other applications. Interestingly, after restarting ibus without the --xim option, it is possible to enter these symbols in Alacritty using compose, but then ibus-table no longer recognises \ as a start character inside of Alacritty (in other applications it works fine).

I tried m17n and typing-booster as suggested and both show the same behaviour as ibus-table. Most symbols work fine, but ≈ doesn’t.

I tried to narrow down the cause and so far I found that if I map ≈ onto a normal key, it works in Alacritty. Also, the minimal window example from the winit crate (which is used by Alacritty) shows the same behaviour:

```console $ cargo run --example=window | grep Received Finished dev [unoptimized + debuginfo] target(s) in 0.12s Running `target/debug/examples/window` WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('h') } WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('e') } WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('l') } WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('l') } WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('o') } WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('🙃') } WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('α') } WindowEvent { window_id: WindowId(X(WindowId(94371843))), event: ReceivedCharacter('≈') } ```

where 🙃 was entered via compose and α via ibus-table. ≈ is just ignored when entered via compose or ibus-table, but shows up when I use my remapped normal key.

It seems to me that this is probably not an issue in ibus-table-others, but rather a problem somewhere in the interaction between ibus and winit? Any suggestions to troubleshoot this further or a more appropriate place to report this?

---

Versions used:

• ibus: 1.5.25
• ibus-table: 1.15.0
• ibus-table-others: 1.3.12