Community
Participate
Working Groups
This bug tracks suggestions/enhancements about the shape of the "editorActions" extension point.
I've run into a few things while generating real "commands" from this extension point: - we should have an id for the extension that is namespace qualified. Then we can use that id for the command id. As it is now, i'm using info.name which is not guaranteed to be unique and the command service needs it to be unique. (As do the editor actions.) - we should have a tooltip
Paul, in case the word "editorActions" has you shivering... The extension point in this bug is about very specific extensions/commands that plug-ins can contribute that operate against the editor text. When we read these extensions, they get turned into "commands" with a handler generated by us that is refined for the editor case.
see also bug 337867. Where it makes sense we should make fileActions and editorActions consistent (such as the "info").
from bug 359414: Query1) What I want to do is to relate an action to a particular file type. For example, the "FORMAT JS" action probably wouldn't make sense for a HTML file. I would like to limit the appearance of that action to a file with .js extension. Can I do that now already? (In reply to comment #3) > Where it makes sense we should make fileActions and > editorActions consistent (such as the "info"). The file commands extension defines "validation properties" which let you decide which files a command applies to. I don't see a reason why we shouldn't allow the same thing in editor actions.
I'm playing around with a "create gist" plugin and it would be nice to know the name of the file when running the service implementation. In the case of a gist, I might want to name the gist file using the name of the orion file, something like: "Snippet from foo.txt"
fixed. I added the following to the editor.command extension: - you can specify an id (uses name if no id specified for backward compatibility) - you can specify a tooltip - you can specify validationProperties in the same way you do in file commands. - the service implementation now passes a fourth parameter, the full path name of the resource being edited. Updated the "toRGB" plugin to be valid for only *.css files and to provide a tooltip. Existing plugins can run unmodified, but we may want to look at our editor plugins and update them. For example: tooltips, maybe Format JS should just appear for *.js, etc. The validation properties code is shared by fileCommands and editorCommands in a new utility in extensionCommands. I suspect we'll want to beef up and more formally specify how validationProperties work. cc'ing john and marking as enhancement, as I think this will be 0.4 N&N for plugin developers.
