Re: [lazarus] Changing SynEdit - actions
- Move all (all non-basic at least) editor commands to a separate unit and implement each command on a separate method or class. I'm inclined to make them TAction descendants to unify shortcut handling, but I'm not set yet... What would we gain? Reuse ? In theory (depending on how that unit is implemented). It should be designed to work on any stringlist (which is what I believe the underlying data-set in synedit is), so it can update a synedit, or a memo or whatever and can be used for other components or heck if called from code directly to do easy advanced stringset parsing. Imagine if we could tell a programmer that the stringset he is trying to modify in a certain way before displaying - well he can access the search| replace menu's own command from his code with all it's features|power. Right now most string parsing seems to be handled by pos, copy and delete - which works but why should people need to write the same code over and over when lazarus already contains it ? A.J. Some might notice I am highly in favour of lazarus having MORE than delphi ever did - to make delphi users SWOON over it :) -- there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing SynEdit - actions
On Wed, 1 Mar 2006 12:09:42 +0200 A.J. Venter [EMAIL PROTECTED] wrote: - Move all (all non-basic at least) editor commands to a separate unit and implement each command on a separate method or class. I'm inclined to make them TAction descendants to unify shortcut handling, but I'm not set yet... What would we gain? Reuse ? In theory (depending on how that unit is implemented). It should be designed to work on any stringlist (which is what I believe the underlying data-set in synedit is), Yes, it is a TStrings descendant and some functions don't use the advanced features. so it can update a synedit, or a memo or whatever and can be used for other components or heck if called from code directly to do easy advanced stringset parsing. Imagine if we could tell a programmer that the stringset he is trying to modify in a certain way before displaying - well he can access the search| replace menu's own command from his code with all it's features|power. I agree in case of the search/replace/block indent/unindent commands and maybe a few more. It is a matter of speed. If speed does not matter, just create a synedit, assign your list and execute the command. If speed does matter, read further: Normally at least the biggest part of a synedit command handles synedit specific things like cursor, invalidating, gutter, marks, selection, highlighter and undo/redo stuff. To get good reusable stringlist functions, we would have to rewrite all the functions. Right now most string parsing seems to be handled by pos, copy and delete - which works but why should people need to write the same code over and over when lazarus already contains it ? The same reason, why there are so many databases. A.J. Some might notice I am highly in favour of lazarus having MORE than delphi ever did - to make delphi users SWOON over it :) Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing SynEdit - actions
Right now most string parsing seems to be handled by pos, copy and delete - which works but why should people need to write the same code over and over when lazarus already contains it ? The same reason, why there are so many databases. Touché, anyway your explanations did give me a lot more clarity on the nature of the underlying code, and I can see that making it generic would be a lot of work, perhaps not worth it unless somebody has an itch. Ciao A.J. -- there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing SynEdit - actions
Lengthy email warning! :-$ Another idea: one thread per thread. Great idea ;-) - Move all (all non-basic at least) editor commands to a separate unit and implement each command on a separate method or class. I'm inclined to make them TAction descendants to unify shortcut handling, but I'm not set yet... What would we gain? I'd like it to address these things: - synedit.pp is too big. - some code is too coupled with the editor internals when it didn't need to. - because the huge ExecuteCommand method is so big it has a polluted namespace and some non-sense variable reusing. - changing the behaviour of a command in non-trivial for a user (developer). - assigning editor commands to menu items and avoid shortcut clashing without hacks. I don't know how well the TAction code would handle a number of commands as large as synedit use, and it would need some rework to get chained shortcuts (two shortcuts sequence) going. Normally at least the biggest part of a synedit command handles synedit specific things like cursor, invalidating, gutter, marks, selection, highlighter and undo/redo stuff. Not exactly. These should be and are mostly handled transparently for the command, and completing this abstraction is one of the goals. -Flávio _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing SynEdit - actions
Flávio Etrusco wrote: I don't know how well the TAction code would handle a number of commands as large as synedit use, and it would need some rework to get chained shortcuts (two shortcuts sequence) going. I've publisched some examples for a dynamic and scriptable Command Processor at CC, which could easily manage everything needed at high speed. It would be possible to collect related comands in separate files. BTW maybe I will find some time for programming in the future. Would there be any interest in a fast multifont editor ? I don't intend to do the whole work alone, just showing some ways how it could be accomplished as usual. Once I had started using Delphi but stopped because lack of interest. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing SynEdit - actions
On Wed, 1 Mar 2006, Martin Waldenburg wrote: Flávio Etrusco wrote: I don't know how well the TAction code would handle a number of commands as large as synedit use, and it would need some rework to get chained shortcuts (two shortcuts sequence) going. I've publisched some examples for a dynamic and scriptable Command Processor at CC, which could easily manage everything needed at high speed. It would be possible to collect related comands in separate files. BTW maybe I will find some time for programming in the future. Would there be any interest in a fast multifont editor ? If it could be used as a basis for an RTF/html editor: yes, definitely. The documentation editor could use that. Michael.
Re: [lazarus] Changing SynEdit - actions
On Wed, 1 Mar 2006 09:18:29 -0300 Flávio Etrusco [EMAIL PROTECTED] wrote: Lengthy email warning! :-$ Another idea: one thread per thread. Great idea ;-) - Move all (all non-basic at least) editor commands to a separate unit and implement each command on a separate method or class. I'm inclined to make them TAction descendants to unify shortcut handling, but I'm not set yet... What would we gain? I'd like it to address these things: - synedit.pp is too big. Obviously. - some code is too coupled with the editor internals when it didn't need to. - because the huge ExecuteCommand method is so big it has a polluted namespace and some non-sense variable reusing. - changing the behaviour of a command in non-trivial for a user (developer). - assigning editor commands to menu items and avoid shortcut clashing without hacks. I don't know how well the TAction code would handle a number of commands as large as synedit use, and it would need some rework to get chained shortcuts (two shortcuts sequence) going. TAction speed is very bad with hundreds of shortcuts. I had to use AVL trees for the IDE shortcuts to reduce the loading time of the IDE. Normally at least the biggest part of a synedit command handles synedit specific things like cursor, invalidating, gutter, marks, selection, highlighter and undo/redo stuff. Not exactly. These should be and are mostly handled transparently for the command, and completing this abstraction is one of the goals. This should be, but they are not yet. It's good that someone wants to improve ti. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing SynEdit - actions
Am Mittwoch, den 01.03.2006, 10:00 -0300 schrieb Flávio Etrusco: On 3/1/06, Martin Waldenburg [EMAIL PROTECTED] wrote: BTW maybe I will find some time for programming in the future. Would there be any interest in a fast multifont editor ? I don't intend to do the whole work alone, just showing some ways how it could be accomplished as usual. Once I had started using Delphi but stopped because lack of interest. I'm not very fond of word processors - is there any use for a multifond editor besides this ? - but I'd probably be interested in a general layout engine so we can make the next killer web brower in pascal ;-) Talking about killer apps and reusing older stuff: There is a project named BestOffice by people mostly fraom brazil on sourceforge. Seems to be Delphi only, GPL and mostly frozen since 2003. Since it has a text processor it must have some sort of font rendering engine... FWIW Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
