Helge Hafting wrote: > The patch applied to today's cvs (16/3-2005) and compiled fine. > > >Helge Hafting wrote: > >>* select cells, press C-M for math. Crash! No, I don't see how this > >> could be useful, so ignoring operations on selections when > >> the current selection doesn't fit the operation would be fine here. > > > >Yes, we forgot this. The attached patch includes it. > > This works fine now. I get "command disabled" if some table > cells are selected and I press C-M > > Another oddity: Select text, press C-M. The text becomes math, which is > ok. Select text that contains an entire table. Press C-M. The table turns > into an ascii representation of the table, which in turn gets embedded in > the math without linefeeds. Strange on screen and strange in the dvi. I can > see that cut&pasting tables as ascii representations is useful when pasting > them into something else, like a text editor. This wasn't useful at all, > particularly considering the lack of line feeds. Table cell content was > preserverd though. > This is not a regression, 1.3.4 does the same. Strange and ugly, but > not much of a problem - people rarely try this. > > In this case, the ideal solution is to convert the table to a math matrix. > If that is too much to ask at this point, just refuse the operation.
Yes, I agree. You can file a report on bugzilla (for the next development cycle, i.e. 1.5). > >> I also noticed that selecting some normal text (not in a table) > >> and inserting a table erases the selected text, there is no > >> attempt to get it into the table. This makes more sense, > >> the selection is replaced by the table. Getting the text > >> into the table (using some space-separated or comma- > >> separated heuristic) might be nice and useful, but I guess this > >> isn't the time for new features? > > > >I cannot reproduce. When I select some text outside a table and insert a > > table over the selection, the text gets inserted in the first cell (as in > > 1.3) > > I can no longer reproduce it either. I guess it got fixed > between the two checkouts. > >>* Exiting a table cell with left arrow moves to the previous > >> cell. But it moves to the start of the cell, I expected to get > >> to the end of the cell. This makes a difference when there > >> is long text in the cells. > > > >Regression. Fixed by > >- cur.pit() = 0; > >- cur.pos() = 0; > >+ cur.pit() = cur.lastpit(); > >+ cur.pos() = cur.lastpos(); > >in InsetTabular::movePrevCell > >(see patch). > > This works now, great! > > >>* Using up & down arrows in a table is strange. > >> If the cursor is in the middle of long text in one cell, then > >> I expect it to get it to somewhere in the middle of the text > >> in the cell above/below. This works, but in a strange cumbersome way: > >> At first keypress, the cursor moves to the correct cell, but > >> to the beginning or the end depending on wether it was a > >> down or up key. Odd. The next keypress gets the cursor into > >> the location I expected! Cumbersome because it is twice as > >> many keypresses. Seems the functionality I look for exists though. > > > >No regression, though probably easily fixable. > > > >Can you please test if the attached patch fixes the things I have promised > > and if there are no regressions introduced by the patch? > > I saw no regressions, but one never knows for sure. :-) Good, thanks for testing. JÃrgen > Helge Hafting
