| Summary: | running a file-based command from the editor | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ken_walker, mamacdon |
| Version: | unspecified | ||
| Target Milestone: | 3.0 M1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
cc'ing Mark. Curious on your opinion, which seems better to you...starting to show nav commands in the editor or extending the meaning of editor commands to include non-content altering stuff? I talked to Mark about this a big. We agreed it makes more sense to allow orion.navigate.command items to appear in other places besides editor rather than change the meaning of editor actions. Reasons include: - editor actions require sending the whole file buffer and usually what you want for these kinds of commands is the file metadata. We currently don't supply metadata in editor actions - it seemed hacky to extend editor actions to have a property that means "don't update the text, I already did the work" - Ken commented that the command he wanted to implement would probably belong in navigator as well. So I've implemented a new property on "orion.navigate.command" called "showGlobally" If the command has "forceSingleItem" = true and "showGlobally" = true then the editor will append the command onto the editor toolbar and supply the file metadata. Tested and added a new command, sample.commands.sample4, in the sampleCommandsPlugin.html to demonstrate this. See line 49. I have a fix but can't push due to eclipse.org lockouts. Will update this bug when I've pushed. |
Ken has a scenario where he'd like to run a file-level command from the editor. This command just runs code based on the file metadata and optionally opens a link. So conceptually it's more like a file command ("orion.navigate.command") than "orion.edit.command" which lets you change the editor buffer. This could be implemented today as a related link but conceptually the command is a first class toolbar command and should be visible with the other editor actions. We could alter the spec for "orion.edit.command" to also include non-altering commands, but this doesn't quite seem right. We already have a case where we run some file commands (such as make favorite) in the editor toolbar. I think we want a way for contributors of "orion.navigate.command" to say if a file-level command should appear in the editor. I'm not sure if we want to leave it up to the command contributor to decide this, but I can't think of a better way at the moment. So first try will be a property on orion.navigate.command that specifies it should also be visible for the editor. A possible downside is we'll then need to run the code in the editor that processes all navigator commands, but that still seems conceptually better than redefining orion.edit.command to run random code. I may change my mind once I get in the code....