On Tue, Feb 14, 2006 at 04:07:44PM +0000, John Spray wrote: > Am Dienstag, den 14.02.2006, 17:14 +0200 schrieb Martin Vermeer: > > > Let me check that I understand the logic correctly: > > > When we first show the dialog, if controller.changed() returns true then > > > there are changes to be merged, and if it returns false then there are > > > no changes to be merged. Correct? > > > > ...at the cursor location. Correct. > > > > Does your patch work correctly? > > Excellent question... > > No. > > Now that I play with it a bit, I find that having a controller().find() > called in my update() is absolutely fine as long as update() is only > called once - update() was getting called twice (my code's fault) and > that was causing the first change to get skipped. > > The patch that I sent actually broke it, since without calling > controller.find() the first change wasn't highlighted. > > So I've fixed the GTK frontend by getting rid of the duplicate update() > call (which hopefully won't break any other dialogs, I can't remember > why I put it in show() to begin with). > > Executive summary: my previous patch for this is not necessary. > > John
But did you test this together with my fix for 2212, i.e., including my changes to BufferView_pimpl.C? This changes the logic. You should _not_ call controller().find() in update. That's precisely the faulty logic that my patch removes. (You do it in onNext, which should suffice.) So I suspect your original patch was OK. Please test it together with my fix. - Martin
pgplE6nmB18lT.pgp
Description: PGP signature
