Armel Asselin wrote:
Does your "protection style" implement the same functionality as the
built-in SCI_STYLESETCHANGEABLE - but using indicator bits instead of
style bits?
yes, equal
Have you made provision for the case of allowing caret positioning
inside of a range of "protected" chars? This would disallow
unintended coalescing of adjoining protected ranges.
i did not need that, so i would leave that to whom it interests
IMHO, this is one of the "features" of protected fields that limits
their utility... so I think that any replacement/enhancement for the
existing facility needs to address this.
And yes, not worrying about the "special" (protected) versions of the
styles being overwritten by re-lexing would simplify part of my
problem... is this the main reason you are working on your changes?
yes, this is the main reason because in my app (ECMerge) lexing is
completely disconnected from the usage of indicators, so I want the
lexer and styling stuff to do its job independently from mine
I was liking this "separation from lexing" approach until I realized
that Undo/Redo exposes the very same problem[s]: as *all* styling info
(style *and* indicator bits) is lost and must be reconstructed in this
case, the "pure-indicator" approach to protected fields is
significantly weakened (it would appear).
An additional point vis-a-vis the indicator approach: with the
scarcity of the indicator bits resource (and the way they are used),
it would seem quite desirable to have an indicator-based protected
fields mechanism "overload" the indicator type value, e.g., low bits
as they are now, high bits used to specify protection. Done properly,
this would not need to break existing Scintilla clients - apps that do
not know about the high bits will not set them or look for them.
Overall, it looks like a hybrid scheme utilizing the existing
protection mechanism with indicators used to allow for "caret breaks"
in protected regions provides the best trade-off between new
functionality vs. required [Scintilla] code changes (it should solve
my problem, anyway). ;)
This is not to say that an indicator-based protection mechanism could
not be done also, just that it looks like a somewhat heavier code
footprint.
A comment on using the indicator bits: my current use of the indicator
bits is to display "ephemeral" decorations which can all be erased on
a fairly regular basis... using them to save longer-lasting state will
unfortunately prevent the simple expedient of setting *all* indicator
bits to zero to do this erasing - but this happens whether they get
used as your primary protected state representation OR as "modifiers"
of the existing protected state mechanism... :(
i'm sure that you can define a set of indicators that are ephemeral and
another set for indicators that are not. You can clean the first without
the second.
Yes, I recalled this aspect of indicator use shortly after posting -
but I was no longer at my computer. :)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
