GUI toolkit selection for a text editor widget

[Srinath Avadhanula]

Hello,

Sorry to be bringing up what seems to be a somewhat beaten up topic...

This is what I wanted to do:

Create a _simple_ text editor widget which supports VI(M) style
keybindings but works with arbitrary fonts/unicode characters. Vi(m)
unfortunately, does not support Devanagari (or proportional fonts) and
it looks like it will take quite some time for these things to work. As
and when Vim supports Devanagari on Windows, I will give up this effort.

My current aims are:
1. Simple Vi(m) style keybindings.
2. Syntax highlighting for arbitrary files based on Vim-style syntax
   highlighting definitions. Vim defines syntax highlighting for files
   based on a very flexible regexp style approach. Thus you can define
   syntax hightlighting for new file types just by writing some regexps.
3. Should be able to load/edit files written in unicode.
4. Macro capability.
5. I want to implement this purely in python.
6. Should work on windows.
7. I do not really care much about speed/looks etc as long as the thing is
   functional.

The choice of the GUI toolkit is therefore almost exclusively depends on
how these conditions can be met. This is my take so far:

1. PyQT: Unfortunately, the qtext module which extends the scintilla module
   to QT is available only under a commercial license for windows. The
   QMultiLineEdit widget does not support any text styling at all. Hence
   PyQT seems to be ruled out straight away.

2. wxPython: The wxStyledTextCtrl widget showed great promise. It has
   almost everything one would wish for. Except for a _major_ bug while
   editing unicode. The text caret which shows where the text insertion
   will happen is offset from the actual insertion point in complex
   scripts like devangari or arabic. This looks like its a problem with
   calculating text extents. Robin Dunn has acknowledged this bug, but
   unfortunately, unless there is a workaround, I cannot do anything with
   wxStyledTextCtrl at all.

   wxPython also has wxTextCtrl which has far lesser features than
   wxStyledTextCtrl, but at least does not have the bug with the text
   caret. Unfortunately, it looks like it does not provide some necessary
   functions. For one, if I desire to do syntax highlighting based on it, I
   would need to find out the current range of text displayed in the
   window. But I couldn't find any way of finding out which lines are
   actually displayed. The various wxScrollBar functions (which wxTextCtrl
   inherits) do not give useful information.

3. Tkinter: I looked briefly at Tkinter and the Text widget looked very
   impressive indeed! It looks like the way it highlights text is even
   more powerful than Vim in that each character (or range) has multiple
   "tags" associated with it and the most recent tag takes precedence.
   This looks like something which might be very handy. It even supports
   inserting bitmaps etc. All in all, very neat looking.

   But there seems to be some limitations:
   1. How do I recognize control key inputs? I tried
          self.bind('<Key>', function)
      but how to find out if CTRL-a has been pressed in the function. When
      I ran a simple app, event.char reports 'a' when I press CTRL-A. So
      does event.keysym and event.keycode... wxPython has something called
      event.ControlDown() for keyEvents...

   2. There seems to be a problem with displaying unicode which Text
      suffers from too :( The problem is not as severe as the one
      wxStyledTextCtrl suffers from and it looks like it can be "lived
      with". When moving over certain "composing character" strings in
      unicode, the caret seems to move _between_ the characters. Ideally,
      each sequence of composing characters would be considered a single
      "glyph"... I will elaborate if someone needs clarification.

   3. Although the Text widget itself is powerful, from what I gather in
      this newsgroup and on the web, Tkinter does not provide things like
      a tree control widget which might be essential later on. This looks
      like something which can be worked around, because idle, the editor
      provided with Python 2.3 seems to have all these things constructed
      using the basic primitives...

    Infact, I am wondering whether I should just modify Idle to accept Vi
    style key-bindinds...

I would greatly appreciate any comments.

Thank you,
Regards,
Srinath