Bug 549348 - [LTK] a common "Format" command definition
Summary: [LTK] a common "Format" command definition
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.12   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 521986
  Show dependency tree
 
Reported: 2019-07-17 10:22 EDT by Mickael Istria CLA
Modified: 2021-01-21 07:02 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mickael Istria CLA 2019-07-17 10:22:34 EDT
Format is a common operation provided by most language-specific tools. We should provide a common command definition and shortcut for it, and let extenders plug their specific handlers.
Comment 1 Christoph Laeubrich CLA 2021-01-21 06:26:10 EST
Just an example that I recently noticed:

I have created a custom content type for the generic editor and now want to provide formatting.

Right-Click on the Editor > Source 

shows an item "Format" with the usual Shortcut but it is grayed out. Would be good to have a convenient entry point where one can define the content-type + a handler with a method with the usual parameter:

> void formatDocument(ITextViewer viewer, int offset)
Comment 2 Mickael Istria CLA 2021-01-21 06:31:32 EST
(In reply to Christoph Laeubrich from comment #1)
> shows an item "Format" with the usual Shortcut but it is grayed out.

It need to be investigated where this item is coming from. I guess it's coming from LSP4E and it shouldn't be available in the Generic Editor unless there is a language server and it defines formatting capability.
If you can confirm this command comes from LSP4E, please report a bug to LSP4E.


(In reply to Christoph Laeubrich from comment #1)
> Would
> be good to have a convenient entry point where one can define the
> content-type + a handler with a method with the usual parameter:
> 
> > void formatDocument(ITextViewer viewer, int offset)

Where do you think this API should be?
Handlers are much more powerful with more dynamic control of enablement and so on. From a handler, it's relatively easy to get and editor and the document to apply changes on. An additional API would seem weaker to me in comparison.
Comment 3 Christoph Laeubrich CLA 2021-01-21 07:02:16 EST
Its just an idea... the E4 way would probably be to define the format item as a command and one can provide handlers with it, but an extension point would suffice also (e.g. it is rater simple: No extension to format for the given content type -> disabled, otherwise -> enabled :-)