A page to collect ideas for improving Tk's text widget, and to list current limitations.

   * Foremost amongst these is the 'scrollbar problem' when there are wrapped lines of varying lengths.  As you scroll, the length of the scrollbar changes!

   * Add a 'blockcursor' option to present a flashing block rather than thin line.

   * Add a method to count the number of characters between two index positions (currently the only way to do this is ''string length [[.text get $idx1 $idx2]]'')

   * Add helper code to implement a text replace operation which doesn't mess with the current insertion position or the current scroll position, unless such changes are actually required.  (the naive use of ''delete'' followed by ''insert'' really isn't very satisfactory).

   * Add the ability to find the index at the beginning or end of any display line, whether that line is actually currently displayed or not.

[Vince] has placed a work-in-progress patch at http://sourceforge.net/tracker/?func=detail&aid=791292&group_id=12997&atid=312997 which addresses many of these issues.

----
''My biggest (and only) frustration with the text widget is that it is too slow or weak. Loading really large files into it is very slow and painful. That renders apps like Tkdiff or Tkgrep practically useless.'' -- [RS]: Well, comparing with Notepad, Word or such, [text] still loads quite acceptably, if you load the file line by line with [update]s in between - start reading on top, while bottom still loads. Even on a slow [iPaq], [iRead: a Gutenberg eBook reader] is usable for files of say 400 KB (where PocketWord bails out at about 180KB)

''I suppose you're right, but... Notepad and Word??? Were you out of good parameters when you wrote that?''

----
''[MGS]'' [[2003/08/22]] - I would like to see [Move cursor by display line in a text widget] a standard feature. I guess it should be optional (and keep the current default method of cursor control for backwards compatibility).


----
I agree with [RS]; I think it can also be said that the "uselessness" of an app is partly related to how the app is written. For example, tkdiff now works by leaving the whole window blank until all diffs have been processed. It is possible to write tkdiff where it would display data as it is available 1, 10 or 100 lines at a time, making it come up and be usable significantly faster. True, viewing the last diff will take just as long but most people use tools like tkdiff top down.

That's not to say I don't want the widget to be faster, but I do think it's a stretch to say tkdiff or tkgrep is "practically useless".

''OK. What about a serious text editor, which is expected to display the entire document all the time? You can use that trick and display only portions at any given time, but programming most of the functionality becomes a lot more complex. Visually every single event, even key presses, and their relation with what is displayed or hidden must be managed all the time.'' - [RS]: No, it's easiest to load big files in one go into the text widget - just update while you're loading :D

----
''[MGS]'' [[2003/08/22]] - Of course, you can load chunks of the input file during the idle event loop with something like this:

 proc text:load {text channel {size 1024}} {
 
   $text insert end [read $channel $size]
 
   if { [eof $channel] } {
     close $channel
     puts "channel closed at [clock format [clock seconds]]"
   } else {
     after idle [list after 0 [info level 0]]
   }
 
 }
 
   text .t -yscrollcommand [list .y set]
   scrollbar .y -orient vertical -command [list .t yview]
 
   pack .y -side right -expand 0 -fill y
   pack .t -side left  -expand 1 -fill both
 
   set channel [open all.tcl r]
   puts "channel opened at [clock format [clock seconds]]"
   text:load .t $channel

Loading a 15 Mb file took about 4 seconds on my 700Mhz K7 Athlon with 384 Mb RAM.

----
[Category Suggestions]