Abdelrazak Younes wrote: > Georg Baum wrote: >> Abdelrazak Younes wrote: >> >>> Georg Baum wrote: >>>> This looks wrong (the rest looks OK). Do you know that b != >>>> work_area_->bufferView().buffer() is possible even after a >>>> work_area_->bufferView().setBuffer(b)? >>> This was indeed the case before my patch but look also at my >>> BufferView_pimp change. >> >> They do only change the behaviour if quitting == true. > > This plus my older changes to BufferView::setBuffer(), please read that > method and I think you will understand.
I think I do understand, but what I understand seems to differ from your view. >> b != >> work_area_->bufferView().buffer() is still possible. > > No, they may differ only if b == 0 which means that we are killing the > buffer. Exactly. And in this case you are now calling connectBuffer and setLayout. This was not done before. This does only make a difference if there still is a different buffer, but that happens for me quite often because I use lots of multipart documents. > I'll try to read the TortoiseSVN doc to do that. Great. With plain svn yo'll have to use a trick unfortunately (set diff-cmd = /home/me/bin/svndiff and call the real diff with arguments in svndiff). I don't know how that works with tourtoisesvn. >>> I've tested this patch with a lot of buffer switching and deletion. >> >> It may work, but I still think that the logic above is wrong. You are >> going to call connectBuffer and setLayout with an already connected >> buffer when b == 0. > > No, when b==0, BufferView::setBuffer() will switch to the first > available buffer in the bufferlist. And that buffer will be connected again. This was not done before. >> That may do no harm, but is AFAIK not necessary, and makes the code >> harder to understand. > > I agree that it is hard to understand and the main reason is that > setBuffer(0) for killing a buffer is not a good API. I'll try to clean > up that when I get some time. > > Is that any clearer? No :-( Georg
