I changed subject because it's very hard to follow the discussion in the existing threads...
On Sun, Oct 12, 2008 at 7:29 AM, Edward K. Ream <[EMAIL PROTECTED]> wrote: > At present the big problem is that the onTextChanged event happens > before the key stroke that causes the changes is reported(!) The > workaround would be to banish (ignore) all key bindings for printable > characters. It's possible, but extreme. For example, there are > presently quite useful bindings for tab and period. I think having the native widgets handle as many events as possible is the right way to go, only making exceptions when we really, really want to. It's the free lunch - if there is no Leo code excercised for particular tasks, there won't be bugs that need to be fixed in Leo. You can just sit back and report it in scintilla. As for the tree widget - the likelihood of it having any bugs is relatively low. Eliminating the need of running lots of code is a big win, even if it breaks many unit tests. Making certain unittests unnecessary because the code they excercise is not needed anymore is a very good thing. Doing things in a too complicated manner because we want to benefit from code that was necessary because of Tk only bumps up the amount of bugs and makes things work slower (because more python code gets run on every keystroke). Also, where leo behaviour of particular key deviates from the "usual way" of the native widgets, people consider it a leo bug, not feature. For example the situation where you select a block of text and try to indent it with tab and the text disappears - that's probably not something people want to see. Avoiding distractions like this eliminate the need of open-with plugin (I'm sure some people will stick with the vim plugin, but that can't be helped yet ;-) I think what we should do is: - Forget the way body editing was done in tk leo. - See how acceptable scintilla's behaviour is for typical editing tasks and if it needs to be changed, only then change it (handle the commands in leo side) If we do it this way, apart from the code maintenance / user acceptance benefits cited above, we can change the body editor easily later on. If someone implements an editor widget that does vi bindings, we could just drop it in without breaking half of the plugin (because our code never really knew too much of how the editor went about its business). I think qleolite proved that a lot can be done by skipping things in Leo's core. If Leo is at some point in time able to actually delete that code completely, it will be a *huge* win for the project, being yet another perk we get from switching to Qt. Back in the day I worked in a project that used a rich text editor as a text editor for mms messages. Lots of stuff were configured in the derived class, and in the end it was not clear how much of that was really needed. Predictably, the fix for most bugs was reducing the amount of "special" things that was done. > Maybe this is getting ahead of myself, but I don't think so. It gives > me hope that the Qt folk may be able to help me in such a way that > there is no change to existing qt code. It's similar to my coding the It is often safe to assume that things work "right" by default (with Qt, and to some extent scintilla), and any apparent deviations from that are probably bugs or misunderstandings on the users part. -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
