Community
Participate
Working Groups
The "Toggle Highlight" button for various editors is located in the toolbar of the "Editor Presentation" action set. The Generic Editor uses its own toolbar instead, causing the button to "jump around" from a user's perspective.
I originally wanted to fix this as part of bug 528172, but I couldn't figure out how. I tried using variations of locationURI="toolbar:org.eclipse.ui.edit.text.actionSet.presentation" for the menu contribution together with an enablement filter that checks that the ActionSet is enabled (see [1]). However, this approach always seems to insert an additional separator into the toolbar along the button. It looks to me like there isn't a way to achieve the exact same result as contributing an action to an action set with menuContributions. Does anybody maybe have any pointers?
[1] See "Contribution visibility" section in https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fworkbench_cmd_menus.htm
I'm sorry, I didn't get it: all text editors are fine with the current state, except generic one? Why? What is special in the generic editor toolbar contribiton? May be a screenshot would help?
Created attachment 271896 [details] Toolbar Contribution comparison Sorry for the bad explanation. The attached screenshot shows the issue. Generic Editor contributes the "Mark Occurrences" toolbar button to its own toolbar section, while other editors (Java, Ant, Javascript, DLTK, C/C++, PHP) contribute it to the "Editor Presentation" section, to the left of the "Word Wrap" button. The result for the user is that the button "jumps around" when switching editors. It was a bit difficult to figure out how to fix this, because the other editors all contribute legacy Actions into the legacy "Editor Presentation" ActionSet, whereas Generic Editor makes a "new-style" menu contribution, which makes it a bit difficult to get the exact same button placement. But I've got a solution now, Gerrit change incoming.
Pushed https://git.eclipse.org/r/113354 This more or less places the toolbar button at the same position as other editors do. "More or less" because of a small technical difference: Others, using the old ActionSet contributions, place the button just to the right of the invisible "Presentation" group marker. It seems that this can't be achieved with a menuContribution (the button will always end up at the rightmost position of the group), so this places it immediately to the left of the marker. This shouldn't be a problem unless someone makes additional contributions to the "Editor Presentation" section that are active when the GenericEditor is active AND are placed at the beginning of the "Presentation" group. I don't think this is very likely - and in fact only possible with the old ActionSet method. I'll file an e4 bug tomorrow to get the differences between ActionSet contributions and MenuContributions sorted out.
Path for this is actually causing bug 534325. It seems like the actionSet do persist a lot of state about buttons, so the commands that are added in the actionSet toolbar with the "hack" you identified actually leads in the button being persisted in the actionSet state, then added again with the command framework and again and again, once per startup of the IDE. I'm going to revert the part about adding it to the presentation toolbar close to other actions to fix it. If you want to improve this situation, then I think the work should happen in bug 527007 and in Platform to replace the actionSet by regular commands and menu contributions, that are much more flexible and do not persist buttons.
(In reply to Mickael Istria from comment #6) > If you want to improve this situation, then I think the work should happen > in bug 527007 and in Platform to replace the actionSet by regular commands > and menu contributions, that are much more flexible and do not persist > buttons. Alright. I'll have a look at migrating the actionSet to commands. I'll probably not get around to it for M7 though. And I guess since the button is in the correct toolbar now and the rest will happen in bug 527007, we can close this now...
