Tk::Text has a couple of to-do items from my perspective.

Tk::Text::UpDown can't compensate for tabs and embedded widgets,
and rectangular copy/cut/paste gets really confused when
tabs are involved, and cannot handle different sized
fonts or fonts that are different widths per character.

==========================================================================
1) 

The Tk::Text::UpDown method won't work correctly if there are
embedded windows or images in the line (in contrast to the Tk::Text::UpDown_old method).
You can see this with the little program below. Don't forget the '-w' switch.

Besides, the cursor is not visible at the beginning of the line if
you don't add padding space to the windows/images (may be not a bug).

There is also a problem with Tk::TextUndo und embedding, which you can also
test with the appended program. If you delete a window/image and undo this,
you will get back the reference of the window/image as a string.

By the way, would it be possible to have characters/windows/images which
are not deleteable.

Greetings,

Johannes Gross


---------------
#!/usr/local/bin/perl -w
use Tk;
use Tk::TextUndo;

$m = MainWindow->new;
$t = $m->TextUndo->pack;
$w = sub { $t->Label( -text => 'Test', -foreground => 'red' ) };
$i = $m->Getimage( 'Camel' );

$t->windowCreate( 'end', -create => $w );
$t->insert( 'end', "abc\n" );
$t->windowCreate( 'end', -create => $w );
$t->insert( 'end', "abc\n" );
$t->windowCreate( 'end', -create => $w );
$t->insert( 'end', "abc\n" );
$t->imageCreate( 'end', -image => $i );
$t->insert( 'end', "abc\n" );
$t->imageCreate( 'end', -image => $i );
$t->insert( 'end', "abc\n" );
$t->imageCreate( 'end', -image => $i );
$t->insert( 'end', "abc\n" );

Tk::MainLoop;

===============================================================================

2) 

rectangular copy/cut/paste gets confused when tabs are involved.
and it cannot handle text of different font sizes, 
or fonts that are not constant width for every character.

what is needed is a method which can determine the number of
pixels from the left edge of the text to a given character
index (and also given a line number)


the worst case selection situation is the user
selects a corner on the screen (A) and then 
scrolls up or down off the screen,
moves the other corner left and right,
and then selects the other corner (B).

blah blah blah blah blah blah blah blah blah blah
 blah blah blah blah blah blah blah blah blah blah
    blah blah blah blah blah blah blah blah blah b
blah blah A <<== SELECTION POINT HERE blah bla
 blah blah blah blah blah blah blah blah blah blah
  blah blah blah blah blah blah blah blah blah bla
blah blah blah blah blah blah blah blah blah blah
 blah blah blah blah SCREEN BOUNDARY HERE blah bla
    blah blah blah -------------------------blah b
blah blah blah blah| blah blah blah blah bl|ah bla
 blah blah blah bla|h blah blah blah blah b|lah bl
  blah blah blah bl|ah blah blah blah blah |blah b
 blah blah blah bla|h blah blah blah blah b|lah bla
    blah blah blah |blah blah blah blah bla|h blah
blah blah blah blah| blah blah blah blah bl|ah blah
 blah blah SELECTIO|N POINT HERE ==>> B  bl|ah blah
  blah blah blah bl|ah blah blah blah blah |blah bl
 blah blah blah bla|h blah blah blah blah b|lah bl
  blah blah blah bl------------------------|ah bla
 blah blah blah blah SCREEN BOUNDARY HERE blah blah
    blah blah blah blah blah blah blah blah blah 

I can get the line.char indexes of A and B
(the start/stop points of the selection)

the problem is getting an X,Y pixel value for A
since it is off screen (bbox gives zeroes or undefs)
(A and all the lines between A and the visible screen)

actually, I dont care about the Y value for A or B.
I only care about the X values of A and B.
I could loop through the row numbers, and
just find out where the A(x) and B(x) characters
are and copy them to the clipboard.

the Y coordinate doesn't matter, since the rectangle 
code only needs to look at the X coordinate to determine
what text is inside the rectangle. THis should make
it easier to code.

at the very least, I would think that you would not 
have to start from the '1.0' index. you could just 
do it on a line by line basis.

so, the loop will go through line numbers, and pass in a X pixel
value, and ask for a character index in return for that line.


so, two methods are needed:

sub magic_line_dot_char_index_to_x_pixel_value
{
takes a line.char index as input, 
and returns a single integer, which is the
number of horizontal pixels from the left side of the text
to the index given.
}

this x_pixel_value is then saved away, 
and the copy/cut code will loop through
the line numbers, and call:

sub magic_line_number_and_x_pixel_value_to_char_index 
{
which takes a line number (from line.char) and a
x_pixel_value (which was determined above),
and it returns a fractional character index,
which indicates what character on that line 
the given x_pixel_value index lands on.
}

the character index could contain fractional data, 
(the rectangle cuts through a character on that line
due to odd font sizes, and other weirdness),
then it would left to the perl code (rectangular copy/cut/paste)
to decide whether to round up or down,
and then get a final line.char index to copy or cut.


I would think that it would be possible to do it on a line by line
basis, and not have to go through ALL the lines. just do the ones
requested by the loop.  since I dont care about the Y pixel value,
all that it needs to do is look at the indicated line,
count so many pixels over from the start fo the line, 
and then return the character index at that point.

finally, to make it easier to code this method, 
rectangular copy/cut/paste need only be supported
when the wrap mode is set to no-wrap.

If all the 'a's in this visible region 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaa|aaaaaaaaaaaaaaa|aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaa|aaaaaaaaaaaaaaa|aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaa|aaaaaaaaaaaaaaa|aa  
bbbbbbbbb|bbbbbbbbbbbbb  |
are on one 'line' because wrapmode was set to word or character,
then it becomes nearly intractable to determine the indexes
on a line by line basis. this would require the text widget
to draw the entire sequence of text, compensate for wrap,
and then realize that indexes for different "lines" might
actually be the same line of text.

so, to avoid this kettle of fish, rectangular copy/cut/paste
will only be supported in no-wrap mode.

==============================================================================

both problems are solved by the addition of two new methods.

sub magic_line_dot_char_index_to_x_pixel_value
sub magic_line_number_and_x_pixel_value_to_char_index 

which would probably need to be written in C to access 
some of the lower level data, and to get the speed needed
for all the calculations.

any volunteers to write these methods, 
contact me (Greg London) at <greg42@bellatlantic.net>
or Nick Ing-Simmons at <nick@ing-simmons.net>
to coordinate the effort.


Greg