Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 392AB429E25 for ; Tue, 24 May 2011 15:16:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiVeIBgPkrLn for ; Tue, 24 May 2011 15:16:01 -0700 (PDT) Received: from mail-fx0-f53.google.com (mail-fx0-f53.google.com [209.85.161.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 2E028431FB6 for ; Tue, 24 May 2011 15:16:01 -0700 (PDT) Received: by fxm8 with SMTP id 8so5348794fxm.26 for ; Tue, 24 May 2011 15:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-type; bh=RkmiHTrFufFWBbh+jjK0wYrcVEsmck/G3uqXBvALaUg=; b=C07OBUo7veewdxkFdhaSaCseoaWFlq1UNuR+33XQddDWrD81DFyABEOEae/I6s4M0e wrMyhA4lx9CHetnod2Nn+CX0zMBipakUpe9ZtoVRRkdPz0PQNKbLeRkMs7zfoMbvSOnd qcU4UYiX5wFRQxf2yLi9aJ3tfWEAWLF7EqiTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:in-reply-to:references:user-agent:date:message-id :mime-version:content-type; b=BzQ+LCDbWcy3sOEGreFm6hyGB/aCwMiEviPZYZ4mGx6kmXUwFX3+N42SeTYRDgbErt VybAhymjSuk3cXYPUviV0SRPC83KkoZEtFiR8iR8FO3QzwDB5MbMC+lMyxfRLHDCiSrm zrPVjItyKC+hex0zAng/vf7TNqSY9HE+FUYDE= Received: by 10.223.158.72 with SMTP id e8mr4143637fax.39.1306275343345; Tue, 24 May 2011 15:15:43 -0700 (PDT) Received: from localhost ([91.144.186.21]) by mx.google.com with ESMTPS id b17sm2878653fab.47.2011.05.24.15.15.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 15:15:42 -0700 (PDT) From: Dmitry Kurochkin To: Carl Worth , notmuch@notmuchmail.org Subject: Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'. In-Reply-To: <87oc2rvjvj.fsf@yoom.home.cworth.org> References: <1306090675-26982-1-git-send-email-dmitry.kurochkin@gmail.com> <1306164587-20326-1-git-send-email-dmitry.kurochkin@gmail.com> <87oc2rlujb.fsf@yoom.home.cworth.org> <8762ozrfrr.fsf@gmail.com> <87oc2rvjvj.fsf@yoom.home.cworth.org> User-Agent: Notmuch/0.5-216-g0104e23 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Wed, 25 May 2011 02:16:06 +0400 Message-ID: <871uznrbh5.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:16:02 -0000 On Tue, 24 May 2011 15:01:04 -0700, Carl Worth wrote: > On Wed, 25 May 2011 00:43:20 +0400, Dmitry Kurochkin wrote: > > Now, looking at Emacs source code, save_excursion_save() uses > > point_marker() to save the point. As you said above, markers are > > updated when the corresponding text is updated. That explains why the > > cursor jumps when using `save-excursion'. > > > > On the other hand, `point' returns position as an integer. Which is > > just what we need. > > Ah. So that explains why your patch is actually making a difference. > > But I've usually had "jumping cursor" problems when using an integer, > (and switching to a marker fixes it). For example, imagine the following > operation: > > User positions cursor on some word > Our code saves point as an integer > Some operation inserts new text before point > Our code restores the cursor to the saved integer > > This sequence restores point to the same integer position in the buffer, > but logically makes the cursor appear to "jump" to the user, (since the > cursor will no longer be on the word it was on before but will now be > earlier in the buffer). > > The fix for the above is to switch from an integer to a marker. > Ah, I see now. > So I'm curious to know the case you're hitting where you getbetter > behavior by switching from a marker to an integer. Can you describe it > in a bit more detail? > I did not find a better way to update the button label than to: 1. insert the new label 2. move the button overlay from the old label to the new one 3. remove the old label When a user clicks the button, the cursor is somewhere inside the old label. If we save the point as a marker, after step 3 it would end up at the position where the old label was. If the new label is inserted before the old one, that means after the new label. So the cursor jumps from inside the button to the position after the button. Since the new button is placed at the same position where the old one was, restoring the point to the same offset it was at the beginning works as we need. Regards, Dmitry > -Carl Non-text part: application/pgp-signature