Typing a character not in `VALID_INPUT_CHARS` commits current candidate

[Socob]

This is more of a question, but since there doesn’t seem to be any documentation (see #25), I can’t really say whether this is a bug, a feature request or me not being able to figure out the settings.

(I previously asked this on AskUbuntu, and it was suggested there that I open an issue here on GitHub.)

I’m using ibus-table-latex and would like to disable the following behavior: When I start typing something that triggers the candidate list (i. e. starting with one of the START_CHARS, for example: any part of \rightarrow, such as \rightarr), the candidate list opens and the best-matching candidate is already “pre-selected” for insertion. See the following screenshot:

My problem is that even when I press a key that’s not in VALID_INPUT_CHARS, such as % or !, this pre-selected top candidate is inserted instead of what I typed. So, for example, typing \rightarr! results in →!, but what I want is for the text to appear exactly as entered in this case.

I’ve tried a few different options:

• I’ve noticed that pressing Enter does something similar to what I want (not sure where this comes from; it’s nowhere on the key bindings tab in the preferences): It preserves the text typed in so far and closes the candidate list. However, I don’t want to have to press a special key to do this.
• The “commit to preedit” key binding (default: Shift) is somewhat similar, but instead of using the characters entered so far, it “auto-completes” the text for the current candidate, but without replacing it with the corresponding symbol. It doesn’t look like this could work for what I want.
• The “cancel” key binding (default: Esc) doesn’t select the candidate, but gets rid of the entered text entirely, so that’s not helpful.
• The “commit” key binding (default: Space) just uses the top candidate immediately.

Another potentially relevant thing I’ve found is the “Auto select” setting in the preferences:

However, this is set to “No”, so I don’t think this is causing my problem.

[mike-fabian]

Like most Chinese input methods, ibus-table also commits the exact characters typed ignoring any candidates or whatever is displayed in the preedit when Return is typed, Almost all Chinese input methods work like this, Space commits a candidate and Return commits the keys which were actually typed.

So when you type \rightarr + Return, then \rightarr is commited. then you could type the !.

I think this is the easiest way to get what you want, first commit the exact typed text with Return, then type the extra character like !.

I also think that “commit to preedit” is not useful for you. “commit to preedit” is only useful for a few Chinese tables like Wubi where you can keep adding Chinese characters to the preedit and when you finally commit you get a new shortcut for that Chinese character string automatically defined. It only really useful for these special Chinese tables.

The “Auto select” option has a very weird and complicated behaviour which I documented in the tooltip after I had “reverse engineered” what it actually does. It is not generally useful except for the Russian “translit” (and a few similar, mostly Russian) tables. Just ignore that one.

Is it OK for you to type \rightarr + Return + !?

Does that answer your question?

[Socob]

@mike-fabian Thanks a lot for the explanation; that definitely clears up some things!

I guess I kind of figured out the part about pressing Return myself already. If possible, I’d really like to avoid having to do that, but it sounds like there’s no way to avoid it?

(My original example is a bit artificial in order to simplify the explanation, so perhaps to give a bit more context: I’m essentially trying to use ibus-table-latex to type “normally”, except for binding a specific key – preferably Tab – to turn LaTeX syntax like \rightarrow into Unicode. But this should really be “on demand” only, i. e. no substitutions should happen during normal typing. This would re-binding “commit” from Space to Tab, but that’s possible in the settings. Something that behaves similar to this is the Julia REPL, for example. What’s really throwing a wrench into things for this purpose is this “auto-commit” behavior.)

If there’s no way to do this at the moment, I’d like to have a go at implementing it myself! I suppose the place to look would be in the code for ibus-table, correct?

[Socob]

Oh, another thing: In the key bindings, I’ve found toggle_autocommit_mode (default: Ctrl+/), but I haven’t been able to figure out what that does. Does that have anything to do with what I’m trying here?

[mike-fabian]

Oh, another thing: In the key bindings, I’ve found toggle_autocommit_mode (default: Ctrl+/), but I haven’t been able to figure out what that does. Does that have anything to do with what I’m trying here?

No, not at all. This is another obscure option For most tables it makes no sense for the user to change it, therefore it is hidden from the setup tool for most tables.

Here you see a screenshot showing the ibus-table setup for the Chinese input method wubi-jidian86 and for latex:

You see that the option is visible in wubi-jidian86 but not in latex. That is because changing it is useless for latex.

If you want to try it nevertheless for latex, you can set it on the command line, the default for the latex table is "false":

dconf write /org/freedesktop/ibus/engine/table/latex/autocommit "false"

But you can set it to "true" if you want and see what happens:

dconf write /org/freedesktop/ibus/engine/table/latex/autocommit "false"

It has no influence on the behaviour you want.

Nothing interesting happens for the latex table when this option is changed, therefore this option is hidden in the setup tool.

[Socob]

OK, I see – thanks again. I haven’t been able to notice any difference with this set to true or false, so as you say it doesn’t seem relevant here (although I still don’t know what it’s actually supposed to do).

Not sure if you saw the first comment (https://github.com/moebiuscurve/ibus-table-others/issues/26#issuecomment-1438682475) – could you just confirm that there’s no way to do this at the moment? I’ll start having a look at the code then!

[mike-fabian]

https://github.com/mike-fabian/ibus-table/blob/main/engine/table.py#L4160

        # Section to handle trailing invalid input:
        #
        # If the key has still not been handled when this point is
        # reached, it cannot be a valid input character. Neither can
        # it be a select key nor a page-up/page-down key. Adding this
        # key to the tabkeys and search for matching candidates in the
        # table would thus be pointless.
        #
        # So we commit all pending input immediately and then commit
        # this invalid input character as well, possibly converted to
        # fullwidth or halfwidth.
        if keychar:
            if DEBUG_LEVEL > 0:
                LOGGER.debug(
                    'trailing invalid input: keychar=%s', keychar)
            if not self._candidates:
                self.commit_string(self.get_preedit_tabkeys_complete())
            else:
                self.commit_to_preedit()
                self.commit_string(self.get_preedit_string_complete())
            if ascii_ispunct(keychar):
                self.commit_string(self.cond_punct_translate(keychar))
            else:
                self.commit_string(self.cond_letter_translate(keychar))
            return True

diff --git a/engine/table.py b/engine/table.py
index 6953e6f..4dcdc7a 100644
--- a/engine/table.py
+++ b/engine/table.py
@@ -4172,7 +4172,7 @@ class TabEngine(IBus.EngineSimple): # type: ignore
             if DEBUG_LEVEL > 0:
                 LOGGER.debug(
                     'trailing invalid input: keychar=%s', keychar)
-            if not self._candidates:
+            if not self._candidates or True:
                 self.commit_string(self.get_preedit_tabkeys_complete())
             else:
                 self.commit_to_preedit()

[Socob]

Well, that was much easier than I expected! I guess the only thing left would be to turn that into a proper setup option. I would be happy to do this, unless this is not something you’d want to include in the code?

[mike-fabian]

The code snipped in my last comment shows the part where trailing invalid input is handled. For example, when you type \rightarr!, you correctly write that ! is not a valid input char for the latex table. The source code of the latex table contains:

### Valid input chars.
VALID_INPUT_CHARS = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890^\_[]{}

! is not among these characters so when ! is typed it is certain that no match is possible.

Then the key processing ends up in the code snippet in the last comment. There it first checks if there are no candidates and if there are not , i commits the typed keys:

            if not self._candidates:
                self.commit_string(self.get_preedit_tabkeys_complete())

For example, if you type \xxxx! then there were no candidates because although x is a valid input character, nothing in the table matches \xxxx. The latex table has only this starting with \x:

$ grep '\\x' latex.txt 
\xi     ξ       0

Therefore, the last 3 x in \xxxx were displayed in pink and if sound is working there were error beeps. If ! is typed in that situation, then the typed keys are committed, i.e. \xxxx is committed.

But if there are matching candidates, then it goes to the else::

            else:
                self.commit_to_preedit()
                self.commit_string(self.get_preedit_string_complete())

which first commits the selected candidate to the preedit and then commits the preedit to the application.

After that it checks what to do with the !.

            if ascii_ispunct(keychar):
                self.commit_string(self.cond_punct_translate(keychar))
            else:
                self.commit_string(self.cond_letter_translate(keychar))
            return True

This looks overly conmplicated, in case of the latex table one could just commit the invalid input character.

But the Chinese tables have options whether letter or punctuation should be committed as fullwidth or halfwidth characters, even depending on whether the table is currently in direct input mode or not. So it checks whether the invalid input character is punctuation or not and then does the translation to fullwidth or halfwidth according to the options set.

In case of the latex table, this does nothing more than just commit the character without any changes. So one gets \xxxx! as the final result.

You seem to want this behaviour not only when there are no candidates but always. To give you something to test I just made that part always True in my test patch:

    if not self._candidates or True:

Now it never goes to the else: and always commits the typed characters.

If you want to test whether this does what you want, you can edit that line in

/usr/share/ibus-table/engine/table.py

(as root), save the file and restart ibus (ibus restart). Or restart your session.

I tested it and I think it does what you want.

[Socob]

Indeed, I gathered as much (although I didn’t know the details about the punctuation part). I also tested it and it seems to work exactly as needed, hence my comment above!

[mike-fabian]

Well, that was much easier than I expected! I guess the only thing left would be to turn that into a proper setup option. I would be happy to do this, unless this is not something you’d want to include in the code?

Yes, my patch in the last comment was of course only for trying it out. If we really want to have this, we would need another option for this.

I am always hesitating to add more options of dubious value to ibus-table. ibus-table already had a lot of weird options when I took over maintenance, it is a mess to have so many options which are only useful in for very specific tables for very specific things. Some options like the strange Auto select options do several completely unrelated things (which I documented in the tooltip). That is a nightmare for maintenance, one can never remove such an option nor simplify the behaviour because some tables depend on exactly this behaviour. To make it a little bit simpler I did at least hide some options from the setup tools of tables for which these options are completely useless.

In future I want to add only options which are clearly useful and do one clearly defined thing only not several things at once.

And the name of the option should be almost self explanatory.

Adding another option is not very much work, but one should really think about how useful it is and if we decide that it is useful, choose a meaningful name for the option.

The option could look like this in the setup tool:

    Invalid input chars commit [candidate|typed keys]

where [candidate|typed keys] is a combobox with two options.

Or it chould be a checkbox:

☑ Invalid input chars always commit typed keys

and when unchecked we would have the current behaviour to commit the candidate and when checked we would the behaviour you want.

I wonder though whether you are the only person in the world who wants this, I am still not really convinced why this is useful.

[mike-fabian]

Why not just type Return !, is that one extra keystroke really such a problem? How many keystrokes on average could that save you? Not so many, I guess.

[mike-fabian]

Also, the behaviour to commit the currently selected candidate when something is typed which cannot add any information to choose a different candidate feels very natural to me. ibus-typing-booster behaves in a similar way, if any key or key combination is typed which cannot add anything the current preedit and cannot change the selected candidate either, then ibus-typing-booster also commits the current candidate and appends the key or key combination.

Comitting the raw typed keys instead feels super weird to me.

[Socob]

No problem – I completely understand, and would be happy to just keep it to myself as a local patch. It’s easy enough to apply, since the code is in Python.

I’m probably not the only one who would have a use for functionality like this (see e. g. the Julia REPL I mentioned above, or when inputting math in LaTeX as Unicode characters for use with unicode-math), but all these use cases usually take the approach of implementing this in specific software (the Julia REPL and IDE, or macros in a LaTeX editor). I was looking for a global solution instead, so I wouldn’t have to keep finding workarounds for each piece of software I want to use where I want to easily write Unicode characters (e. g. when writing emails, code comments in other languages, etc.).

The keystroke itself is not the problem, but the fact that I would have to actively remember to do it. I often type “normal” LaTeX as well, and there I would have to keep hitting Return to prevent turning what I typed into something else. It’s also very easy to accidentally convert a typed sequence into a substitution when mistyping, and then it’s confusing to undo for a moment. Or in general, typing anything that involves backslashes would become troublesome. Of course, I could disable ibus-table-latex when I do this, but it’s just much easier when I don’t have to keep switching input methods.

As I said, it’s perfectly fine if you don’t want to add this!

[mike-fabian]

Trying to understand this better, I just wondered what would happen if you try to type something like

\frac{1}{3}x^3

and do not want that \frac turns automatically into something like ⅟ .

Surprisingly, when testing this, I found that when typing \frac{, the { does not trigger a commit but becomes pink and it beeps. Which means { is a valid input char for the latex table, surprisingly. It beeps because theoretically a typed string containing { could match something, just \frac{ does not match, but other strings containing { could.

But as this surprised me I checked, and actually there is nothing in the latex table using {:

mfabian@hathi:/local/mfabian/src/ibus-table-others/tables (release-candidate-1.3.15)
$ grep '\[' latex.txt 
VALID_INPUT_CHARS = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890^\_[]{}
\sqrt[3]        ∛       0
\sqrt[4]        ∜       0
mfabian@hathi:/local/mfabian/src/ibus-table-others/tables (release-candidate-1.3.15)
$ grep '{' latex.txt 
VALID_INPUT_CHARS = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890^\_[]{}
mfabian@hathi:/local/mfabian/src/ibus-table-others/tables (release-candidate-1.3.15)
$ grep '}' latex.txt 
VALID_INPUT_CHARS = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890^\_[]{}
mfabian@hathi:/local/mfabian/src/ibus-table-others/tables (release-candidate-1.3.15)
$ grep '\[' latex.txt 
VALID_INPUT_CHARS = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890^\_[]{}
\sqrt[3]        ∛       0
\sqrt[4]        ∜       0
mfabian@hathi:/local/mfabian/src/ibus-table-others/tables (release-candidate-1.3.15)
$ grep '\]' latex.txt 
VALID_INPUT_CHARS = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890^\_[]{}
\sqrt[3]        ∛       0
\sqrt[4]        ∜       0
mfabian@hathi:/local/mfabian/src/ibus-table-others/tables (release-candidate-1.3.15)
$

So { is listed in VALID_INPUT_CHARS but nothing in latex.txt really uses it. Looks wrong. I think { and } should be removed from VALID_INPUT_CHARS.

All other characters listed in VALID_INPUT_CHARS ared actually used in the table, only { and } are not used. Really weird.

So currently, for you, this is maybe nicer that \frac{ beeps instead of silently changing it into ⅟{.

But it looks like I should remove { and } from VALID_INPUT_CHARS and then it will do just that, typing \frac{ would become ⅟{.

Is that basically the usecase you have in mind? You type something like \frac{1}{3}x^3 and want the LaTeX command \frac and not some Unicode character for a fraction? And this happens accidentally quite often?

[Socob]

I think you’re right that { and } should be removed. I can see how the idea might have been to turn e. g. \frac{2}{3} into ⅔, but it seems like those cases were instead covered by leaving out the {}, as in \frac23. So as it stands, it doesn’t make any sense to have {} in VALID_INPUT_CHARS.

Is that basically the usecase you have in mind? You type something like \frac{1}{3}x^3 and want the LaTeX command \frac and not some Unicode character for a fraction? And this happens accidentally quite often?

Yeah, that’s basically it when it comes to LaTeX, though there are many other cases where you naturally have backslashes that should be “left alone” (e. g. regular expressions, PHP programming, or, although this doesn’t affect me personally, it would probably come up for many people: anything related to paths on Windows, where \ is the directory separator; these would be less likely to collide with the LaTeX names, though).

Maybe another thing to note is also that I don’t get any error beep sounds. I’m not sure if I turned that off somewhere (can’t find where?) or why that is, but if there were actually a beep every time, that would obviously be extremely annoying :-D

[mike-fabian]

Maybe another thing to note is also that I don’t get any error beep sounds. I’m not sure if I turned that off somewhere (can’t find where?) or why that is, but if there were actually a beep every time, that would obviously be extremely annoying :-D

In the screenshots in

https://github.com/moebiuscurve/ibus-table-others/issues/26#issuecomment-1438772463

You can see the

☑ Play sound file on error [/usr/share/ibus-table/data/coin9.wav]

option.

It is on by default. But you can switch it off by default.

The reason you don’t hear sound might be that you do not have the python module simpleaudio installed.

ibus-table tries to import this:

IMPORT_SIMPLEAUDIO_SUCCESSFUL = False
try:
    import simpleaudio # type: ignore
    IMPORT_SIMPLEAUDIO_SUCCESSFUL = True
except (ImportError,):
    IMPORT_SIMPLEAUDIO_SUCCESSFUL = False

and if it cannot be imported, it just skips doing error sounds.

I did not want to require simpleaudio, on Fedora it is available in the python3-simpleaudio-1.0.4-8.fc37.x86_64 package, but I am not sure whether it is available everywhere. And even if it is available, I don’t want to force ibus-table users to install it even if they don’t care for error beeps.

[mike-fabian]

I think you’re right that { and } should be removed. I can see how the idea might have been to turn e. g. \frac{2}{3} into ⅔, but it seems like those cases were instead covered by leaving out the {}, as in \frac23. So as it stands, it doesn’t make any sense to have {} in VALID_INPUT_CHARS.

I opened another issue for that:

https://github.com/moebiuscurve/ibus-table-others/issues/27

[mike-fabian]

Yeah, that’s basically it when it comes to LaTeX, though there are many other cases where you naturally have backslashes that should be “left alone” (e. g. PHP programming, or, although this doesn’t affect my personally, it would probably come up for many people: anything related to paths on Windows, where \ is the directory separator; these would be less likely to collide with the LaTeX names, though).

I think in these other use cases, the need for input of Unicode characters for mathematical symbols is probably so small, that one would just switch off the latex input most of the time and switch it only on when really needed.

I.e. switch to a plain keyboard layout or switch the ibus-table latex input method to direct input with the toggle_input_mode_on_off key binding (Shift_L by default).

For the occasional input of weird symbols (not only mathematical symbols, all kinds of symbols and emoji) I very much prefer ibus-typing-booster.

I have not used LaTeX much since my University days and I cannot remember most of the LaTeX abbreviations for mathematical characters anymore.

With ibus-typing-booster one does not have to remember exactly, one can match multiple keywords a bit fuzzy and I can usually find what I want even if I only vaguely remember what the name of the character could be.

https://mike-fabian.github.io/ibus-typing-booster/ https://mike-fabian.github.io/ibus-typing-booster/docs/user/#7 Unicode symbols and emoji predictions

If I want some kind of integral, I type integral_ (the trailing _ triggers the symbol search even if the symbol search option is off to make normal typing faster).

Clicking right with the mouse on the candidate showing ∫ gives more similar candidates.

Or, if I am looking for ∮, typing integral_contour_ will get me that character. Spellchecking is done on the input, i.e. typing something like integal_ will usually also do the job.

[Socob]

For a lot of cases, ibus-typing-booster would probably be fine, but already having the LaTeX commands memorized, it’s much faster to make use of them than dealing with some fuzzy matching. I don’t know how it is these days, but I think I remember having some issues with typing in Greek letters (which is very simple using the LaTeX commands), where for example there are a lot of things matching pi in Unicode (a lot of them different variations of the letter π!). And at least for me it feels like overkill since it does a lot more than what I’m really looking for.

Again, I understand that this is probably a pretty niche use case (even including people who would have a use for it, but are using other solutions), and don’t mind not having it included upstream. One could avoid having to add a user-visible option by adding it as an option in the table definition (e. g. latex.txt), although that doesn’t really help with the increase in complexity and maintenance.

[mike-fabian]

Actually, I tried again now to input Greek letters via their names with ibus-typing-booster, I thought typing greek_letter_pi_ should surely work, but it didn’t. Of course I immediately remembered why not, in that search for symbols and emoji I excluded all regular letters from Unicode to make the search resonably fast. So I also excluded the Greek letters.

In my emoji-picker which uses the same code to search for symbols as ibus-typing-booster, there is a command line option to search all of Unicode:

$ emoji-picker --help
usage: emoji_picker.py [-h] [-l [LANGUAGES]] [-f [FONT]] [-s [FONTSIZE]] [-m] [-a] [--fallback [FALLBACK]] [--emoji_unicode_min [EMOJI_UNICODE_MIN]]
                       [--emoji_unicode_max [EMOJI_UNICODE_MAX]] [-d] [--version]

An emoji picker for ibus-typing-booster

options:
  -h, --help            show this help message and exit
  -l [LANGUAGES], --languages [LANGUAGES]
                        Set a list of languages to be used when browsing or searching for emoji. For example: "emoji-picker -l de:fr:ja" would use German, French, and Japanese. If empty,
                        the locale settings are used to determine the languages.
  -f [FONT], --font [FONT]
                        Set a font to display emoji. If not specified, the font is read from the config file. To use the system default font specify "emoji". default: "None"
  -s [FONTSIZE], --fontsize [FONTSIZE]
                        Set a fontsize to display emoji. If not specified, the fontsize is read from the config file. If that fails 24 is used as a fall back fontsize. default: "None"
  -m, --modal           Make the window of emoji-picker modal. default: False
  -a, --all             Load all Unicode characters. Makes all Unicode characters accessible, even normal letters. Slows the search down and is usually not needed. default: False
  --fallback [FALLBACK]
                        Whether to use fallback fonts when rendering emoji. If not 0, pango will use fallback fonts as necessary. If 0, pango will use only glyphs from the closest
                        matching font on the system. No fallback will be done to other fonts on the system that might contain the glyhps needed to render an emoji. default: "None"
  --emoji_unicode_min [EMOJI_UNICODE_MIN]
                        Load only emoji which were added to Unicode not earlier than this Unicode version. default: 0.0
  --emoji_unicode_max [EMOJI_UNICODE_MAX]
                        Load only emoji which were added to Unicode not later than this Unicode version. default: 15.0
  -d, --debug           Print some debug output to stdout. default: False
  --version             Output version information and exit. default: False

Using that, I can search for greek letter pi in emoji-picker and it works.

Typing Booster currently has no option to include all of Unicode in the search. Maybe I should add such an option ....

Including all letters of Unicode in the search makes it slow because there are so many letters of "exotic" scripts which most people may not need. But maybe I should include the most common ones like Greek and Cyrillic ...

Or add a new option to the typing booster setup tool to include all of Unicode in the search.

[mike-fabian]

I am considering adding that option for you, because it really does one single thing and should not be too much of a maintanance problem. I am leaning towards the checkbox version instead of the combobox:

☑ Invalid input chars always commit typed keys

Somehow I am not happy with the text, do you have a better suggestion? Of course the tooltip could explain in more detail what it does, but the text after the checkbox should already explain it reasonably well if possible.

[Socob]

It’s a bit difficult to phrase, since it’s not necessarily clear what “invalid input character” means. Perhaps

☑ Commit current candidate when invalid input character is typed

but this phrasing would lend itself more to a combobox, because it’s not clear what happens when the checkbox is unchecked. So the combobox version could be

Action when typing invalid character: [Commit current candidate | Commit typed keys]

I think a combobox actually might make sense, since there are a number of possible things that could happen when an invalid character is typed beyond the two options that we discussed here (for instance, it could also be equivalent to “cancel” – not that that would be very useful).

[mike-fabian]

Action when typing invalid character: [Commit current candidate | Commit typed keys]

I like that suggestion.

[mike-fabian]

Especially I think you are right that the combobox leaves the possibility to add more options. I don’t think I want to add more option, but the combobox makes this possible.

[mike-fabian]

Do you also have an idea for a longer explanation for that option which could be shown as a tooltip when the mouse hovers over that option? Is there anything more to explain which would make it easier to understand?

[Socob]

Here is a suggestion:

Determines what happens when a character which is not in the set of valid input characters for this table is typed: With “commit current candidate”, the currently selected candidate is inserted. With “commit typed keys”, the raw characters typed so far during the candidate selection process will be inserted instead. In all cases, the candidate selection ends when an invalid character is typed and the character in question is inserted immediately after the text that results from the options listed above.

Some of the phrasing might be a bit awkward because I’m not sure about the proper terminology: Would it be correct to say that the “raw characters typed so far” are the contents of the preedit? Because of the “commit to preedit” functionality, I’m not so sure. There seem to be two “preedit-like buffers”: First, the buffer that the typed characters go to when the normal candidate selection is initiated (shown at the top left of the candidate selection window), and second, wherever that text goes when “commit to preedit” is executed. I don’t really understand the roles of these distinct buffers, and what the official names for them are.

[mike-fabian]

Here is a suggestion:

Determines what happens when a character which is not in the set of valid input characters for this table is typed: With “commit current candidate”, the currently selected candidate is inserted. With “commit typed keys”, the raw characters typed so far during the candidate selection process will be inserted instead. In all cases, the candidate selection ends when an invalid character is typed and the character in question is inserted immediately after the text that results from the options listed above.

That sounds OK. I think I will add this option in April.

Some of the phrasing might be a bit awkward because I’m not sure about the proper terminology: Would it be correct to say that the “raw characters typed so far” are the contents of the preedit? Because of the “commit to preedit” functionality, I’m not so sure. There seem to be two “preedit-like buffers”: First, the buffer that the typed characters go to when the normal candidate selection is initiated (shown at the top left of the candidate selection window), and second, wherever that text goes when “commit to preedit” is executed. I don’t really understand the roles of these distinct buffers, and what the official names for them are.

No, the raw characters typed to far are not the contents of the preedit.

When I type \al with the latex table for ibus-table, the candidate list shows

F1 α pha F2 ℵ eph

and the preedit shows “α” underlined in black.

If you then type Control+Shift_L', then the current preedit gets “committed to preedit”, this is visible because it now turns red and is still underlined (Unless you are on Wayland where colours in preedit unfortunately do not work). This is still in preedit though and not finally commited to the application you are typing in. You could then type another\al` and now you see one “α” in read with underline followed by another “α” in black with underline. The red one is committed to preedit but not to the application, the black one is not committed at all.

ibus-table is the only input method I know of which has this two step committing, first to preedit and then final to the application.

You do not need to worry about this when using the latex table, it is useless for the latex table, just don’t type the key binding `Control+Shift_L' it doesn’t do anything useful for the latex table. It is a feature for very few Chinese input methods like Wubi where you can keep committing Chinese characters to the preedit until you have a rather long Chinese string in the preedit shown in red and then the auxilary text shows you an automatically defined new shortcut to type that possibly very long Chinese string again by a combination of just 4 keys.

But except for this small number of Chinese tables using this, commit to preedit is useless.

Video showing the commit to preedit (in red) using the latex table (only for clarification, you do not want to do this when using the latex table):

https://user-images.githubusercontent.com/2330175/222124677-c0cc97a1-6e45-4c52-ab17-8b55731cf8c2.mp4

[mike-fabian]

I have no time to work on this new option right now, I will probably do it in April, if I didn’t do it in April you can remind me again.

[mike-fabian]

Video showing the commit to preedit feature with the table:

table:wubi-jidian86 - WuBi-Jidian-86-JiShuag-6.0

where it is actually useful:

https://user-images.githubusercontent.com/2330175/222128696-783d14c4-4e5e-4492-848e-664f90d08811.mp4

[mike-fabian]

In that video I type

a Control+Shift_L b Control+Shift_L c Control+Shift_L d Control+Shift_L e Control+Shift_L f Control+Shift_L

Then I have 6 Chinese characters committed to preedit, the preedit is completely red and the auxiliary text shows me

...  #: abnf

which tells me the new shortcut abnf has been defined for that string of 6 Chinese characters.

I commit this by typing space, it turns black I type Return to go to the next line and type abnf now I get that same Chinese string again immediately.

So that commit to preedit feature is for adding more and more stuff to the preedit and then defining automatically a new shortcut for the whole thing. But most table do not even have such a shortcut defining feature yet, only for the very few tables which have this, this commit to preedit is actually useful.

[mike-fabian]

I am back from vacation and working on this. See: https://github.com/mike-fabian/ibus-table/issues/133 https://github.com/mike-fabian/ibus-table/tree/release-candidate-1.16.15 https://github.com/mike-fabian/ibus-table/commit/70435d04d5c901d02320025c929c66388a201dfb

[mike-fabian]

Included in https://github.com/mike-fabian/ibus-table/releases/tag/1.17.0