7 ms·

For decades I've been saying that all text input should go through OS-level IMEs (input method editors). For more complex scripts, the need is obvious, but even

by SiVal 7y ago

For decades I've been saying that all text input should go through OS-level IMEs (input method editors). For more complex scripts, the need is obvious, but even writing in English, we can get great benefits from a system that expands abbreviations, replaces easy-to-type sequences with proper Unicode chars, runs little scripts and inserts the output, gives you quick dictionary/thesaurus lookups, gives you emmet-style powers, etc., whenever you're writing and in any app. Of course, everyone's preferences will be different, so you'll get default IMEs with default configs, but with the idea that you can reconfigure or replace them entirely with systems that work the way you want to work everywhere you input text. There have been utilities that do this sort of things for decades, but they've always been treated as clever hacks rather than standard text input. In other words, instead of powerful text input methods being the exception, they would be the rule, and apps that didn't use them would be the exception.

saurik 7y ago
So that sort of makes sense, but then I realize I am looking for all of those behaviors to be different in different contexts (such as writing code vs. writing an essay).
- TheSmiddy 7y ago
  The OS knows the destination app (and with the correct apis the context within that app) so this would be trivial to implement once the base exists.
Pxtl 7y ago
> For decades I've been saying that all text input should go through OS-level IMEs (input method editors). Which is why it's infuriating when the built-in widgets of a platform don't include simple operations for obvious workflows like filtering characters, masked input, etc. That's what leads developers to have to roll their own implementation using keydown/keyup. I can't tell you how many GUI frameworks have forced me to roll my own numeric input widget.
- ygra 7y ago
  Wouldn't it be enough if there was an obvious event for actual text input? WPF for example has that and it's the obvious and IME-friendly choice, since of course not every keystroke results in a character (dead keys exist too, after all).
pcr910303 7y ago
> I've been saying that all text input should go through OS-level IMEs This is so true, all commercial OSes that take i18n seriously do this, while most open source OSes' community (which communication revolves around English) decided that IMEs are an add-on for CJK people. It's a pity, and this one reason is enough for Linux to be never adopted for ordinary users in the non-western world.
- mikekchar 7y ago
  That's not really fair, though. Linux users still overwhelmingly use X windows. There is no standard IME for X. This is just a historical issue. X Windows is OLD -- far older that Windows or Mac (even the old Mac), for instance. My biggest problem with IMEs in free software land is that we've had groups like Gnome lean on IME developers and push through their vision of how it should work -- even though the people pushing their vision don't use IMEs. I ended up migrating to FCITX just because it was the last hold out not to cave to pressure.
  - efdee 7y ago
    That's not really fair either. X Windows might be older, but neither Mac OS nor Windows had anything like this in their older versions. Some things evolved, some things didn't. O hi X Windows!
    - rmah 7y ago
      MacOS had rather robust internationalization support 25 years ago. Non-standard, but still.
  - shadowgovt 7y ago
    Old really means there's been more time to identify and solve the problem, and the fact it hasn't been cleanly solved is a lot more indicative of priorities than time or tech. Microsoft and Apple have the incentive of selling to billion-user markets. The open source community, on average, appears to have demonstrated a lack of interest in opening up the user-base further (and expecting that user-base to just roll their own solution creates multiple catch-22 and tragedy of the commons problems). Why one of the commercial open-source vendors hasn't taken this on as a core challenge, I do not know.
