[Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

[Hans-Peter Diettrich]

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