Hello Jean-Marc,
> Le 06/09/13 13:07, Hashini Senaratne a écrit :
I do not know whether this is a goo new or not. But with the following fix I
could solve that problem.
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index c53fd1d..1dc8f51 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -2856,14 +2856,15 @@ void checkCursorLeftEdge(PainterInfo & pi, Cursor const
pi.pain.setDrawingEnabled(false);
// No need to care about vertical position.
RowPainter rp(pi, bv.buffer().text(), cur.bottom().pit(), row, bidi, 0,
- rp.paintOnlyInsets();
+ //rp.paintOnlyInsets();
+ rp.paintText();
pi.pain.setDrawingEnabled(drawing);
It seems like paintOnlyInset() doen not call the function we want. Do we
need to optimize this more? Again is it not efficient to paint whole the text?
> > I did not get the role of 'buffer_.changed(false);'
>
> This is the part that starts the draw machinery. Here is the code from
> Buffer.cpp:
>
> void Buffer::changed(bool update_metrics) const
> {
> if (d->wa_)
> d->wa_->redrawAll(update_metrics);
> }
>
> What we do is force a redraw, although we know that most of the times
> Buffer::draw will not do anything.
Thank you for this explanation.
> > both cur.getLeftEdge() and left_edge become '0' just
> > after entering the Math inset. So above strategy change will not be executed
> > as cur.getLeftEdge() = left_edge.
>
> cur.getLeftEdge should not get reset without reason. Why does it happen?
This happens because as the cux_x resets to the leftmost position of the
relevant row. Because of that, it meets the following condition.
// If need to slide right
if (cur_x < left_edge + 10) {
left_edge = cur_x - 10;
}
There cur.getLeftEdge() becomes 0. Actually I could not mention, here I have
checked leftedge value after calling cur.setLeftEdge(left_edge).
> > By the way, I do not see any relationship between the case numbers in the
> > switch under BufferView::draw and the numbers I am getting for strategies. I
> > think that is nothing to worry about.
>
> What o you mean? They should be the same (but not the same as those in
> src/update_flags.h).
I meant the order of cases appearing in the switch. first case is case 0,
second is case 1. Should not these numbers which I am getting tally with
those cases? As I am getting 2 for FullScreenUpdate and 3 for
DecorationUpdate, it seems odd to me. That is why I mentioned. In order of
cases, FullScreenUpdate comes after DecorationUpdate.
> > Here is a set of data I got from debugging.
> > 1- indicates values before calculating left edge
> > 2- indicates values before calculating left edge
> > cur means - cur_x
>
> I cannot look at it right now, I'll try on monday.
Sure. I will try to solve the other bugs relating to
*selecting text position in an already slid row
*selecting range of text
*Home/ End problem (this also works fine after a simple mouse pointer movement)
