Re: [Lazarus] Synedit: Highlight All feature (patch) [Re: SynEdit question (IFDEF SYN_LAZARUS)]
On Mon, 07 Jul 2008 00:40:21 +0100 Martin Friebe [EMAIL PROTECTED] wrote: Recreated the patch. The 3 *.pp files go into components/synedit/ Thanks. Applied. I am looking for any feedback, that will prevent me from developing this into the wrong direction. The current ideas/plans are: - speed optimizations to highlight all, even so it does not curreently slow down working on my system. What operations updates the highlight all often? there may be possibilities to limit the amount of search, if only a few lines are invalidated. - Further rework on the PaintLine code. Higlighter NONE, could use PaintToken too (simulating a single token for the whole line) This would mean that brackets will be highlighted - Moving special lines into a Markup class - Moving block selection into a Markup class This would simplify PaintLines. Also currently if the Block is across several HighlighterTokens, the will not join in the token accu. This would become possible. IMO all are good ideas. Please also let me know, anything that would be needed before the above changes, in order to apply the change to SVN. I could then do further changes against the applied version. If you have time, you can implement it for 'none' too. Will do. I f I am right this will actually simplify some code. Let's see. ~Text does seem to be None but with MatchingBrackets ? or does text highlight anything else? ? If you right click the source editor , and within the context menu choose the sub-menu File settings, there is an other sub-menu Highlighter. In addition to a list of all the highlighters from editor-enviroment, there are two entries: -Text -None I haven't found anything that is highlighted by text except it does the brackets, which none does currently not. So the question is, have I missed something, or is there some other intend? Text was intended for future use, for things that can be better done with markups. So, it can be removed. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Synedit: Highlight All feature (patch) [Re: SynEdit question (IFDEF SYN_LAZARUS)]
Hi Mattias, Cool, thanks. Mattias Gaertner wrote: On Mon, 07 Jul 2008 00:40:21 +0100 Martin Friebe [EMAIL PROTECTED] wrote: Recreated the patch. The 3 *.pp files go into components/synedit/ Thanks. Applied. I am looking for any feedback, that will prevent me from developing this into the wrong direction. The current ideas/plans are: - speed optimizations to highlight all, even so it does not curreently slow down working on my system. What operations updates the highlight all often? there may be possibilities to limit the amount of search, if only a few lines are invalidated. - Further rework on the PaintLine code. Higlighter NONE, could use PaintToken too (simulating a single token for the whole line) This would mean that brackets will be highlighted - Moving special lines into a Markup class - Moving block selection into a Markup class This would simplify PaintLines. Also currently if the Block is across several HighlighterTokens, the will not join in the token accu. This would become possible. IMO all are good ideas. Please also let me know, anything that would be needed before the above changes, in order to apply the change to SVN. I could then do further changes against the applied version. If you have time, you can implement it for 'none' too. Will do. I f I am right this will actually simplify some code. Let's see. ~Text does seem to be None but with MatchingBrackets ? or does text highlight anything else? ? If you right click the source editor , and within the context menu choose the sub-menu File settings, there is an other sub-menu Highlighter. In addition to a list of all the highlighters from editor-enviroment, there are two entries: -Text -None I haven't found anything that is highlighted by text except it does the brackets, which none does currently not. So the question is, have I missed something, or is there some other intend? Text was intended for future use, for things that can be better done with markups. So, it can be removed. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Synedit: Highlight All feature (patch) [Re: SynEdit question (IFDEF SYN_LAZARUS)]
Recreated the patch. The 3 *.pp files go into components/synedit/ I am looking for any feedback, that will prevent me from developing this into the wrong direction. The current ideas/plans are: - speed optimizations to highlight all, even so it does not curreently slow down working on my system. there may be possibilities to limit the amount of search, if only a few lines are invalidated. - Further rework on the PaintLine code. Higlighter NONE, could use PaintToken too (simulating a single token for the whole line) This would mean that brackets will be highlighted - Moving special lines into a Markup class - Moving block selection into a Markup class This would simplify PaintLines. Also currently if the Block is across several HighlighterTokens, the will not join in the token accu. This would become possible. Please also let me know, anything that would be needed before the above changes, in order to apply the change to SVN. I could then do further changes against the applied version. If you have time, you can implement it for 'none' too. Will do. I f I am right this will actually simplify some code. Let's see. ~Text does seem to be None but with MatchingBrackets ? or does text highlight anything else? ? If you right click the source editor , and within the context menu choose the sub-menu File settings, there is an other sub-menu Highlighter. In addition to a list of all the highlighters from editor-enviroment, there are two entries: -Text -None I haven't found anything that is highlighted by text except it does the brackets, which none does currently not. So the question is, have I missed something, or is there some other intend? Thanks Martin Mattias Gaertner wrote: On Sun, 29 Jun 2008 13:14:46 +0100 Martin Friebe [EMAIL PROTECTED] wrote: 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 ...). Strange. I get: patch: malformed patch at line 68: @@ -896,6 +902,8 @@ I wonder why. 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? If you have time, you can implement it for 'none' too. ~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 Hardly used. - The Byte Position in the Sourcetext (if all chars were 2 bytes, then thats means X = twice the CharPos) = LogicalCaretXY - The Position on the Screen (uses CharPos for X ?) Not the same as CharPos, because of tabs. = CaretXY - (Screen Position in Pixel) That makes 4. 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? Yes. - LogicalCaret, LogCarret referring to the BYTE pos ? Yes. * 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) It's the screen position without scrolling. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus high_all.rar Description: Binary data ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Synedit: Highlight All feature (patch) [Re: SynEdit question (IFDEF SYN_LAZARUS)]
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 [EMAIL PROTECTED]: 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@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
