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... > 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. > So, great - I can define the styles when I initialize Scintilla from > my particular [container] application... but in SciTE, these would not > get defined, and the lexer only has to know to ignore the high bit. For now, the most SciTE friendly way would be to just define a second style for each of your comment types, not trying to force this into a particular bit. Have the lexer define these styles and duplicate the style settings for each pair. > But how do I *set* these "read-only" styles? I would be happy if my > application could just do a SCI_ADDSTYLEDTEXT using these styles and > the text would then stay that way until I reset "normal" styles by > using SCI_ADDSTYLEDTEXT again... but presumably any later request for > styling could have the lexer overwrite the magic styles with normal > styles, right? Yes, there is no good support for sharing the responsibility for lexing. The bit 4 for read-only does have the advantage that your lexer would set a 4 bit mask and so not touch the read-only bit. You'd still have to schedule container side resetting of the read-only bit. > 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. > Comments? Suggestions? Would I be better off just watching for > SC_MOD_CHANGESTYLE notifications in my app and re-writing my magic > styles if they change? Is this last reliable AND non-recursive? :) This will not work if you change within the notification: post yourself a do-later message. > 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. > 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. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
