[Lazarus] Synedit: Highlight All feature (patch) [Re: SynEdit question (IFDEF SYN_LAZARUS)]

[Martin Friebe]

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:
>> 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 <lazarus at mfriebe.de>:
>>
>>   
>>     
>>> 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
>> Lazarus at lazarus.freepascal.org
>> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
>>   
>>     
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> 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://lists.lazarus-ide.org/pipermail/lazarus/attachments/20080629/890b8abc/attachment-0007.obj>