Wed 21 Dec 2016 03:21:29 PM UTC, comment #19:
This still happens, just installed 4.2.0 on ubuntu with all dependencies and etc. GUI works fine until the combination of ' + space key in the US international Keyboard.
I disabled auto completion and enabled it again and the issue went away for a while. It happened again after a few minutes. With auto-completion off issue doesn't happen.
|
Sat 12 Nov 2016 07:18:29 PM UTC, comment #18:
Downgrading to Severity 3. This is not a blocker for the 4.2.0 release.
|
Wed 14 Sep 2016 06:04:57 PM UTC, comment #17:
Ok, both Ubuntu and Fedora.
If it's true that this affects the majority of users, then maybe we should stop compiling autocompletion completely and not have the feature at all in the Octave editor until Qscintilla is fixed (or pick a new editor framework that isn't buggy).
|
Wed 14 Sep 2016 05:45:20 PM UTC, comment #16:
Are Ubuntu users the majority? I would assume so.
However, I can replicate it with 4.0.1 and 4.0.3 from the Fedora repositories on Fedora 23, too.
|
Wed 14 Sep 2016 05:37:06 PM UTC, comment #15:
Are Ubuntu users the majority? As far as I know this bug only affects Ubuntu users who are using a non-Latin keyboard input locale. I'm not sure whether Fedora installs and activates ibus by default.
We cannot do anything about this at the moment in Octave other than disabling autocomplete or forcing the environment variables in commment #11, which has other side effects when running under ibus, can't test at the moment.
|
Wed 14 Sep 2016 01:28:54 AM UTC, comment #14:
Isn't disabling the auto completion as default an option? This does not solve the problem, but does not make the bug active by default, which should affect less users.
I am unsure about how many users are affected by this bug and whether or not the tradeoff of not having autocompletion by default is the best decision when taking the majority needs into account.
However, not having autocompletion is much less troubling than crashing the editor.
|
Mon 08 Aug 2016 06:03:21 PM UTC, comment #13:
@Mike: Can we do anything for this bug? It seems to be a problem upstream with QScintilla. If we can't, then we should downgrade the severity to 3 to stop it gating the 4.2 release.
|
Sun 22 Feb 2015 07:00:54 PM UTC, comment #12:
I can also confirm that this crashes QScintilla using the Python binding for QScintilla and using the simple editor/autocompletion demo here:
http://www.kidstrythisathome.com/2011/08/autocompletion-using-pyqt4-and-qscintilla/
So this is definitely not an Octave bug. I don't know what needs to be done to address this in QScintilla upstream, but marking this bug as postponed.
The workaround is to uninstall or disable the ibus input method.
|
Sun 22 Feb 2015 05:35:20 AM UTC, comment #11:
@Torsten: I see the same as you if I `apt-get purge libibus-qt1`. If I `apt-get install ibus-qt4`, then I get the crash reported here. Unsetting the environment variables QT_IM_MODULE and QT4_IM_MODULE also temporarily disables ibus in the Octave GUI, which prevents the crash and just shows the behavior you are seeing.
Searching the web for "qscintilla ibus" shows that this is a problem with other QScintilla-based projects, not Octave-specific. I don't know if this has been reported to the QScintilla project or whether it's considered a bug in the input method or in QScintilla.
|
Sat 31 Jan 2015 07:31:20 AM UTC, comment #10:
I am still not able to reproduce the crash (gui-release) but:
- in a new editor tab, entering `, nothing happens, entering <space>, the ` appears (as expected)
- after a completion list was shown, entering `, the character instantly appears
- switching focus into another tab/widget/application and back into the editor tab, entering ` needs another key to make the character appear (as expected)
- when switching into another tab, the behavior is normal in that tab
It seems that the completion list corrupts something that is reinitialized when the tab gets focus again.
|
Fri 30 Jan 2015 11:03:37 PM UTC, comment #9:
Sorry for the delay, but I can confirm this crash of the GUI now with the OP's examples. I can crash any of 3.8.2, gui-release, and default.
The keyboard layout doesn't seem to matter for me, specifically I can crash the GUI with both standard US layout with Compose for international characters, or using US with dead key layout. As long as there is some way to enter an international character from the keyboard with either compose or dead keys. Pasting a character into the editor from the clipboard does not cause the crash.
Entering non-ASCII characters into the command window does not crash. Entering non-ASCII characters into a new editor window does not crash. The autocompletion popup has to be activated first, and either selected or canceled. The keyboard focus then has to stay in the editor and a non-ASCII international character entered using dead keys or a compose key combination.
|
Wed 25 Jun 2014 08:37:22 PM UTC, comment #8:
sorry, I forgot:
br(autocomplete appears)<space>(autocomplete disappears)´(nothing visible happens)<a>(crash) also leads to a crash, like with other composed characters
|
Wed 25 Jun 2014 08:25:53 PM UTC, comment #7:
The crash happens only when using dead keys.
It also happens when editing a .cc file (I used a hello word program and for as the keyword for completion).
The crash also happens when using other dead key characters:
br(autocomplete appears)<space>(autocomplete disappears)´(nothing visible happens)<space>(crash)
|
Fri 06 Jun 2014 05:06:29 AM UTC, comment #6:
I can't reproduce this with the gui-branch (stable is building, I am on ubuntu 12.04). I entered:
br
(completion list appears)
<space>
(completion list disappears)
^
(maybe followed by other characters)
Does this also happen on your system when you are editing c-files (file.cc)?
|
Fri 06 Jun 2014 12:10:00 AM UTC, comment #5:
For clarification, does the crash only happen when you are using a dead key layout? Does it crash when you enter the caret or when you hit space after the caret? Does it crash with other dead key symbols like tilde or accent/quote characters? Or am I wrong and you can also crash it when caret is not a dead key prefix?
|
Wed 04 Jun 2014 05:09:30 PM UTC, comment #4:
The auto competion settings are:
Number of chars typed before competion list displayed: 1
Match keywords and Case sensitive are selected.
As language setting, I use "system default" which is German (but the crash also happens when I set manually to en_US).
The crash only happens, if a "to be autocompleted" charakter is followed by a space (the autocompletion windows disappears) and the caret. For example a = a ^ works fine. But a = b (autocomplete appears) [one or more]SPACE (autocomplete disappears) CARET (crash).
When I set the # of autocomplete chars to 2, the crash happens for a = br(=break)) SPACE CARET.
If the autocomplete window is still shown, the caret ist not displayed when entered.
To put it in a nutshell: The crash happens one (or more) spaces after an autocompletion dropdown was hidden and a CARET is entered.
|
Wed 04 Jun 2014 05:07:07 AM UTC, comment #3:
What are the exact preferences you are using for the autocompletion?
|
Fri 30 May 2014 08:00:38 PM UTC, comment #2:
Thank you Mike for the fast response!
Unfortunately, it did not fix the problem (qt-at-spi was not installed).
I just playes a bit around in an empty file:
- Entering a single caret works.
- Entering a^ works, too.
- Entering a^ b^ works for the first caret, crash with the second one.
- Entering a^ = b^ crashes, too.
- Octave did also not crash with dead chars.
But: Turning autocomplete off resolves the problem!
|
Fri 30 May 2014 07:26:11 PM UTC, comment #1:
Thanks for your bug report. Can you look at bug #41552 and see if one of the workarounds in that bug report eliminate this crash for you? Specifically, does either
- export QT_ACCESSIBILITY=0; or
- sudo apt-get purge qt-at-spi
cause the crash to no longer occur?
|
Fri 30 May 2014 07:19:25 PM UTC, original submission:
Octave 3.8.1 from the Ubuntu repository started with --force-gui crashes when ^ should be displayed:
octave exited with signal 11
when entering a caret.
For me, it is reproducible with:
- Create a new file
- enter in this file a = b^
I use dead keys on a German keyboard, so I have to press space after ^ to get it displayed. Copying the char from an other file works without problems.
|