> > 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
