Hello Jean-Marc, Hope you returned safely.
> > It seems to me, I have not clearly understood this matter till now. I doubt > > how we can call rp.drawOnlyInsets(...); before left_edge computations, as we > > are only creating the RowPainter object after those calculations. > > See my other message, you should be able to create another RowPainter > object. I tried this but as you mentioned in the other method, but could not see nay positive outcome. But I tried something else with your help, as mentioned below. > I bet that debugging will tell you that no drawing occurs in this case, > probably because in BufferView::draw, update_strategy is NoScreenUpdate. > This means that it is possible to draw cursor at start of row, but not > at end of row. > > What this means is that, the code that sets left edge should be moved in > its own TextMetrics method (checkCursorScroll or something) and this > method should be called before the swith() in BufferView::draw. Then, if > needed the update strategy should be changed, so that some drawing > actually takes place. Does this make sense? I also debugged the code and finally came to BufferView::draw. I believe that this update_strategy is affecting the problem that we have (unintended sliding of row when entering Math inset from the right side). First of all I tried draw again after all the cases of the switch statement by calling tm.draw(pi, 0, y); again. This gave an positive outcome. No unexpected sliding happened at that certain point (entering Math from right). But just after entered, unwanted dash (-/ dash/ minus mark) showed between the right edge of the screen. Appearing sign/ part of the letter differs when the screen size is changed (I am not using a maximized screen). So this part of the letter is something is the equation, appearing at the right edge when the row is not slid. Then I removed the added line and called it again just after the drawing method stated in the last case: "FullScreenUpdate". I could get the same observations as I mentioned above. So I doubt whether this is to do with NoScreenUpdate. I thought code under the comment "// and possibly grey out below" is something to do with this (Something like erasing the unwanted painted part). So I simply used a for loop to call twice the whole content under the case : "FullScreenUpdate". I know is this not a good approach. But this solved the problem I was suffering for weeks. Perhaps we can call this only when a sliding occurs. Please guide me through this. I see that redrawing all the time is not efficient. This automatically fixed the problem we had with the Home and End key presses. But although I believed that this would solve all the other problems, still the problem relating to selecting a different point of an already slid row and selection of a range of text is not completely solved. The selected point is slid to the right edge (But the previous problem what we had with sliding to the leftmost position is solved). Thank you Hashini
