As well as the file/registry/database and formatting
(XML/YAML/INI/properties) issues mentioned by the others, there are
different structures of settings needed based on the development model
of the application. Some want a hierarchy with global, user, project,
language and file properties and some may need these to be split so
that, for example, window sizes can only be set in the per user
properties.
> Well, since you mention it, SciTE does have a file format already
> defined which is able to represent all of the needed style control
> information in a concise and easy-to-use way. :)
There are many problems with the SciTE version of properties files.
Some downstream projects (Anjuta IIRC) have reused the code but many
projects have very different requirements. Sometimes an existing
settings system must be used.
> To both of these points: yes, they are great theoretical (and even
> sometimes practical) stances to take... but in the real world, anyone
> using Scintilla is forced to either adopt an existing format from
> elsewhere (or make [yet another] one up) and implement it.
What is the problem with using an existing format? Normally your
environment will strongly indicate what is a sensible choice. Java
applications normally use .properties format (or XML). Windows
executables often use the registry. If you are writing in a web
environment and need to communicate with JavaScript then JSON will
look good.
SciTE has its own properties file format as it is cross-platform, I
wanted to minimize dependencies and there was no XML API that was
available in default GTK+ and Windows 9x installations. I'm not sure
that even now you can depend on a similar XML API being available on
both GTK+ and Windows.
> A (to me, of course) reasonable compromise here would be to add an API
> function which, when passed a style# and a string in the format of a
> SciTE [right-hand-side] properties file value, would interpret it in
> the context of the currently set lexer AND whatever properties are
> already set, and make the indicated style definition calls (note that
> I am not suggesting implementing the left-hand-side (key) semantics).
This wouldn't be too bad.
I'm not sure it is good in the long term as new needs may impact
the basic style syntax. SinkWorld may need nested properties which
will require more operators which will then require quoting rules.
style.cxx.5=fore:#FF0000,decoration:{type:underline,fore:#808080,hover:{fore:#0000FF}}
> Nobody would be forced to use this, but anyone who has the need to
> represent style-definition information similar to that of SciTE,
> *could* use a ready-made solution... SciTE itself would be able to
> take advantage of this facility! :)
SciTE would have to flatten its properties structure to fit into
Scintilla's single level model as a style definition may depend on a
setting that is set in global properties and overridden in user
properties. It could expand all variables before giving the text to
Scintilla or copy all of the properties (in depth order) into
Scintilla every time the document is switched. That would require some
extra processing and storage over the existing implementation.
Neil
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
