RSyntaxTextArea
RSyntaxTextArea copied to clipboard
Handling of slash and ctrl-slash shortcuts
After digging through the code a bit, as well as the forums, I found that there are some issues with handling the ctrl-slash shortcut to toggle comments, and slash end-tag completion. In the current code, this means that on Linux, the ctrl-slash shortcut is disabled by default. In the Arduino IDE, we have re-enabed the ctrl-slash shortcut through a menu item, and there is a hack in place that consumes all KEY_TYPED events that have control pressed (but are not control sequences themselves). This hack prevents the problem where typing ctrl-slash will trigger both the toggle comment KEY_PRESSED shortcut, but also the KEY_TYPED end-tag completion shortcut (which inserts a / character).
I'd like to get rid of this hack, so I'll likely just disable the end-tag completion (which we don't really need anyway). But thinking about his, I also wondered if no cleaner solution is possible, which is why I'm opening this ticket.
I think that the actual problem here is the way that the end-tag completion is bound. It currently consumes the KEY_TYPED event for /. It then inserts a literal / character, to emulate normal insertion behaviour, and continues to check to see if the tag should be closed. Because matching of keybindings (by swing) for KEY_TYPED events does not include any modifier keys, this also matches a ctrl-slash keypress.
If not for this handling of the KEY_TYPED event, the ctrl-slash handling would be perfectly fine - a control-slash (or control-anything) keystroke does not normally insert any characters. On Windows and OSX, this works, since ctrl-slash does not trigger any KEY_TYPED event. On Linux, however, ctrl-slash does trigger a KEY_TYPED event, causing the end-tag completion handler to insert a slash when pressing ctrl-slash to toggle comments.
This leads me to believe two better approaches might be possible:
- Instead of binding the KEY_TYPED event for /, bind some later event (e.g. after the / was inserted, so ctrl-slash automatically doesn't trigger this). I'm not sure what this would be - listening for document changes is probably wrong, since that also responds to programmatic changes. I haven't figured out what part of the swing code actually decides to insert slash, but not control-slash, but this might be related to special "input methods" I found mentioned in the code. Also, I'm not sure how well this would integrate with the existing keybinding and macro capturing infrastructure (though I'm not so sure it needs to, since the / keybinding is a bit special anyway).
- When handling KEY_TYPED for /, check if ctrl was pressed during the event, and if so, simply return.
ActionEvent
has agetModifiers()
method that can be used for this. For good measure, this should probably also check for the alt modifier, since pressing alt plus a key normally doesn't insert it either (but don't return on any modifiers, since that would probably break on keyboards where you need to press shift to insert a /).
I think the first suggestion is more elegant, but also has some problems to overcome. The latter is more of a hack, but I think it would work and is easy to implement. In fact, I just tried it, and it seems to work just as well as the current hack. I couldn't actually manage to get the / close tag stuff works, since I couldn't find how to enable that (seems it is disabled at the TokenMaker by default, but not sure how to access that).
With this change applied, both toggling comments and inserting slashes works as expected on QWERTY. On QWERTZ and AZERTY, inserting slashes works normally, but not toggling comments (since the / is made using a shift, the / keycode is never sent, but some other keycode, colon or seven along with a shift modifier). In the end this really boils down to the java keybinding infrastructure being not quite ready to deal with alternative layouts.
If you like, I can prepare a pullrequest?
Pull requests are always welcome, though I am a little hesitant to revisit that code, since I recall it was quite touchy for awhile, and I didn't always have access to systems that exhibited problems, so I relied on other folks to verify for me.
@bobbylight The error shows up in the all arduino releases not using US keyboard layout. So it affects and irritates a huge amount of people out there. It would be a great improvement, if someone could put some effort to solve this. Please! Thanks Armin
I originally volunteered to provide a PR, but haven't been working with this code since then and this does not really have priority for me atm, so don't expect anything from my side for now...