Community
Participate
Working Groups
HEAD All the toogle comments actions should be unified into one command that's used in all kinds of editors. Currently, there are 6 "Toggle Command" entries in the Keys dialog, which is simply too many. Same for Add/Remove Block Comments. Bug 192045 and bug 149817 already discussed this. If you don't want to have such language-centric commands in the existing text plug-ins, then it's probably time for a new org.eclipse.ltk.text plug-in.
> a new org.eclipse.ltk.text plug-in. There's already the inactive ltk.ui plug-in.
It seems a common plugin for low-level "source" unifying functions that are slightly above "text" but, below any specific language would be useful. I thought there already was (an active) one. I'm wondering, what else should go in there ... Format? Go to Matching character? Is the keys-commands dialog the only thing to be effected (from end-users point of view?). Thanks,
Yes, for the user the only benefit will be to see only three entires as there are currently three different bindings registered.
> Yes, for the user the only benefit will be to see only three entires as there > are currently three different bindings registered. It's not only about seeing a single entry, it's also about having to change only a single entry. More benefits could be that the commands show up in the menu (e.g. toggle comment is not enabled in the Source menu for properties file editors), and that language implementors are encouraged to support the basic editing commands a user would expect from an Eclipse editor. More Java commands that could be generified: Shift Left, Shift Right, Correct Indentation, 4 Expand Selection To > * commands, Go to Matching Bracket, Toggle Mark Occurrences, Rename in File, Quick Outline, Quick Hierarchy, ...
Agree that there should be a common implementation for toggling comments action. Even it's well known that writing a common code is three times harder, I think it should be done, because the current situation looks just painful. A lot of copy-pasted code in different projects. For example see the link - the projects with their own implementation of the action.: http://www.google.com/codesearch?hl=ru&start=10&sa=N&q=eclipse+ToggleCommentAction+lang:java And for example compare the code in the links bellow (the code isn't equal but very very similar). And the problem that I'm going to make another probably slightly modified version for my own project... Or there's a better solution exists I do know nothing about? http://www.google.com/codesearch/p?hl=ru#01LBHk8tQbw/plugins/com.aptana.ide.epl/src/com/aptana/ide/ui/editors/ToggleCommentAction.java&q=ToggleCommentAction%20lang:java&sa=N&cd=6&ct=rc http://www.google.com/codesearch/p?hl=ru#4NvyNs443EQ/trunk/veloeclipse/src/com/googlecode/veloeclipse/vaulttec/ui/editor/actions/ToggleCommentAction.java&q=ToggleCommentAction%20lang:java&sa=N&cd=2&ct=rc http://www.google.com/codesearch/p?hl=ru#vh1H5LlsU7g/org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/editor/ToggleCommentAction.java&q=ToggleCommentAction%20lang:java&sa=N&cd=1&ct=rc http://www.google.com/codesearch/p?hl=ru#SshE6Z6fnWc/archives/vendors/eclipse-platform/plugins/org.eclipse.jdt.ui/src/org/eclipse/jdt/internal/ui/javaeditor/ToggleCommentAction.java&q=ToggleCommentAction%20lang:java&sa=N&cd=11&ct=rc
*** Bug 514926 has been marked as a duplicate of this bug. ***
The links provided above in this bug are not working. Mickael, in bug 514926, proposed to work at platform.text level to - re-define a command to toggle comments and bind it with Shift+Ctrl+C Then, the specific editors should be able to add a handler. Questions: 1. Do you think this is feasible? 2. Where should we look for an example ? (Is there any example of specific editors redefining platform.text commands?) (I'm also dding interested people in c/c)
(In reply to Patrik Suzzi from comment #7) > Questions: > 1. Do you think this is feasible? Totally. > 2. Where should we look for an example ? > (Is there any example of specific editors redefining platform.text > commands?) It's not redefining the command, it's only giving an handler to an existing command. A few of the many examples providing this pattern (command defined in some plugin, but handlers provided by other projects): * org.eclipse.debug.ui.commands.ToggleLineBreakpoint (defined by debug, provided by JDT, JSDT, PDT, whateverDT) * org.eclipse.ui.edit.copy provided by org.eclipse.ui and implemented by org.eclipse.ui.ide and most tree-based or diagram-based editors/views.
I'd be happy to solve this problem. I just want to give some pointers to look at: https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00025.html https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00023.html https://wiki.eclipse.org/Languages_Tools_Factorization https://www.eclipse.org/org/langsymp/ If we want to start to tackle this, we need to add an ltk.ui bundle early in 4.8 and make sure everyone has time to migrate to the new generic commands.
See also bug 415563.
Isn't the requirement for a new bundle a bit overkill? Would it be that bad to have the command defined in the org.eclipse.ui.workbench.texteditor bundle? Indeed, many text editors may not need such command, but would it harm to provide the definition anyway?
(In reply to Mickael Istria from comment #11) > Isn't the requirement for a new bundle a bit overkill? Would it be that bad > to have the command defined in the org.eclipse.ui.workbench.texteditor > bundle? Indeed, many text editors may not need such command, but would it > harm to provide the definition anyway? Yes, it would not only be bad but a no go and layer breaker. -1000.
(In reply to Mickael Istria from comment #11) > Isn't the requirement for a new bundle a bit overkill? I'd expect more language specific things to go/move there over time.
> I'd expect more language specific things to go/move there over time. [Preamble: I'm not trying to force you to change your mind there, the comments and questions below are more meant to help me agreeing with you] I'm actually curious about where we should place the line between text and language. Current text editor already allows to have completion, hover and other stuff which involves understanding some semantic of the text; making this text very close from being a language. It's not clear to me how a "comment" command on a text is more language-specific than a "hover" one. Overall, I'm wondering if assisted text edition and language edition are really different layers (that's a philosophical question I'd be glad to discuss with you next time we meet in person). Extra layers increase complexity. It has to come with added-value to be profitable; here I currently fail at seeing the added value of an extra plugin for such operations.
(In reply to Mickael Istria from comment #14) > > I'd expect more language specific things to go/move there over time. > > Current text editor already allows to have completion, hover and > other stuff The framework allows clients to add those things if desired. Commands are different. Even if not used by anyone they will appear on the Keys preference page. Also note that we already have the LTK layer for the refactorings.
Removing target milestone for all bugs that are not major or above.
> Removing target milestone for all bugs that are not major or above. Of course I meant "major or below". Sorry for the noise!
