-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typing a character not in VALID_INPUT_CHARS
commits current candidate
#26
Comments
Like most Chinese input methods, ibus-table also commits the exact characters typed ignoring any candidates or whatever is displayed in the preedit when So when you type I think this is the easiest way to get what you want, first commit the exact typed text with 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 Does that answer your question? |
@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 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 |
Oh, another thing: In the key bindings, I’ve found |
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":
But you can set it to "true" if you want and see what happens:
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. |
OK, I see – thanks again. I haven’t been able to notice any difference with this set to Not sure if you saw the first comment (#26 (comment)) – 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! |
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() |
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? |
The code snipped in my last comment shows the part where trailing invalid input is handled. For example, when you type
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
Therefore, the last 3 x in But if there are matching candidates, then it goes to the 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 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:
Now it never goes to the If you want to test whether this does what you want, you can edit that line in
(as root), save the file and restart ibus ( I tested it and I think it does what you want. |
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! |
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 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:
where Or it chould be a checkbox:
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. |
Why not just type |
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. Comitting the raw typed keys instead feels super weird to me. |
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 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 As I said, it’s perfectly fine if you don’t want to add this! |
Trying to understand this better, I just wondered what would happen if you try to type something like
and do not want that Surprisingly, when testing this, I found that when typing But as this surprised me I checked, and actually there is nothing in the latex table using
So All other characters listed in So currently, for you, this is maybe nicer that But it looks like I should remove Is that basically the usecase you have in mind? You type something like |
I think you’re right that
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 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 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 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. |
I opened another issue for that: |
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 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/ If I want some kind of integral, I type Clicking right with the mouse on the candidate showing ∫ gives more similar candidates. Or, if I am looking for ∮, typing |
For a lot of cases, 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. |
Actually, I tried again now to input Greek letters via their names with ibus-typing-booster, I thought typing In my
Using that, I can search for 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. |
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. |
It’s a bit difficult to phrase, since it’s not necessarily clear what “invalid input character” means. Perhaps
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
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). |
I like that suggestion. |
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. |
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? |
Here is a suggestion:
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. |
That sounds OK. I think I will add this option in April.
No, the raw characters typed to far are not the contents of the preedit. When I type F1 α pha and the preedit shows “α” underlined in black. If you then type 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): Peek.2023-03-01.12-17.mp4 |
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. |
Video showing the commit to preedit feature with the table: table:wubi-jidian86 - WuBi-Jidian-86-JiShuag-6.0 where it is actually useful: Peek.2023-03-01.12-36.mp4 |
In that video I type
Then I have 6 Chinese characters committed to preedit, the preedit is completely red and the auxiliary text shows me
which tells me the new shortcut I commit this by typing space, it turns black 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. |
…not in valid input characters is typed Resolves: #133 See also: moebiuscurve/ibus-table-others#26
I am back from vacation and working on this. |
…not in valid input characters is typed Resolves: #133 See also: moebiuscurve/ibus-table-others#26
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 theSTART_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:
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.
The text was updated successfully, but these errors were encountered: