First off, thanks Neil, for one of your typical detailed and
thought-out answers. :)
Neil Hodgson wrote:
Robert Roessler:
More specifically, I want to be able to have specially-formatted OCaml
comments that will have "magic" properties (turn on/off markers and be
non-deletable). The control/behavior from "style_set_changeable"
seems adequate.
The changeable facet has not been sufficiently used to be certain
the behaviour is OK. There is a very good chance you will soon be
proposing changes...
Wow, *how* did you know? :)
More specifically still, since the lexer now uses only 4 bits, I could
just define versions of my comment styles with the 5th bit set to mean
"same style as low bits but with changeable attribute set to false".
Serendipitously, Armel Asselin is also working in this area to
allow an indicator to be used for read-only.
This seems like a good place to bring up a problem I see with what I
(and Armel?) want to do - if there are, say, two "protected" regions
in your buffer and the user deletes all of the text between them, what
happens next? With Scintilla's current implementation of protected
text, it is not possible to move the cursor "into" the now-joined
range... is Undo your only friend at this point?
Speaking of changes, here is something which I believe was brought up
semi-recently: some way of providing feedback from, e.g., an
SC_MOD_BEFOREDELETE notification returning "NO - do not permit this!"
- this approach obviously only works if the notifications are always
synchronous.
...
Although I would rather keep "funny" changes like this out of the
lexer, I *could* have the lexer itself recognize the special comment
sequences and set the magic styles, but this seems like a Bad
Idea(tm). Now the lexer needs to know if it is being used in my
special application (and should act differently), or is being used
from SciTE or any other app (and should act normally) - and now the
lexer needs to get updated if I want modify this new behavior.
Use a property like lexer.caml.magic to choose.
Thanks - a whole communication path using this is possible now that we
can both read and write properties in the Scintilla interface. ;)
...
A nit: shouldn't Document::ConvertLineEnds use InsertChar instead of
InsertString for adding in the *single* line-end chars? InsertString
is relatively expensive because of always doing a heap allocation to
add style info...
There are going to be a few allocations to implement undo for each
insertion anyway. If you produce a benchmark showing a significant
performance difference, I'd consider it. I think that InsertChar is
there for ease of calling rather than for efficiency. It would
actually be more efficient for PasteRectangular to special case \r\n
and use InsertString rather than 2*InsertChar so that only one undo
action was created.
OK.
A related nit: assuming that alloca is available on the platforms
Scintilla is intended to reach, shouldn't it be used - at least
through, say, a conditionally defined macro for temp char array
allocation?
alloca is more available than when Scintilla started but still has
a couple of problems. Some platforms and applications will have
limited stack and it'd be easy to blow through this in a call to add
some text. SciTE uses a block size of 128K (256K with style bytes) as
that seemed a reasonable compromise between various memory uses and
reading speed. Other apps may read the whole file which could easily
break a normal Windows megabyte stack. alloca may be implemented in
strange ways, including not using the stack: one of the *BSDs does
this IIRC.
OK - this is the sort of real-world feedback I was looking for. BUT,
what I have in mind is not quite as naive as that... just something to
handle [maybe] "small" requests from a char array always allocated in
a stack frame (triggered by some macro like USE_LOCAL_ALLOC), with the
definition of "small" coming from a compile-time def. The POSIX
interface for PCRE uses something like this.
But as you point out, given Undo/Redo, perhaps you can never get away
from nasty ol' heap allocations... ;)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
