From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Outline cycling does not preserve point's position Date: Sun, 8 Sep 2013 18:23:46 +0200 Message-ID: References: <868uz8sufg.fsf@somewhere.org> <86vc2cqvnb.fsf@somewhere.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A06E0C14-7532-4A0C-9A3A-C1B75835EAA4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIhmE-0003Az-Iw for emacs-orgmode@gnu.org; Sun, 08 Sep 2013 12:23:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VIhm9-000673-Um for emacs-orgmode@gnu.org; Sun, 08 Sep 2013 12:23:54 -0400 Received: from mail-we0-x229.google.com ([2a00:1450:400c:c03::229]:39487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIhm9-00066w-Kk for emacs-orgmode@gnu.org; Sun, 08 Sep 2013 12:23:49 -0400 Received: by mail-we0-f169.google.com with SMTP id t60so4597286wes.14 for ; Sun, 08 Sep 2013 09:23:47 -0700 (PDT) In-Reply-To: <86vc2cqvnb.fsf@somewhere.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Sebastien Vauban Cc: emacs-orgmode@gnu.org --Apple-Mail=_A06E0C14-7532-4A0C-9A3A-C1B75835EAA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7.9.2013, at 21:28, Sebastien Vauban wrote: > Hi Carsten, >=20 > Carsten Dominik wrote: >> On 7.9.2013, at 14:11, "Sebastien Vauban" = wrote: >>=20 >>> Since a little while, I've observed that point's position is not = anymore >>> preserved when cycling buffer's view with S-TAB. >>>=20 >>> Sometimes, point stays where it was (even when in the body of = entries); >>> sometimes, not. >>>=20 >>> See http://screencast.com/t/1sr6Lezk: >>>=20 >>> - when on the first letter of "From", in that example, point's = location is >>> preserved; >>>=20 >>> - when on the second letter of it, point's location is lost: new = position is >>> at the end of the level 1 parent... >>>=20 >>> That's very annoying when you want to just look at your tree = structure, but >>> don't expect to land somewhere else by doing so. >>=20 >> you say "since a little while". Have you tried to bisect? >=20 > Not yet. I have many Chinese plates turning at the moment, but I'll = try to do > that very soon. And I have other problems to report or bisect: >=20 > - not possible anymore to "cut" a code snippet in two parts with C-c = C-v C-d > (demarcate block); already reported (without bisect), no answer; >=20 > - not possible anymore to use C-a or C-e in code blocks to select = regions; not > reported yet, though I reported similar problems with C-arrows = (apparently > due to a change which is now officially part of 8.1). IMO, that = renders > editing of code block in the original buffer much more annoying. Also this is now fixed. Regards - Carsten >=20 >> Or has it been like this always? >=20 > In my mind, this did work before; or, at least, in (many) more cases = than it > now does. >=20 >> Also, I am not convinced that staying in invisible places is the >> right behavior at all. Even though I would agree that three S-TAB >> in a row should be a null operation. >=20 > At the very least, we could agree that point should always be part of = the > entry we were on; so never go up to the *parent* entry. >=20 >> May be it would be better to use something like >>=20 >> (org-display-outline-path nil t) >>=20 >> to see where you are? >=20 > I know where I am: I'm using that. But, sometimes (in fact, often), I = want to > see the rest of the entries (brothers, parents, etc.) in the outline = view. >=20 > I simply expect to land back at the entry I was at, when having cycled > 3 times. >=20 > Best regards, > Seb >=20 > --=20 > Sebastien Vauban --Apple-Mail=_A06E0C14-7532-4A0C-9A3A-C1B75835EAA4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlIspJIACgkQ9hweYzZiJkzpKwCghY85kaR5ajwUL7f9fN5RbR+0 eUIAoIurottcgKSq2FMHYATOzaRbB9dq =e3bE -----END PGP SIGNATURE----- --Apple-Mail=_A06E0C14-7532-4A0C-9A3A-C1B75835EAA4--