Community
Participate
Working Groups
OS X, GNU Readline, Emacs, and many other applications/platforms support a basic set of useful keyboard navigation meta-sequences, such as: * CTRL-E - go to end of line * CTRL-A - go to beginning of line * CTRL-F - go forward one character * CTRL-B - go backward one character * CTRL-H - delete backward from cursor one character * CTRL-W - delete backward from cursor one word * CTRL-U - delete backward from cursor to beginning of line * CTRL-K - delete forward from cursor to end of line * Up-arrow - go to beginning of line if first line of text * Down-arrow - go to end of line if last line of text .. and so on. Mylyn's wikitext task editor does not support these sequences/shortcuts and it results in a significantly worse experience than the JIRA web application offers. The web application does not actually do anything special, it simply allows the OS X support for these sequences to pass through when typing in a textfield. It's understood that some of these commands will have collisions with existing keyboard shortcuts (e.g.: CTRL-H) I would set this up myself as a custom configuration in Preferences->Keys, but many of the movements/commands mentioned above are not even listed there. Please consider providing such support, thanks.
Additionally: * CTRL-D - delete forward from cursor one character Please note that these sequences already work in other areas of Eclipse. For example, in the Search dialog, CTRL-E, -A, -D, -H, -B, -F, and -K all work. Up arrow works as described, though Down arrow does not (brings up search history, which is understandable). Clearly these commands can be supported within the Eclipse platform. Is there anything that would keep WikiText from following suit?
Thanks for the bug. It's not clear from your bug if you're asking for new commands that emulate the platform, or if the bug is about existing Eclipse text editing commands not working. The WikiText editor (and WikiText within the task editor) should support all of the standard key bindings that Eclipse offers in text editors. Pressing CTRL+Shift+L (Command+Shift+L on a mac) should give you a list of what's available. I've tried out a few and they work fine for me. Please verify that your keybindings are setup as you would expect, and try them out in the Eclipse text editor (open a *.txt file in Eclipse). If they're working there but not in the task editor, please let me know. When responding please identify text editing commands by their name as presented in the Eclipse preferences under *General -> Keys*
The issue I'm reporting is that commands I would expect to work do not work in mylyn task editor text area input fields. For example, I'm typing this inside of mylyn's task editor, in the 'New Comment' text area right now. The cursor is following the words as I type them, and I would expect that if I type 'ctrl-a', my cursor would jump to the beginning of the line I'm on. Just tried it -- and it doesn't work. However, if I move focus to the "QA Contact:" input field, and type a few characters, I can then type 'ctrl-a', 'ctrl-e', 'ctrl-b', 'ctrl-f' -- all these commands work as expected. Why don't they work in text areas? It seems that Mylyn is trapping these commands somehow.
The Mylyn task editor new comment field and description field both behave the same as other text editors in Eclipse. Eclipse provides keybindings to platform commands in this field. Other fields (such as the QA Contact input field) are simple native widget with no additional functionality provided by the Eclipse platform. We can look at two things here: # is the task editor field working correctly with the keybindings and commands provided by the Eclipse platform # are there additional keybindings and commands that could be added to make the editor behave more like a simple native widget
Hi David, Understood regarding your comments above, and I'm not really sure whether it's option (1) or (2) that needs to be addressed. Here's what I do know: 1. File->New->Class 2. In the 'Name' field, type 'foobar' 3. press ctrl-a 4. notice the cursor jumps to the beginning of the line 5. press ctrl-e 6. notice the cursor jumps to the end of the line the behavior above is as expected with regard to my initial description for this bug. These commands do not work in wikitext editor text area input fields, and for those that prefer the keyboard to the mouse, this significantly degrades usability as compared to the browser. Again, I realize that this is probably not a 'wikitext thing' per se, but probably a shortcoming of the platform. Is there there some UI sugar wikitext can sprinkle on top of these widgets to get them to behave properly? Thanks.
I use Emacs bindings in the Eclipse Platform. Key bindings mentioned above, such as ctrl-e bound to the "Line End" command to navigate to the end of a line of text are configured and do work in regular editors but not in wikitext editor fields. It looks like the wikitext editor doesn't respect the Eclipse platform key bindings.
Thanks for the bug. I've managed to reproduce here and will look into it.
This is more complex than it seems at first glance: These commands have a keybinding however they have no command handler in the task editor. In the file editor they have a command handler because @AbstractTextEditor.createActions()@ creates actions and @MarkupEditor.setAction(String,IAction)@ registers a command handler on @IHandlerService@ for the editor site. This all works because @MarkupEditor@ extends @AbstractTextEditor@. In the case of the task editor, we're using a @SourceViewer@ which doesn't activate any actions. To fix tihs, @MarkupTaskEditorExtension@ or perhaps the task editor itself will have to register some command handlers for common editing commands, such as those registered in @createActions()@. Many of these can be found in @org.eclipse.ui.texteditor.ITextEditorActionConstants@. Steffen what are your thoughts on this: should the task editor be registering these command handlers, or is that better done by the @MarkupTaskEditorExtension@? It's not clear to me where the responsibility should lie since the @IHandlerService@ belongs to the editor site.
Created attachment 177626 [details] mylyn/context/zip
Created attachment 177980 [details] patch demonstrating candidate fix Attached a patch demonstrating a candidate design for fixing this problem. Registers a single command handler for the 'delete line' command (for me this has a keybinding of CTRL+D). For this fix to work we'll need to add handlers for all of the common platform text commands.
Created attachment 177981 [details] mylyn/context/zip
That seems like a lot of work and code to maintain to handle all the different commands that text editors support. Have you considered letting the task editor page implement ITextEditor instead to be able to reuse the text editing actions provided by platform? Not sure if that makes any sense though.
ITextEditor itself involves a lot of code, and has many associated interfaces ITextEditorExtension, ITextEditorExtension2, etc. Also looking at some of the action class implementations, I've seen casts to AbstractTextEditor. I agree that it's a code maintenance problem, but at this point I don't see that we have any better options.
If we decide to proceed with this it would be nice to put it into the Mylyn commons so others who embed source viewers in non text editors can reuse the command bindings.
Sounds like an unpleasant bit of work, but I'm so glad to see this is being taken seriously. Thanks for the effort.
(In reply to comment #15) > Sounds like an unpleasant bit of work, but I'm so glad to see this is being > taken seriously. Thanks for the effort. No problem Chris, this kind of thing is important. The whole idea is that using WikiText should result in a better editor (not worse). (In reply to comment #14) > If we decide to proceed with this it would be nice to put it into the Mylyn > commons so others who embed source viewers in non text editors can reuse the > command bindings. Agreed, though there's no standard way to get to a TextViewer (SourceViewer) from the StyledText. Currently this is done in a WikiText-specific manner (using @Widget.setData(ISourceViewer.class.getName(),viewer)@). Maybe that's good enought for Mylyn commons?
> (In reply to comment #14) > > If we decide to proceed with this it would be nice to put it into the Mylyn > > commons so others who embed source viewers in non text editors can reuse the > > command bindings. > > Agreed, though there's no standard way to get to a TextViewer (SourceViewer) > from the StyledText. Currently this is done in a WikiText-specific manner > (using @Widget.setData(ISourceViewer.class.getName(),viewer)@). Maybe that's > good enough for Mylyn commons? Yes, that certainly works and CommonTextSupport does it exactly like that. We could probably extend that class to handle other actions as well as it already has support for two of the actions specified in ITextEditorActionDefinitionIds.
Created attachment 179419 [details] patch that adds common delete/cut commands
Created attachment 179420 [details] mylyn/context/zip
There are some shortcomings that make me question whether CommonTextSupport can be used in this case: # CommonTextSupport requires an IHandlerService, which is unavailable to AbstractTaskEditorExtension (we could make it available via IAdaptable) # CommonTextSupport does a whole lot of things with other actions/handlers which are not needed in this case I've attached a patch that adds common delete/cut commands.
Steffen, any comments/questions/objections related to the current patch?
The approach looks fine. I would still prefer to make this available in the commons and through code rather than XML to make it easier to reuse. If that requires extending or changing CommonTextSupport please free to do that but if you would rather keep the implementation in WikiText that seems reasonable, too.
Created attachment 181533 [details] patch that adds several handlers to o.e.m.commons.ui Steffen, how about this? It moves the handlers to @o.e.m.internal.provisional.commons.ui.commands@ and also modifies their applicability for both @ITextViewer@ and @ISourceViewer@. Registering the handlers remains in the XML.
Created attachment 181534 [details] mylyn/context/zip
Looks good to me.
Committed the patch. This fixes the problem with the following commands: * Cut Line * Cut Line to Beginning * Cut Line to End * Delete Line * Delete Line to Beginning * Delete Line to End leaving this task open since other commands are not yet implemented.
David, do all of the common commands that we want to have need to be enumerated? Some other ones that I would like to see are move block up/down (alt + up or down arrow on windows).
All of the Eclipse platform supported commands have been implemented to my knowledge. Removing the target milestone since there are many others requested on this bug. We now have a good architectural solution for implementing new commands, patches welcome.
I'm marking this resolved as per comment 10. Please raise separate requests for commands that are still missing.
*** Bug 331599 has been marked as a duplicate of this bug. ***
(In reply to comment #29) > I'm marking this resolved as per comment 10. Great. Don't you mean per comment #26?
@David, @Steffen, Great news that this is complete. Thanks both for your work. Is this available via a nightly update site somewhere? Or perhaps it'll be available today (Wednesday) via the weekly update site at http://download.eclipse.org/mylyn/snapshots/weekly ? Thanks, - Chris
Chris, this is available now as part of Mylyn 3.5 and on the weekly site. Please give it a go and let us know how it works out for you.
@David, I just sync'd up against the weekly site, got 20110404-105 and the bindings aren't there. Perhaps the very latest weekly hasn't shown up yet? (20110413?) Thanks, - Chris
Chris, that's odd... the bindings have been in there for awhile. The commands and bindings that are listed in comment #26 are those that you should be able to use. Can you indicate which commands you're trying to use, which key combinations should trigger them, and verify that the command is listed with the expected settings under *Preferences -> General -> Keys*?
