Sounds fine for our needs. We'd prefer to have the decorations associated with the document -- it's easier for apps that can provide more than one concurrent view to a document, and it then pushes the responsibility for managing multiple views to each app, which makes sense to me.
The SCN_MODIFIED event works if getting the list of decorations at a range (which might be one-byte long) would be efficient. - Eric Neil Hodgson wrote:
Projects based on Scintilla have been using indicators to mark areas of text that contain errors, search matches, URL hotspots, misspellings, etc. These areas are discovered through some user initiated command or by running a background process rather than as part of lexing. Such marks are often fairly sparse: a HTML syntax checker may show 5 errors in a whole file. Its a little complex using indicators in this way as the lexing state has to be preserved while setting the indicator and there is only 1 to 3 bits available for this state. I'm thinking of adding the capability to have a set of indicators that are not stored in the styling bytes but rather in a compact format similar to run length encoding. They may be called "Extended Indicators" or "Decorations". The implementation would be based on SinkWorld's RunStyles class. The existing indicator drawing code would be reused with the same styles available for each type. A decoration would be reasonably stable: inserting or deleting text outside a decoration leaves it alone; insertions inside a decoration show the decoration, and insertions at the edges don't show the decoration. Decorations would not be remembered in the undo history. Since they are not lexer based there wouldn't be any 'decorations valid' range remembered by Scintilla nor an equivalent to SCN_STYLENEEDED. Containers would manage this themselves through SCN_MODIFIED. Decorations could either be implemented completely in the view layer (simpler but only visible in one view) or with the locations stored in the document and visual appearance in the view. There would be a defined drawing order and some could be drawn underneath the text and others over the text. The number of decoration types allowed could be open ended or fixed. If fixed at 32 it would be simpler to treat as a bit set for notifications and calls. Mouse clicks in decorations could be notified to the application. There would be APIs to set a decoration over a range, to clear a decoration over a range, see if a decoration or any decorations are at a position and to find the start and end of a decoration range. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
_______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