tempguy9999 7y ago
> we can get great benefits from a system that expands abbreviations, ... emmet-style powers I can't agree here (excepting perhaps the unicode char replacement which a non-english speaker needs to comment on the viability of, vs actually having a non-english keyboard (excepting huge alphabets like chinese where that is used already AFAIK)). Writing is fundamentally a thinking process, the text entry for a touch typist is relatively quick. If you are to propose expanding abbreviations, how much time do you expect to save? I mean, actually measured it? > runs little scripts and inserts the output What is the purpose of this? > gives you quick dictionary/thesaurus lookups I use those perhaps once a week or less. If you use it say 3X a day, you'd save little time, perhaps a couple of minutes. Dunno what emmet powers are though. MS word & libreOffice does some of what you want and the first time I install them, I spend several minutes tracking down each setting and turning them off - they drive me bonkers. They think they know what I want but they don't. Touch typists can hit many keys a second and kind of pipeline their typing. Having the input modified automatically is rarely useful IMO. Your idea may be good but like many other ideas such as graphical programming, except in restricted cases they don't work. Perhaps if you measured it I'd be convinced but I can't accept it now as an obviously great benefit.
- chrisweekly 7y ago
  IIUC the parent was suggesting an OS-level system that _supports_ these features natively, as the foundation layer for any number of userland tools to sit atop... vs your compelling arg for why said features must be straightforward to disable. I don't see a conflict.
  - tempguy9999 7y ago
    True, upvoted. My point was that these facilities are of questionable value (I'd like to see how much time they really save, or indeed even lose when triggered accidentally), and that they have to be in easy control of the user. With MS there's too much "we invented it so you're getting it", and bad designers (who always outnumber good) will do the same. Actual example, was working with vis studio with another guy. Open a bracket and VS automatically added a closing bracket. That is fucking annoying and saves you a whole keystroke while breaking muscle memory and interfereing with our work. We had trouble turning that off.
polm23 7y ago
Totally agree. The best use case here is hooking up your keyboard to a personal database to autocomplete notes you saved, like locations, bookmarks, and so on. I have a note-taking system that I use to store all this data, and after I set it up years ago I looked at implementing an IME to search my notes and get a link to an entry, but every platform has its own byzantine IME API and I never got anything working. I've been thinking it might be easier to just make a cross-platform program that interacts with the clipboard rather than being a true IME. In general one effect I'd like to see from having flexible IMEs would be allowing logging and chat could be left to separate apps. Imagine a birdwatching (or whatever) keyboard that lets you pick the birds you saw, their age, behavior, and punch it in while you're in the field, and have it output in structured form into whatever app is handy.

by SiVal 7y ago

saurik 7y ago

So that sort of makes sense, but then I realize I am looking for all of those behaviors to be different in different contexts (such as writing code vs. writing an essay).

TheSmiddy 7y ago
The OS knows the destination app (and with the correct apis the context within that app) so this would be trivial to implement once the base exists.

Pxtl 7y ago

> For decades I've been saying that all text input should go through OS-level IMEs (input method editors). Which is why it's infuriating when the built-in widgets of a platform don't include simple operations for obvious workflows like filtering characters, masked input, etc. That's what leads developers to have to roll their own implementation using keydown/keyup. I can't tell you how many GUI frameworks have forced me to roll my own numeric input widget.

ygra 7y ago
Wouldn't it be enough if there was an obvious event for actual text input? WPF for example has that and it's the obvious and IME-friendly choice, since of course not every keystroke results in a character (dead keys exist too, after all).

pcr910303 7y ago

> I've been saying that all text input should go through OS-level IMEs This is so true, all commercial OSes that take i18n seriously do this, while most open source OSes' community (which communication revolves around English) decided that IMEs are an add-on for CJK people. It's a pity, and this one reason is enough for Linux to be never adopted for ordinary users in the non-western world.

mikekchar 7y ago
That's not really fair, though. Linux users still overwhelmingly use X windows. There is no standard IME for X. This is just a historical issue. X Windows is OLD -- far older that Windows or Mac (even the old Mac), for instance. My biggest problem with IMEs in free software land is that we've had groups like Gnome lean on IME developers and push through their vision of how it should work -- even though the people pushing their vision don't use IMEs. I ended up migrating to FCITX just because it was the last hold out not to cave to pressure.
- efdee 7y ago
  That's not really fair either. X Windows might be older, but neither Mac OS nor Windows had anything like this in their older versions. Some things evolved, some things didn't. O hi X Windows!
  - rmah 7y ago
    MacOS had rather robust internationalization support 25 years ago. Non-standard, but still.
- shadowgovt 7y ago
  Old really means there's been more time to identify and solve the problem, and the fact it hasn't been cleanly solved is a lot more indicative of priorities than time or tech. Microsoft and Apple have the incentive of selling to billion-user markets. The open source community, on average, appears to have demonstrated a lack of interest in opening up the user-base further (and expecting that user-base to just roll their own solution creates multiple catch-22 and tragedy of the commons problems). Why one of the commercial open-source vendors hasn't taken this on as a core challenge, I do not know.

tempguy9999 7y ago

> we can get great benefits from a system that expands abbreviations, ... emmet-style powers I can't agree here (excepting perhaps the unicode char replacement which a non-english speaker needs to comment on the viability of, vs actually having a non-english keyboard (excepting huge alphabets like chinese where that is used already AFAIK)). Writing is fundamentally a thinking process, the text entry for a touch typist is relatively quick. If you are to propose expanding abbreviations, how much time do you expect to save? I mean, actually measured it? > runs little scripts and inserts the output What is the purpose of this? > gives you quick dictionary/thesaurus lookups I use those perhaps once a week or less. If you use it say 3X a day, you'd save little time, perhaps a couple of minutes. Dunno what emmet powers are though. MS word & libreOffice does some of what you want and the first time I install them, I spend several minutes tracking down each setting and turning them off - they drive me bonkers. They think they know what I want but they don't. Touch typists can hit many keys a second and kind of pipeline their typing. Having the input modified automatically is rarely useful IMO. Your idea may be good but like many other ideas such as graphical programming, except in restricted cases they don't work. Perhaps if you measured it I'd be convinced but I can't accept it now as an obviously great benefit.

chrisweekly 7y ago
IIUC the parent was suggesting an OS-level system that _supports_ these features natively, as the foundation layer for any number of userland tools to sit atop... vs your compelling arg for why said features must be straightforward to disable. I don't see a conflict.
- tempguy9999 7y ago
  True, upvoted. My point was that these facilities are of questionable value (I'd like to see how much time they really save, or indeed even lose when triggered accidentally), and that they have to be in easy control of the user. With MS there's too much "we invented it so you're getting it", and bad designers (who always outnumber good) will do the same. Actual example, was working with vis studio with another guy. Open a bracket and VS automatically added a closing bracket. That is fucking annoying and saves you a whole keystroke while breaking muscle memory and interfereing with our work. We had trouble turning that off.

polm23 7y ago

Totally agree. The best use case here is hooking up your keyboard to a personal database to autocomplete notes you saved, like locations, bookmarks, and so on. I have a note-taking system that I use to store all this data, and after I set it up years ago I looked at implementing an IME to search my notes and get a link to an entry, but every platform has its own byzantine IME API and I never got anything working. I've been thinking it might be easier to just make a cross-platform program that interacts with the clipboard rather than being a true IME. In general one effect I'd like to see from having flexible IMEs would be allowing logging and chat could be left to separate apps. Imagine a birdwatching (or whatever) keyboard that lets you pick the birds you saw, their age, behavior, and punch it in while you're in the field, and have it output in structured form into whatever app is handy.