scroll "smartly" when scrolling to a too-big-to-be-displayed rect
This fixes calculation history navigation on big cells (that are bigger
than the displayed table)
This fixes crashes: indeed, in the way it was done before, we called
scrollToSubviewOfTypeOfCellAtLocation after setting the new selected subtype
and before reloading the data. However, selecting a new subtype might expand
the selected cell which can temper with the cell repartition. If so, we need to
reload the data to be able to call 'selectedCell' for instance.
Scenario: Create a new sequence which is the multiplication of a lot of
imaginary i. Save it (many multiplication sign are added), then try to
edit it again, in linear edition mode: the text overflows the buffer. If
we still copied it, it might get copied until the middle of a code point,
which would make the UTF8Decoder crash afterwards.
editing
This fixes the following bug: in solver, input Matrix(Matrix()) and select the
inner Matrix. When handling "OK" event, the "=0" is inserted at a wrong
position leading to a crash !
when a text cannot be inserted because it overflows the buffer, don't
add anything
insertTextAtLocation already behaves like this but handleEventWithText
used to cap the inserted text which sometimes leads to a different
behaviour - it would insert a truncated text
The buffer length did not take into account the \n removal. In fact, we
could just remove the \n while also removing the empty code points,
which is what we do now.
Scenario: Copy a text with \n (for instance from a script), then paste
it in a script name -> if \n are replaed with \0 instead of just being
removed, there are problems with the extension
This reverts commit d1ebbc685d67702994aa3ef822886a681cee63b9.
There were problems in the calculation app for instance:
- Write 34 then press ans -> the cursor is not drawn right of ans, but
left.
- Write a large layout, go up in th history, then go back to edition:
the view is not scrolled to the cursor
If nextFirstResponder is nullptr, it means we are exiting the app, so
there is no need to relayout, reselect, ...
We did it bbefore because a long time ago, we used to keep all apps side
by side so they had to be thouroughly cleaned when exiting
