On Tue, 3 Nov 2009 12:47:40 -0800
"Gregory" == Gregory Crosswhite >>>>>> wrote:
Gregory> The problem with Leo is that although there are rarely Gregory> performance problems when navigating and editing the outline, Gregory> the text pane can be very slow at times when using the Gregory> Tk-based GUI --- even on modern hardware --- because the Gregory> syntax highlighter is written in Python. (Incidentally, as Gregory> much as I love Leo, I also hold it up as an example of how Gregory> slow scripting languages aren't always "fast enough" as their Gregory> proponents claim. :-) ) :-) Gregory> There are two solutions to this: First, you can use the Gregory> Qt-based Leo GUI, which uses the native C++ colorizer built Gregory> into QtScintilla, which I have never had any performance Gregory> problems with. Since you (reasonably) really like Gregory> haskell-mode in Emacs, though, you can alternatively use the Gregory> Emacs plugin so that you end up using Leo to navigate through Gregory> your code to the chunk that you want to edit, and then using Gregory> Emacs to do the actual editing. This might sound like an Gregory> awkward setup, but I actually find that navigating in this way Gregory> requires much less mental energy than scanning through Gregory> multiple flat files to pick out the code that you want to edit Gregory> next, and the plugin makes this type of workflow fairly Gregory> painless. Thanks to your help, now I made Qt Leo to work with my Emacs. :-) Gregory> Viewing Leo as a "meta-editor" is a good way to think about it. Good. Let me try to imbibe this view more... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------