Martin Friebe schrieb: > Looking at your signature, you are the Author of > http://wiki.lazarus.freepascal.org/Redesign_of_the_SynEdit_component ?
Right, this was the draft for the subsequent implementation. > A couple of remarks: > -Individual drawer objects fro Gutter and TextArea (I will avoid Grid in > the name, Grid is a specialization) The Grid is a hint on the organisation of the canvas, in rectangular cells. I've spent a lot of time in the various coordinate systems and their mapping, for drawing purposes (relative to the window), document view (rows/columns, scrolling, line wrapping), and document storage (folding, tab expansion, UTF encoding). The need for properly anchored bookmarks was a big challenge. Similar, but finally easy to implement, was the preservation of the cursor column, when scrolling across lines of shorter lenght. > This has been started for the Gutter. It does need a lot of clean up still. > It would also benefit from the Os-Handle and canvas being moved into a > wrapper class. This would: > - avoid the need to callback synedit for Invalidates > - allow a Handle/Canvas of another Component being passed to SynEdit, > and SynEdit painting the other component (e.g. SourceEditor) Here we may have quite different viewpoints, on the delegation of the responsibilities. > Similar considerations for the Textarea. However the textdrawer will > have to access a lot of other objects, and need ways to merge the > result. there are > - the highlighter > - the MarkUpManager In my solution the highlighting (including hyperlinks) is implemented in derived classes, by overriding the line-painting method. I ended up in a single array, holding the scanner start state for every line - required for proper handling of multi-line comments. Hyperlinks are implemented as special highlighting information. When the mouse pointer moves, the according characters and attributes are obtained for the current line, from the document, then the line eventually is repainted when the "active" state of a hyperlink has changed. > - The TextLines itself (e.g. Highlighter token will return a tab as a > tab, but the TestLines need to translate this into displayable chars. Either > -- spaces > -- "show special chars" >" (and if tab is only one char, then maybe > there is only one ">" followe by spaces? Right, tab expansion is highly configurable in my solution :-) > This can only be done by the Lines, as they know the layout/tabwidth > (see concept of Views/ TabView below) Right, the handling of wrapped lines also was a challenge :-) > The storage and view of the TextLines: > I think TSynEditCodeBuffer is a good start for this. Yet tabs are a > specialisation, that should go into a ViewClass. > ViewClasses TSynEditStrings themself, that will modify how the stored > text is seen. (TrimTrailingSpaces is an example. FoldedView too, so > FoldedFiew does not yet fully follow the concept) I've left folding to the document management, for any convenient implementation. The visual component manages visible lines only, the mapping between stored and visible lines must be implemented outside of it. Including notifications of the changed line count, when text blocks are collapsed or expanded. If desired, multiple views can have different blocks collapsed, different tab width, wrapping on different screen boundaries etc. The consideration of multiple views reveals clear frontiers for the various responsibilities (what feature to implement where). > The following Views (and others) can apply to the text > > - WordWrapView > - FoldView > - TabView or ElasticTabView (http://bugs.freepascal.org/view.php?id=9650) > modifies Logical(byte) to Phisical (char on screen) calculations. > probably still returns tabs, but offers conversation methods. > - replacing tabs with spaces in the Strings[] property, may > complicate Highlighting and MarkUp and show special chars > It would also impact the ability of keeping the caret from being > placed in the middle of a tab (which currently can be done) > - TrimSpaceView > - TSynEditStringBuffer (holding the actual text) IMO all this is already perfectly implemented in my CharGrid. With regards to the ElasticTabView, I have my own opinion on a mix of an source code editor with a text processor or page layouter - it stinks :-( I neither like subroutine arguments indented to the "(" of the call, nor block comments to the right of source code, sensitive to insertion or deletion of lines of code. I don't want to open a can of worms for people who put more emphasis on the appearance of their(?) source code, than on its functionality. It's more annoying when the caret disappears in the last line or column of the window, as I observed in the current SynEdit implementation. DoDi _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus