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

[Kai-Uwe Maetzel <kai-uwe_maetzel@xxxxxxxxxx>]

Christopher,

1) File buffers generalize the notion
of editors and document providers. Text editors of different kinds can
share the same document provider. This way, they show the same document
for the same input element. In addition to the document they share any
state that is managed by the document provider for the input element. This
includes the need for state validation, the dirty bit, the annotation model,
and more. For files the annotation model helps with keeping attached text
markers in sync with the contents of the file in the course of modifications.
When considering editors to be not just UI based editors the functionality
provided by document providers makes still sense. File buffers provide
that functionality independent from any UI code. Document providers can
be implemented on top of file buffers and have to manage only the information
that is relevant for their editors. Side effect is that different document
providers can work on the same file buffers and unrelated editors can share
the same document. Your see this in the M3 build when opening the default
text editor and the compilation unit editor on the same .java file.

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. 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.

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. 

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


_______________________________________________
platform-text-dev mailing list
platform-text-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-text-dev