Re: [platform-text-dev] Questions about 3.0 plan items

[Christopher Lenz <cmlenz@xxxxxx>]

Hello Kai-Uwe,

thanks a bunch for these explanations!

Kai-Uwe Maetzel wrote:
[snip]
> File buffers are transparent to you in several ways. Having defined and 
> set your own document provider for your editors, you are not affected by 
> file buffers. Your code simply bypasses them. You have to adapt your 
> code to benefit from file buffers. If you inherit the default document 
> provider from the platform you automatically use file buffers. The 
> "documentCreation" extension point is interesting for your if you want 
> the file buffer manager to instantiate a specific document 
> implementation for certain file extensions.

Hmm, what would be the use case for a custom IDocument implementation?

For the editor I'm working on, I had initially thought about providing an 
extension of Document that would also manage and allow access to the model 
(i.e. the parsed representation) corresponding to the document. Although 
that seemed intuitive at first, I let go of the idea after seeing that no 
other plugin in Eclipse seemed to extend IDocument/Document.

For example: assuming an XML editor, would it make sense to provide a custom 
IDocument implementation that also implemented the org.w3c.dom.Document 
interface, for easy access by e.g. the outline view or extending plug-ins?

[ ... and sorry if I'm asking too basic stuff here :-P ]

> The "documentSetup" 
> extension point is interesting if you want to install specific 
> partitioners etc. on documents created by the file buffer manager for 
> certain file extensions.
>
> 2) Preference handling is consolidated in code. The amount of code you 
> have to write to cope with preferences in less than before. This does 
> not yet impact how the editor surfaces the preferences. Right now 
> Eclipse preference handling is mostly component based and not function 
> based. I.e. the user still has to change the setting for each editor 
> individually. The Java editor does not inherit the setting from the 
> workbench. Eclipse preference handling needs a rework in this respect 
> altogether.

Okay.

> 3) Partitioning is revisited in the course of allowing multiple 
> languages in the same editor. There is not much information about this 
> yet. We will work on this in M5.

Interesting :-)

-chris

> Kai
>
>
>
> *Christopher Lenz <cmlenz@xxxxxx>*
> Sent by: platform-text-dev-admin@xxxxxxxxxxx
>
> 09/05/2003 04:18 PM
> Please respond to
> platform-text-dev@xxxxxxxxxxx
>
> 	
> To
> 	platform-text-dev@xxxxxxxxxxx
> cc
> 	
> Subject
> 	[platform-text-dev] Questions about 3.0 plan items
>
>
> Hi all,
>
> I'm having a bit of a hard time trying to find details about some of the
> plan items for 3.0. Many of the descriptions on the plan outline are pretty
> coarse, and only few of the plan items seem to have bugzilla entries (and
> then most of those entries contain very few details :-P ).
>
> So here we go ... if anyone can point me to documents that I have missed,
> please do so.
>
> 1. File Buffers (#40789)
>
> What is the intention behind this, where can I find more details? If I'm
> writing a text editor, do I need to care about this, or is it 
> transparent to
> me? And more specifically, do I need to care about the new
> 'documentCreation' extension point?
>
> 2. Preference Handling / Support default configurations and preference
>    inheritance
>
> Again, can anyone provide more details about this item? A text-based editor
> needs a lot of custom code to provide the custumization that you'd expect
> from pretty much every text editor: print margin, current line marker,
> annotations, etc. It's easy to set that stuff up with TextEditor and
> SourceViewerDecorationSupport, but you still need to provide the preference
> pages/tabs to let the user customize the behaviour, and the user needs to
> touch the prefs of each and every editor if he/she just wants *all* text
> editors to show the print margin (for example).
>
> So what this boils down to is: (a) is there anything planned to allow reuse
> of the typical text editor configuration blocks? See Workbench>Editors>Text
> Editor, Java>Editor and Ant>Editor as examples for a lot of annoying UI 
> code
> copied around. And (b), is there anything planned to allow editors to use
> the same common preference values, while still providing their own extended
> customization options?
>
> 3. Extend partitioning/Introduce nested partitions
>
> This is the most interesting to me. Is there a specific use case that
> requires such support?
>
> This plan item *seems* to make it possible to more easily implement editors
> of compound text documents such as HTML files, where the main HTML editor
> could delegate to other plugins to let them handle e.g. embedded 
> sections of
> CSS or JavaScript. Am I totally off with this conclusion?
>
> Thanks,
> -chris