This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Ubuntu 13.04 Scenario: - Start gnome-terminal - Type: aaa bbb ccc - Press Alt+b ==> cursor jumps on first c - Press Alt+f ==> cursor jumps on last c - Type mc and press ENTER ==> Midnight Commander started - Press F10 ==> I can close Midnight Commander - Start NetBeans - Start built-in terminal - Type: aaa bbb ccc - Press Alt+b ==> terminal adds 'b' - Press Alt+f ==> terminal adds 'f' - Type mc and press ENTER ==> Midnight Commander started - Press F10 ==> I can't close Midnight Commander
Workaround: Alt+b == Esc+b, Atl+f == Esc+f
Works for me in nightly build. Terminal has "Ignore global shortcuts" checkbox in options, is it unset?
Yes F10 was fixed in trunk. Alt-<key> doesn't work in all cases ("Ignore global shortcuts" checkbox doesn't fix bug)
Alt+<key> is not implemented now. Alt+B, Alt+C, ...
Hi, how can we solve this issue? I posted previously a question on stackoverflow describing the problem, and now found this bug report. How can i contribute to solve this bug, where to start? thanks ! http://stackoverflow.com/q/28212671/1478248?stw=2
(In reply to swartur2012 from comment #5) > How can i contribute to solve this bug, where to start? lib.terminalemulator + probably Tools->Options->Misc->Terminal; "Ignore global shortcuts" checkbox
We can do this. First, the problem with F10 is unrelated and as already mentioned has been fixed. Second, IgnoreGlobalShortcuts is a red herring. There are very few shortcuts in NB beginning with Alt. You can see them all using Tools->Options->Keymap. However, a _window manager_ might steal any Alt-keys before NetBeans even sees them so keep this in mind. Third, the sequences are really interpreted by the shell or whatever application is running in the terminal and interpretation of control sequences depends on the editor mode. So if you favor vi (set -o vi) Alt-f doesn't really do anything (but Alt-w does). A quick summary of what is missing is that when Alt is used as a modifier for some other key, say K, it should be converted to ESC followed by K. The actual spec is somewhat more complicated. Look in http://invisible-island.net/xterm/ctlseqs/ctlseqs.html or some other xterm spec under "Alt and Meta Keys". There are 4 resources that govern things: resource default value ----------------------------- metaSendsEscape true altSendsEscape false altIsNotMeta false modifyOtherKeys 0 (disable) From a coding point it's not _that_ complicated but what options do we want to give to users? In general the Alt key is considered to be synonymous with Meta. Try "xmodmap -pm". It will explain why altIsNotMeta is false by default. I.e. altIsMeta! modifyOtherKeys seems to be the least variable of these and I'm just going to assume that keeping it at disabled is fine. It's been hard to figure under what circumstances a users keyboard may have an actual Meta key. By that I don't mean a physical key labelled Meta, that went out with Symbolics' keyboards, but an xmodmap/XKB hack to designate a specific key/keyCode to be Meta distinct from Alt. Java recognizes this distinction as there exist both KeyEvent.VK_ALT and VK_META but I don't quite have the xmodmap savvy to assign a particular key to VK_META and test this out. Also things are different on Windows and Mac. See http://unix.stackexchange.com/questions/28993/what-is-bashs-meta-key So for starters I'll assume that ... modifyOtherKeys always 0 (disable) altIsNotMeta always false (ergo Alt == Meta) metaSendsEscape N/A altSendsEscape ... For altSendsEscape the default, according to the man page, is false yet all the terminals I've toyed with seem to have it set to true. So, we can start with creating a new term and options property, altSendsEscape, and make it be true by default.
changeset : 299668:48249f3a54f8 author : ivan@netbeans.org date : Sat Aug 13 11:05:44 PDT 2016 summary : 236268 - terminal ignores Alt-f, Alt-b keys Introduced new Term property, altSendsEscape. It is matched with a TermOptions property of the same name and a check box in org.netbeans.modules.terminal.nb.TermOptionsPanel. I was surprised to find out that TermOptionsPanel under org.netbeans.lib.terminalemulator.support was cloned, for reasonably good reason, into terminal.nb/TerminalImplementation. So for the moment, the original TermOptionsPanel doesn't support altSendsEscape yet. Syncing the two implementations will be a future project. Term's altSendsEscape property affects the behaviour of Term's screen's charTyped() KeyListener. It is based on xterm behaviour. You can read more about it in the javadoc for Term.setAltSendsEscape(). User Visible Changes -------------------- If altSendsEscape is checked (the default), when Alt is used as a modifier for some other key, say K, it will be converted to an ESC followed by K. If altSendsEscape is not checked, when Alt is used as a modifier, characters in the range 0-127 will be "shifted" to 128-255 by adding 128. This allows the entering of "8bit ascii", "accented", characters used predominantely in the "latin" charsets. It takes a bit of care to actually see this work. For example, my personal locale has LANG=en_US.utf8 but everything else, LC_*, is "C". Java looks at $LC_ALL to decide it's Charset and for "C" it chooses US-ASCII which is a 7-bit ASCII encoding so anything modified by Alt showed up as '?' for me. The remedy was to set $LC_ALL to en_US.utf8. There are also some shananigans that 'bash' pulls such that if you type Alt-e at bash you won't get the accented 'e' but if you use 'cat' or 'od' or 'vi' things get echoed properly. The Mac ------- Apparently my earlier assumption that "altIsNotMeta false" doesn't hold for the Mac for it has a dedicated Meta key, the Apple key, distinct from Alt. However, I don't have a Mac so it'll take me a bit to figure what's the right thing to do. Suggestions welcome. Terminal options dialog ----------------------- The usual accelerator choosing game. I freed S by using z for FontSize and assigned it to AltSendsESC.