GNOME Bugzilla – Bug 689471
Cannot use Emacs when Input Source integration is on
Last modified: 2013-04-20 17:10:42 UTC
In emacs key binding, set-mark (start selection) is bind to C-<space> by default. Most of users has been get use to that and to avoid conflict with input method, users would turn the input method in Emacs off, so that C-<space> won't trigger the input method. Now however, in Input Source integration when C-<space> is set as trigger input method and input method is disabled in Emacs, C-<space> cannot trigger emacs for set-mark. This is really annoying.
I don't fully understand the problem here. We don't even have a default key binding to switch input sources so if you set it to ctrl+space you'd certainly expect it to conflict with emacs, no? What could we do?
(In reply to comment #1) > I don't fully understand the problem here. > > We don't even have a default key binding to switch input sources so if you set > it to ctrl+space you'd certainly expect it to conflict with emacs, no? What > could we do? Well, I think there is another implicit "option" we're missing here. Application could tell the ibus-daemon, "Hey, I'm doing something special, please don't enable input method for me" Actually what happened in the ibus/fcitx case is, application tell ibus-daemon/fcitx daemon it need input method service, otherwise, don't trigger the input method.
(In reply to comment #1) > I don't fully understand the problem here. > > We don't even have a default key binding to switch input sources so if you set > it to ctrl+space you'd certainly expect it to conflict with emacs, no? What > could we do? Let's don't think about the conflict thing here, maybe that could help. So, say we're in GIMP main window, we shouldn't be able to trigger the input method since once it's triggered, there is no way of using gimp's accelerate key (T for text, S for selection...) There shouldn't be a way to trigger the input method if there is no input context associated.
(In reply to comment #3) > Let's don't think about the conflict thing here, maybe that could help. > > So, say we're in GIMP main window, we shouldn't be able to trigger the input > method since once it's triggered, there is no way of using gimp's accelerate > key (T for text, S for selection...) Are you sure about that? It actually works here... > There shouldn't be a way to trigger the input method if there is no input > context associated. If there's no text entry widget focused then IBus doesn't even enter the picture, i.e. the application will normally handle the X key events, which is what allows the GIMP in the above example to work correctly.
(In reply to comment #4) > (In reply to comment #3) > > Let's don't think about the conflict thing here, maybe that could help. > > > > So, say we're in GIMP main window, we shouldn't be able to trigger the input > > method since once it's triggered, there is no way of using gimp's accelerate > > key (T for text, S for selection...) > > Are you sure about that? It actually works here... > > > There shouldn't be a way to trigger the input method if there is no input > > context associated. > > If there's no text entry widget focused then IBus doesn't even enter the > picture, i.e. the application will normally handle the X key events, which is > what allows the GIMP in the above example to work correctly. Sorry... I should have tried. You're right. if there is no context, ibus doesn't enter the picture. This is a very bad example... So I think the problem here is only the triggering key, right?
(In reply to comment #4) > (In reply to comment #3) > > Let's don't think about the conflict thing here, maybe that could help. > > > > So, say we're in GIMP main window, we shouldn't be able to trigger the input > > method since once it's triggered, there is no way of using gimp's accelerate > > key (T for text, S for selection...) > > Are you sure about that? It actually works here... > > > There shouldn't be a way to trigger the input method if there is no input > > context associated. > > If there's no text entry widget focused then IBus doesn't even enter the > picture, i.e. the application will normally handle the X key events, which is > what allows the GIMP in the above example to work correctly. BTW actually that's kupfer's react lead me to think GIMP might have the same behaviour...(which is not the case) So, kupfer seems to create input context itself, even there is no text entry. Sorry about that.
Hi Mike, can we close this now?
(In reply to comment #7) > Hi Mike, can we close this now? Sorry for my late reply. I don't know what is the right way to deal with this issue. Maybe we might want to close this bug for now. I think the root cause is still the fact the input source integration cannot deal with input context. Users who want to use a context based input solution should fallback to other input methods like fcitx. There don't seems to be any solutions yet.
(In reply to comment #8) > I don't know what is the right way to deal with this issue. Maybe we might want > to close this bug for now. Ok, I'll close this. > I think the root cause is still the fact the input source integration cannot > deal with input context. Users who want to use a context based input solution > should fallback to other input methods like fcitx. There don't seems to be any > solutions yet. Note that in Gnome 3.8 the default shortcut to switch input sources is Super+Space so it won't conflict with emacs by default.