Ok,
I got the first version ready. It seems to run well on my system. But I would be happy about any feedback (bugs, or optimization, or design issues, or ...).
So far I have made 2 classes:
- Highlight All (which is used in Incremental search, but can be used in normal search too)
There is some room for performance optimization, but it already performs very well)
- MatchingBrackets => just moved existing code.
Further modules can be added easily.
I also thought about moving the SelectionBlock into a class of it's own (see also question "highlighter None)
A few Questions, various things I came across:
- Selecting Highlighter = NONE or Text (from editor context menu) ~None, does also disable MatchingBrackets, is that intend? Because MatchingBrackets are an option on the EditorEnviroment "General" page, and not on the "Color/Highlighter" page? ~Text does seem to be "None" but with MatchingBrackets ? or does text highlight anything else?
If None was not intend to suppress MatchingBrackets, code could be simplified, and None could pretend to paint a single (all line) token. Currently this can be done anyway. But it would;nt work, if SelectionBlock, became a TMarkup* class (as that would put the SelectBlock on the same level with Brackets.)
- The Caret positions by name:
I am aware there are 3 (is that right?) ways to reference to the caret position.
- The Char(utf8) Position in the SourceText
- The Byte Position in the Sourcetext (if all chars were 2 bytes, then thats means X = twice the CharPos)
- The Position on the Screen (uses CharPos for X ?)
- (Screen Position in Pixel)
The source refers to the Caret in Various Ways:
- CaretXY, CaretX, CaretY, GetCaretXY, fCaretX, fCaretY, ... I believe they refer to the CHAR pos ?
This is also referred to a PhysicalCaret?
- LogicalCaret, LogCarret
referring to the BYTE pos ?
* from the Synedit Source
fCaretX: Integer; // physical position (screen)
Is this really the position on screen, or is it the X(Char position) in the Source? (This differs if the screen is horizontally scrolled)
Best Regards
Martin
Martin Friebe wrote 98 lines
> Yes. And we need markers for live templates. For example some green blocks and
> some red blocks.
> The HighlightAll markers can be used for identifier references too.
>
>
Not sure what you refer too.
But it will probably work. Not necessarily with the highlight all (which
is search based).
But it should be easy once I have an SynEditTextMarkup object.
The idea is that it provides functions like
MarkupStyleAndColorAtPos( XPosInLine ) : SomeStyleInfo;
XPosOfNextMarkupChange( CurrentXPosInLine ) : integer;
Then while adding a token, to the token akku, it would be splitted (if
needed) and the markup applied.
=> so any other (non Language (eg non-pascal, non-html,...)) Markup,
could be done in there.
I'll post more, once I converted my current proto-type, to support this.
BestRegards
Martin
Mattias G?rtner wrote:
> Zitat von Martin Friebe :
>
>
>
>> Makes sense,or well depends on how old the plans are, and how much
>> SynEdit has moved since.
>> One block, that is of particular interest to me is the PaintLines.
>>
>> PaintLines happens to be an IFDEF SYNLAZ over several 100 (or 1000?)
>> lines. A complete Lazarus, and a complete Original version.
>> IMHO an IfDef of this Size IMHO doesn't serve the protection/diff
>> purpose very much?
>>
>>
> There were so many IFDEFs in that part that it was hardly readable. It reached a
> critical limit.
>
>
>
>
>> I have a patch/prototype (still some cleanup on it) for a "highlight
>> All" during search feature.
>>
>>
> Cool.
>
>
>
>> Marc Weustink has a copy of this (because I
>> had previously send other patches to him).
>> This will however require some changes to PaintToken.
>> Also PaintToken appears to have several other shortcomings/bugs, which
>> could easily be fixed/
>> => but all of those would probably end up in a rewrite of PaintToken
>> (which is why I haven't reported those issues yet)
>>
>>
> No problem. PaintToken is an optimized function. And like most optimized
> functions: When adding new features, you have to rewrite it.
>
>
>
>
>> Any feedback guiding me in this issue would be welcome.
>> I can also (in the evening) mail my prototype and comments about it =>
>> but I don't know what/if Marc has any plans on it.
>>
>> Another idea (and so far not beyond the state of an idea) is to move all
>> TextMarking (HighlightBrackets, SpecialLines, SelectedBlock, and the new
>> HighlightAll => features that are not SynEditHighlighter), into a new
>> class SynEditTextMarkup. However "PaintLines" still would need changes.
>>
>>
> Yes. And we need markers for live templates. For example some green blocks and
> some red blocks.
> The HighlightAll markers can be used for identifier references too.
>
> Mattias
>
> _______________________________________________
> Lazarus mailing list
>
>
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
>
>
_______________________________________________
Lazarus mailing list
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: high_all.rar
Type: application/octet-stream
Size: 11283 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080629/890b8abc/attachment-0001.obj
