Bug 756595

I have tried to reproduce this but as far as I can see, content assist is working as expected. Could this be an issue with ibus or something overriding the ctrl + space shortcut? By default, auto content assist should be enabled (Window -> Preferences.  Java -> Editor -> Content Assist -> Enable Auto Activation), so at least in the Java perspective, when you type a "." you should see the content assist.

This works for me, too.

eclipse-platform-3.7.1-4.fc16.x86_64
eclipse-jdt-3.7.1-4.fc16.x86_64

I think Roland's idea of GNOME accessibility getting in the way is a good one.  What desktop environment are you using?

Thank you, it seems indeed to be something else than eclipse. Content Assist on "." worked and still works before I filed this bug. But I cannot figure why the ctrl+space shortcut doesn't work. But it did work when I created a new user and started eclipse under that account.

Even though it's not a bug in eclipse, do you have any pointers to go about this?

Ok, so I found im-chooser and sure enough I had ibus enabled. Disabled it and now completion works again. No idea why it was enabled, I don't seem to need it.

So I guess the bug really is about eclipse completion not working with ibus enabled.

I feel like we've been through this before with im-chooser ... is there a chance this was fixed in Fedora to not use Ctrl-space and then regressed in F16?

If you are complaining in this issue why ibus is running for your box, please provide your locale information and $HOME/.imsettings.log. otherwise you'll have only a workaround to change the default keybinding to enable IM in ibus because ctrl+space is assigned for that purpose and this is a limitation to use together with IM.

Is there any chance the default can be something other than Ctrl-space?  I could have sworn this was changed in the past due to the conflict with Eclipse :)

