Community
Participate
Working Groups
Currently it's very difficult to reuse the Mylyn WikiText editor without using internal API. An editor can be assembled without using internals by using MarkupSourceViewer and MarkupSourceViewerConfiguration, however there are several concerns that should be addressed in order to create a full-featured editor that are not readily reusable without significant effort and/or use of internals: * outline * preview * non-resource editor input * enabling commands * integration with services (IFocusService, IContextService, IHandlerService) With this enhancement Mylyn WikiText would provide reusable components and API that facilitate creating an editor with minimal effort, supporting flexible configurations such as: * multipage editor integration * form integration * with or without outline * with or without preview ** flexible preview configuration, such as tab-based, stack-layout, toggle action/command etc. The implementation should consider making it easier to consume Mylyn WikiText in an RCP environment, see bug bug 273013
E.g. I would like to use WikiText in the comment editor for Subversive because the Trac Source browser shows markup.
This sounds good, a reusable wiki editor.. I'm currently maintaining a wiki online editor for Trac wikis [http://trac-hacks.org/wiki/WikiEditorForEclipsePlugin] and it was in my plans to replace current text editor and integrate it with mylyn WikiText... so a flexible reusable text editor would be just great On top of the list of features you already got I would add a flexible way to handle other IEditorInput different that IFileInput editor as some implementations may not be backed up by regular physical File, for example when you save changes online or just keep a local cache.. As far I saw for the current implementation assumes quite often that there is an actual File behind the editor and it didn't work when it didn't. I've started some testing efforts by extending the internal MarkupEditor (yes I know it's internal) just to override doSave method and the way that it loads the prefered markup dialect and found that most of it worked fine (syntax highlight, outline, code assistance, ...) but a few things didn't: * Source code Folding * Preview tab * WikiText context menu actions (generate docbook, html ..) didn't show up but those same did work as expected if the extended editor was open using a FileEditorInput in the same way. I'm really looking forward a feature like this to be implemented and to give a hand wherever it makes sense I'll keep in touch.. Regards Ivan
(In reply to comment #2) > I'm currently maintaining a wiki online editor for Trac wikis > [http://trac-hacks.org/wiki/WikiEditorForEclipsePlugin] and it was in my plans > to replace current text editor and integrate it with mylyn WikiText... so a > flexible reusable text editor would be just great Thanks for the heads-up on your project. It looks very exciting. It's difficult to provide a good editor API that is easily consumed and extensible without exposing too much in the way of internals. By getting involved on this feature you can help to ensure that WikiText provides something that meets the needs of your project. > On top of the list of features you already got I would add a flexible way to > handle other IEditorInput different that IFileInput editor as some > implementations may not be backed up by regular physical File, for example when > you save changes online or just keep a local cache.. Agreed, it's priority for this feature to avoid references to IFileEditorInput if possible. As you mention this will allow the use of non-resource based inputs, but also hopefully work towards reducing dependencies on IDE, as per bug 273013. > ...snip... > I've started some testing efforts by extending the internal MarkupEditor (yes I > know it's internal) just to override doSave method and the way that it loads > the prefered markup dialect and found that most of it worked fine (syntax > highlight, outline, code assistance, ...) but a few things didn't: That's great. My current plan is to leave the internal MarkupEditor as-is, as it does a good job within the IDE. I'm in the process of creating an all-new editor implementation with will not be internal. I'll attach the work in progress to this bug as soon as I can so that people can collaborate on the new API. > * Source code Folding Is code folding an important feature? > * Preview tab Keep in mind that this feature is about providing API to facilitate creating an editor -- so the choice of where/how/if to provide a preview will be up to users of the new API. Tabs will be possible, but not mandated. > * WikiText context menu actions (generate docbook, html ..) didn't show up These generate actions are resource-specific. To have them appear elsewhere will require some integration work, and is certainly not part of this enhancement. > but those same did work as expected if the extended editor was open using a > FileEditorInput in the same way. > > > I'm really looking forward a feature like this to be implemented and to give a > hand wherever it makes sense Great to hear! I look forward to your involvement and contributions.
(In reply to comment #3) Hi David, regarding the code folding feature, the preview tab or even the export functionality, it is not that much about if they are important or they would be optional (I understand what you mean), it's just that they currently don't work because the editor expect is actual File backing up and they probably should be resource agnostic, even the generate action, over the editor, might be as well resource agnostic just asking for an output filename (that doesn't belong here, I know) > It's difficult to provide a good editor API that is easily consumed and extensible > without exposing too much in the way of internals. > [...] > My current plan is to leave the internal MarkupEditor as-is, as > it does a good job within the IDE. I'm in the process of creating an all-new > editor implementation with will not be internal. I'll attach the work in > progress to this bug as soon as I can so that people can collaborate on the new > API. Well, there is no need to expose all the implementation details to expose the functionality that is already built You already have all the building blocks to create a rich featured editor I don't think you will need to create an /all-new/ implementation, maybe just creating an (abstract) editor class exposing some template methods that can be overridden by subclasses and a way to assemble the editor components using a few high level classes (SourceViewer, Preview control, Outline ..) that should be also configurable/extensible. So people can use/extend that one or assemble the part at their own.. There is no need to expose from those component classes their implementation details, that are already in internal, it is just a matter of exposing the minimal/necessary API deciding what functionality can be configured programatically, which methods are public so they can be overridden and which would be private/final.. and provide all necessary hooks for clients to add functionality Something like, e.g, a SourceViewer class that for example allows overriding: - strategy for knowing the wiki dialect to show and configure many other properties: - quick outline or not? - code assistance? - cheat sheet or not? - show in targets list - ... I think it's possible with the code already implemented to extract a public API, that can easily be used to with a minimum effort create an editor like the current MarkupEditor (or a different one for that matter..) I don't see the need to write an all-new implementation, that is also the reason I commented about those things above that have found when testing the current implementation with non-resource inputs, so you can know about those if reusing some code.. I hope this wasn't too long, and as said before I am looking forward this feature and also to contribute, how do you say in English?, my "grain of sand" ... Regards Ivan
Created attachment 151444 [details] initial cut at the new API Attached an initial cut at the new API. Potential users of this API are encouraged to provide feedback to ensure that it meets their needs.
Created attachment 151445 [details] mylyn/context/zip
(In reply to comment #5) > Created an attachment (id=151444) [details] > initial cut at the new API > > Attached an initial cut at the new API. Potential users of this API are > encouraged to provide feedback to ensure that it meets their needs. For my side it looks alright as it fits my need to create a custom editor without using internal classes I'm still missing code assistance and source code folding which are both nice to have, but I guess the could still be added to the API Thanks Ivan
There is also missing the updateOutlineSelected functionality as it is not possible to add it by extending the editor Thanks again Ivan
Created attachment 151857 [details] how to enable tracing in your launch configuration (In reply to comment #7) > For my side it looks alright as it fits my need to create a custom editor > without using internal classes Great! > I'm still missing code assistance and source code folding which are both nice > to have, but I guess the could still be added to the API You're right: folding is missing. Content assist should be there. It's activated with the source context @org.eclipse.mylyn.wikitext.ui.editor.sourceViewer@. I suggest that you enable tracing options. I've attached a screenshot to show how to do that.
(In reply to comment #8) > There is also missing the updateOutlineSelected functionality as it is not > possible to add it by extending the editor I'm not sure what you mean here. Can you elaborate?
(In reply to comment #10) > (In reply to comment #8) > > There is also missing the updateOutlineSelected functionality as it is not > > possible to add it by extending the editor > > I'm not sure what you mean here. Can you elaborate? I meant the functionality that selects the related outline item when you are editing a given section of the wiki page, which was managed by the method 'updateOutlineSelection()' in the original MarkupEditor (but I didn't quite write the right name) I guess it should be no problem to include it, as it is quite useful most fields are private so this can not be added by extending the editor Regards Ivan
(In reply to comment #11) This functionality has been implemented a little differently from the original MarkupEditor: content outlines should listen for property changes @WikiTextSourceEditor.PROP_OUTLINE@ and update accordingly. Take a look at @org.eclipse.mylyn.wikitext.ui.editor.DefaultWikiTextSourceEditorOutline.editorPropertyChanged(Object, int)@, it should be doing exactly what you describe. If it's not working correctly or if it doesn't meet your needs please let me know.
(In reply to comment #9) > > Content assist should be there. It's activated with the source context > @org.eclipse.mylyn.wikitext.ui.editor.sourceViewer@. I suggest that you enable > tracing options. I've attached a screenshot to show how to do that. Well, I can not get to work code assistance, I created a Test editor that just extend the new editor to set the wiki markup on the constructor, so minimum chances of interferences there, and assigned to a .testwiki extension and still no code assistance, while in the original editor it's still working.. I see that templates are loaded properly but still don't know why it doesn't show up Regarding tracing options, do you know why may it be that mylyn plugins to not show in the Tracing options list? (In reply to comment #12) > (In reply to comment #11) > > This functionality has been implemented a little differently from the original > MarkupEditor: content outlines should listen for property changes > @WikiTextSourceEditor.PROP_OUTLINE@ and update accordingly. Take a look at > @org.eclipse.mylyn.wikitext.ui.editor.DefaultWikiTextSourceEditorOutline.editorPropertyChanged(Object, > int)@, it should be doing exactly what you describe. > I see, but now navigating with the cursor is not enough to select the current section in the outline, you need to actual *edit* the text to get the outline selection updated.. which may be or may be not convenient in some cases.. I liked more the old implementation where just navigating the wiki text selected the current outline section.. Regards Ivan
(In reply to comment #13) > Well, I can not get to work code assistance, > I created a Test editor that just extend the new editor to set the wiki markup > on the constructor, so minimum chances of interferences there, and assigned to > a .testwiki extension and still no code assistance, while in the original > editor it's still working.. Is there any chance you can attach your test case? If you can, I'll take a look. > Regarding tracing options, do you know why may it be that mylyn plugins to not > show in the Tracing options list? Is there something specific that you'd like to trace? If so please file an enhancement request. > I see, but now navigating with the cursor is not enough to select the current > section in the outline, you need to actual *edit* the text to get the outline > selection updated.. > which may be or may be not convenient in some cases.. > > I liked more the old implementation where just navigating the wiki text > selected the current outline section.. Agreed. It was my original intention to include that functionality but somehow it got missed. Thanks for your feedback!
Created attachment 152169 [details] patch updated to address outline selection issue With this updated patch the outline selection follows the user's navigational context
Created attachment 152170 [details] mylyn/context/zip
Created attachment 152180 [details] Code Assistance Test Editor Hi David, I've attached the small test that creates a very simple editor registered to open .testwiki files You can create a file with Trac markup and .testwiki extension, to see if you can get code assistance with it for me it doesn't work Regards Ivan
Created attachment 152184 [details] screenshot of test editor I've run your patch as-is and it works for me! For a start, can you check your *Error Log* view to see if there are any exceptions?
(In reply to comment #18) > Created an attachment (id=152184) [details] > screenshot of test editor > > I've run your patch as-is and it works for me! For a start, can you check your > *Error Log* view to see if there are any exceptions? Yes, you are right there must be something wrong on my setup, sooner or later will show up. One more thing, probably this does not belong here but, the syntax highlighting does not provide visual feedback for hyperlinks but in the tasks editor, iirc, it does highlight them.. is there a way or workaround to fix this? Thanks again Ivan
(In reply to comment #19) > One more thing, probably this does not belong here but, the syntax highlighting > does not provide visual feedback for hyperlinks but in the tasks editor, iirc, > it does highlight them.. Please file a separate bug to track this issue.
Patch has been committed with minor changes. If any issues come up with the new API please file a separate bug.