(In reply to comment #3)
> Thank you, it seems indeed to be something else than eclipse. Content Assist on
> "." worked and still works before I filed this bug. But I cannot figure why the
> ctrl+space shortcut doesn't work. But it did work when I created a new user and
> started eclipse under that account.
> 
> Even though it's not a bug in eclipse, do you have any pointers to go about
> this?

You could change the default trigger key with 'ibus-setup' command.
If you don't use ibus, probably you could disable it with 'im-chooser'.

Currently I don't think to change the default trigger key in ibus and didn't change it in the past.

Probably I'd close this bug as "Not a Bug".

As we can not make Eclipse change the shortcut without making the IDE unusable for any experienced developer and generating the same amount of bugreports for Eclipse and ibus can not change the shortcut I'm proposing to make the two packages conflict. 
Without Ctrl+Space Eclipse is losing it's biggest feature so conflicting with ibus seems like a fare trade to me.

The point is that ibus will break not only Eclipse but every other IDE. To list IDEs shipped in Fedora that will be affected - kdevelop, netbeans, qtcreator, eclipse, emacs (uses ctrl+space in a number of combinations), monodevelop. 
And there are other things that will be affected - everything that includes kate-part (virtuallly the whole KDE desktop+ kile, lyx and etc.). 
This list was created by 15 min search if one digs deeper the list will grow a lot. Using such a commonly used application shortcut as a global one seems totally unacceptable to me.

Hmm.., interested.
OK, probably I guess you installed multiple XKB keymaps. Now we are working on combining XKB keymaps and input methods for GNOME and other desktops.
ibus Control+Space would be bound when the multiple ibus engines are enabled.
The ibus behavior is changed between F15 and F16.
In F15, if an input method is enabled, ibus binds Control+Space.
In F16, either multiple XKB keymaps or input methods effect the keybinding.
So if you configure mono keymap and no input method, I think you would not effect the ibus keybinding.
The purpose is that we have the similar implementation with Mac OS X and ChromeOS.

I'd think input method settings will be available on gnome-control-center in f17 or later and probably it would be better KDE also have the similar implementation.

I thought Control + Space is for the global setting and the input method keybinding is not ibus only but also other input method frameworks.
I have used Control + Space for input methods for more than ten years and it might be compatible with MS-Windows.
You still could change default the ibus keybinding with 'ibus-setup' command.
So probably if your initial locale is en_US.UTF-8, probably the ibus keybinding would not effect you since no default input method engines are enabled.

I thought Control+Space is for content assist and the keybinding is not Eclipse only but also other IDEs. I have used Control+Space for content assist for more than five years under windows and several linux distros.

Seriously, before discovering this issue in a fresh Fedora installation I've seen Control+Space used for keyboard switching only on MacOS (_Command_+Space, actually) but I always thought MacOS to be something totally alien.

PS Does anybody know what information is being requested for this issue via NEEDINFO flag? Shouldn't it be cleared?

Using ibus-setup command can change the default key-bind of Control+Space to another one.
Probably we will use Control+Space for input method by default.
Chinese users use Control+Space for MS-IME AFAIK.
I'm not sure why you talk about this issue now since this have been happened when you launch ibus and other Control+Space applications.

Control+Space is the autocompletion shortcut in pretty much every application that does autocompletion. It would be very bad if a system wide shortcuts starts messing with a well known application shortcut.

The autocompletion shortcut is not well know but minor for me and it seems Java applications because I don't see the Control+Space autocompletion shortcut in libreroffice, firefox, thunderbird, gedit. I uses the office tools, browser, e-mail client and text editor as daily work.
Input method Control+Space is the well know shortcut key for me beyond platforms.

I think you could customize the behavior with ibus or eclips.
Personally I'd like to suggest all Java shortcut keys to another one by default.

(In reply to comment #15)
> The autocompletion shortcut is not well know but minor for me and it seems Java
> applications because I don't see the Control+Space autocompletion shortcut in
> libreroffice, firefox, thunderbird, gedit. I uses the office tools, browser,
> e-mail client and text editor as daily work.
> Input method Control+Space is the well know shortcut key for me beyond
> platforms.
> 
> I think you could customize the behavior with ibus or eclips.
> Personally I'd like to suggest all Java shortcut keys to another one by
> default.

Please read comment 10 . I listed a number of things there and it's not Java only unless you feel free to strike the whole KDE stack as a Java.

I don't use your listed applications as daily works except for emacs.
Probably I think you could customize the emacs key-binding or Control+@ or customize ibus.

(In reply to comment #16)
> Please read comment 10 . I listed a number of things there and it's not Java
> only unless you feel free to strike the whole KDE stack as a Java.

Probably I don't think there is a problem at present.

What am I saying that it's ugly to request changing keybinding in tens of applications just because you don't use them!

My 2 cents.

Really, everyone uses ctrl + space to start autocomplete feature in IDEs. I consider it as a standard.

However you could customize ibus if you'd like to keep the key-binding in such an applications.
It would be limited in Java applications especially in Java development and other applications have Control+Space as other usages.

(In reply to comment #20)
> However you could customize ibus if you'd like to keep the key-binding in such
> an applications.
> It would be limited in Java applications especially in Java development and
> other applications have Control+Space as other usages.

How should I write it that we don't speak about Java applications only? 
About other applications having control-space for other usages they will stop working too!

As we would not come to agreement. I opened a FESCo ticket to get a broader attention to the issue.
https://fedorahosted.org/fesco/ticket/798

BTW, which ibus version do you use?
Reading this bug again, I doubt your problem might be that ibus eats the key events when an ibus XKB engine is enabled.
If yes, it was a known issue and has been fixed in ibus-1.4.0-17.fc16 (bug #769133).

It would be good to know what caused ibus to start running
on the reporter's desktop.

I guess your $HOME/.imsettings.log might has a clue for that.

This is something that has been affecting me (in emacs); I'd originally filed it as an emacs bug.  Since there have been requests for .imsettings.log files, I'll attach mine, I'd be curious if there's any wisdom that can be gained from it.

FWIW, I have ibus-1.4.0-17.fc17.x86_64

As far as I know, I don't actually need it running, but I don't see how it is controlled?  How can it make it not run?

Created attachment 560615 [details]
.imsettings.log

Jonathan, you can disable ibus with im-chooser.

Jens, regarding your question what caused ibus to be enabled: Could it be that some earlier Fedora release had ibus enabled by default? I usually update and don't reinstall and also always use the same $HOME.

(In reply to comment #28)
> Jonathan, you can disable ibus with im-chooser.

Right. or removing $HOME/.xinputrc should works in this case because we don't enable IM for en_US locale by default.

> Jens, regarding your question what caused ibus to be enabled: Could it be that
> some earlier Fedora release had ibus enabled by default? I usually update and
> don't reinstall and also always use the same $HOME.

Given it's true, that doesn't explain why they are complaining it now. they should face it earlier then...

Except when you didn't use Eclipse (or Emacs, etc.) before.

If you still have ~/.xinputrc pointing to ibus.conf it would be
interesting to know the datestamp of the symlink.

(In reply to comment #28)
> Jens, regarding your question what caused ibus to be enabled: Could it be that
> some earlier Fedora release had ibus enabled by default? I usually update and
> don't reinstall and also always use the same $HOME.

Not intentionally or as far as I know in any final release at least.
ibus is only enabled by default for East Asian locales.

If someone is able to reproduce how ibus might be getting started
unexpectingly that would be very helpful to know about.

$ ll .xinputrc 
lrwxrwxrwx   24. Nov 21:38 .xinputrc -> /etc/X11/xinit/xinput.d/none.conf

No idea if or when it was linked to something else. The date actually fits to my comment #4.

I see.  You should be able to delete the symlink unless
your desktop is running in an Asian locale .

Not sure if this would help but I have customized my ibus input list with 2 languages and left the default as english and the ctrl-space content assist in Eclipse would switch ibus to the first language although I've unbinded all the keyboard shortcuts. Once I add english to the list as another language, content assist works correctly again.

I'm experiencing this too, but AFAIK I have no ibus running!


I'm running F17, 64bits with Eclipse Indigo (not the fedora eclipse, the plain eclipse).

Something is stealing my ctrl+space key and I don't know what program it is.

I uninstalled all ibus packages and now my eclipse completion works again (after loggin out and in again).

ibus ___REALLY___ needs to change this behaviour!
eclipse is not the only program (by far!) that makes extensive use of ctrl+space

(In reply to comment #36)
> I uninstalled all ibus packages and now my eclipse completion works again
> (after loggin out and in again).
> 
> ibus ___REALLY___ needs to change this behaviour!
> eclipse is not the only program (by far!) that makes extensive use of
> ctrl+space

I think it's good for eclipse to change the behavior instead.
ibus-setup has already provided the customization.

I'll say it again - there is no way for eclipse to switch the default autocompletion key binding without seriously degrading the user experience. A question that comes to my mind - It should be possible for ibus to not eat the key event but resend it, right? This way it should be possible for both to still work. I think I've seen virt-manager doing that.

(In reply to comment #38)
> I'll say it again - there is no way for eclipse to switch the default
> autocompletion key binding without seriously degrading the user experience.
> A question that comes to my mind - It should be possible for ibus to not eat
> the key event but resend it, right? This way it should be possible for both
> to still work. I think I've seen virt-manager doing that.

Your suggestion would degrade the input method user experience. I think it's always vice-versa.
And ibus-setup already provides the customization.

(In reply to comment #39)
> (In reply to comment #38)
> > I'll say it again - there is no way for eclipse to switch the default
> > autocompletion key binding without seriously degrading the user experience.
> > A question that comes to my mind - It should be possible for ibus to not eat
> > the key event but resend it, right? This way it should be possible for both
> > to still work. I think I've seen virt-manager doing that.
> 
> Your suggestion would degrade the input method user experience. I think it's
> always vice-versa.
> And ibus-setup already provides the customization.

How would it degrade it? If ibus listens for the key event - handles it , does its stuff and rethrows it for other listeners - both should work right?

(In reply to comment #40)
> How would it degrade it? If ibus listens for the key event - handles it ,
> does its stuff and rethrows it for other listeners - both should work right?

handle it? Not sure what you're talking about key event.
It would be good for eclipse to change the default keybinding to another one not to conflict other applications.

You seem to have a really closed mind.

Guess who was first with the ctrl+space shortcut?
I'll give you a clue: it starts with an E and ends with clipse. And a dozen other IDEs.

Now please look at the usage of the shortcut:
- How often does a user of ibus use the ctrl+space shortcut? I'm guessing a few times per day.
- Now how often does a user of Eclipse use the ctrl+space shortcut? That would be more like a few times per minute.

Now tell me all honesty that you still think it's more logical for Eclipse to change their shortcut...

(In reply to comment #42)
> Now please look at the usage of the shortcut:
> - How often does a user of ibus use the ctrl+space shortcut? I'm guessing a
> few times per day.

I have used one time per 15 seconds for input methods for Asian locales.
And ibus won't be enabled for en_US by default.

(In reply to comment #41)
> (In reply to comment #40)
> > How would it degrade it? If ibus listens for the key event - handles it ,
> > does its stuff and rethrows it for other listeners - both should work right?
> 
> handle it? Not sure what you're talking about key event.
> It would be good for eclipse to change the default keybinding to another one
> not to conflict other applications.

Can you point me to the exact place in ibus code where listening for the key event happens? It should be a matter of not eating the event but rethrowing it.
And Eclipse does not conflict with other applications as it gets the event only when Eclipse is active which is quite different from someone defining a global shortcut. 

Anyway please point me to this code so I can take a look and play with it to see whether I will find a workaround.

(In reply to comment #43)
> (In reply to comment #42)
> > Now please look at the usage of the shortcut:
> > - How often does a user of ibus use the ctrl+space shortcut? I'm guessing a
> > few times per day.
> 
> I have used one time per 15 seconds for input methods for Asian locales.
> And ibus won't be enabled for en_US by default.

You might want to work with Ferry to check why ibus is eating his ctrl+space. It still happen to a number of people and the only solution I have for them is yum erase ibus*.

(In reply to comment #45)
> (In reply to comment #43)
> > (In reply to comment #42)
> > > Now please look at the usage of the shortcut:
> > > - How often does a user of ibus use the ctrl+space shortcut? I'm guessing a
> > > few times per day.
> > 
> > I have used one time per 15 seconds for input methods for Asian locales.
> > And ibus won't be enabled for en_US by default.
> 
> You might want to work with Ferry to check why ibus is eating his
> ctrl+space. It still happen to a number of people and the only solution I
> have for them is yum erase ibus*.

exactly. disabling ibus wasn't enough for me, I had to yum uninstall ibus

(In reply to comment #46)
> exactly. disabling ibus wasn't enough for me, I had to yum uninstall ibus

If you faced that issue on f17, there was a bug in gtk2. see Bug#828764 and try again after upgrading gtk2.

FWIW I've tried to open eclipse on f17 and this is the first time to run there, the default keybinding for the content assistant seems alt+/. is it the upstream change or Fedora specific to avoid this conflict for certain locales?

Alt+/ = word completion

that's not the same as code completion, which is ctrl+space

Aha. anyway, I don't see any features being assigned to ctrl+space by default on f17. FYI.

I wanted to try to see if it really doesn't conflict to ctrl+space between ibus and eclipse when rethrowing.

just read that ibus will be tightly integrated in gnome 3.6 (http://blog.fedora-fr.org/bochecha/post/2012/06/GNOME-3.6-and-IBus-for-Hong-Kong-users)

this issue NEEDS to be properly resolved before that in order to not disrupt the workflow of all Eclipse, IntelliJ, etc users.

Google recently released a new IDE that uses CTRL-space for code completion: http://collide.googlecode.com/git/README.md
I mention this to support the assertion that CTRL-space is used in many IDEs for code completion.

I use ibus on Fedora daily for non-English text input yet _ALSO_ uses Eclipse and other IDEs. My two points:
1. More IDEs will be released that want CTRL-space. Requiring custom configuration or patching of every one of them is unreasonable.
2. Saying "ibus won't be enabled for en_US by default" leaves Asian developers like me in the cold.

If ibus could change the default keybinding from CTRl-space to something else (like CTRL-Shift-space) it'd make the lives of users who need both east Asian text input and code completion in IDEs easier.

Again, anyone tell me what the feature are assigned to ctrl+space on Eclipse? I want to try to settle with comment#38 if possible. it might works on Eclipse perhaps, but it doesn't ensure it works on others as well though. it's another concern.

BTW I'm very concerned that we will eventually see the same situation sooner or later if you say the reason of "FOO apps also use the same key binding. this is majority. IM shouldn't use it" is sane. in fact it happened in the past.
Aside from that, though any suggestion is better than nothing since most people who don't need to use IM doesn't care and they just want comfort for themselves without knowing there are painful for IM users as well as you feel. however, let's see that IM is important for users who need it as similar as the Dead key and etc may be important for you. try to ask yourself, "Do I want to use the complicated key binding to input something for daily use?" IMHO the input is essential. it shouldn't be disturbed by anything else. I don't have any strong opinion to keep using ctrl+space for IM though, but we have to cut off this silly loop anyway.

I'm listening any constructive suggestions.

I suspect ibus has a passive key grab on ctrl+space. To implement forwarding of that key, you'll need to grab the key in XIGrabModeSync and call XIAllowDevice(ReplayDevice) once the key event was received (best followed by a XFlush() to make sure the request doesn't get held back and delays the key event). That will replay the event on the next window.

(In reply to comment #52)
> Again, anyone tell me what the feature are assigned to ctrl+space on
> Eclipse? I want to try to settle with comment#38 if possible. it might works
> on Eclipse perhaps, but it doesn't ensure it works on others as well though.
> it's another concern.
> 
> BTW I'm very concerned that we will eventually see the same situation sooner
> or later if you say the reason of "FOO apps also use the same key binding.
> this is majority. IM shouldn't use it" is sane. in fact it happened in the
> past.
> Aside from that, though any suggestion is better than nothing since most
> people who don't need to use IM doesn't care and they just want comfort for
> themselves without knowing there are painful for IM users as well as you
> feel. however, let's see that IM is important for users who need it as
> similar as the Dead key and etc may be important for you. try to ask
> yourself, "Do I want to use the complicated key binding to input something
> for daily use?" IMHO the input is essential. it shouldn't be disturbed by
> anything else. I don't have any strong opinion to keep using ctrl+space for
> IM though, but we have to cut off this silly loop anyway.
> 
> I'm listening any constructive suggestions.

Looks like comment#53 explains it all. I was just going to experiment with stuff as noone is familiar with input as Peter is, but to try anything we would need at least a hint from ibus developers as I'm not ready to spend days just to find an entry point in totally unfamiliar app. I don't even have an idea which of the ibus packages handles this.

(In reply to comment #53)
> I suspect ibus has a passive key grab on ctrl+space. To implement forwarding
> of that key, you'll need to grab the key in XIGrabModeSync and call
> XIAllowDevice(ReplayDevice) once the key event was received (best followed
> by a XFlush() to make sure the request doesn't get held back and delays the
> key event). That will replay the event on the next window.

If the shortcut key is Control+space, ibus does not return it so that other applications do not bind it whether sync or async is used.
But ibus would forward non-Control+space keys.
I cannot find XIAllowDevice in /usr/include/X11

sorry, ECOFFEE. that should read XIAllowEvent, defined in XInput.h
http://cgit.freedesktop.org/xorg/lib/libXi/tree/include/X11/extensions/XInput2.h#n447

Works more or less the same way as XAllowEvents.

(In reply to comment #56)
> sorry, ECOFFEE. that should read XIAllowEvent, defined in XInput.h
> http://cgit.freedesktop.org/xorg/lib/libXi/tree/include/X11/extensions/
> XInput2.h#n447
> 
> Works more or less the same way as XAllowEvents.

I'm not sure how XIAllowEvents can be used.
When I call XIAllowEvents (xdisplay, XIAllMasterDevices, SyncKeyboard, CurrentTime), XI_BadDevice was returned below.

This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 591 error_code 149 request_code 141 minor_code 53)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


    RANDR  (opcode: 149, base event: 100, base error: 165)
    XInputExtension  (opcode: 141, base event: 78, base error: 149)

XIALlowEvents requires the deviceid of the device that sent the event (and triggered the passive grab). XIAllMasterDevices is not valid for this call, sorry.

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.