From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ruy Exel Subject: Confusing org-cycle invocation when cursor is in invisible text Date: Fri, 15 Dec 2017 18:51:18 -0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ePwxe-0004VE-7Z for emacs-orgmode@gnu.org; Fri, 15 Dec 2017 15:52:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ePwxd-0006tR-C7 for emacs-orgmode@gnu.org; Fri, 15 Dec 2017 15:52:02 -0500 Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:34065) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ePwxd-0006rw-4i for emacs-orgmode@gnu.org; Fri, 15 Dec 2017 15:52:01 -0500 Received: by mail-wm0-x231.google.com with SMTP id y82so32119104wmg.1 for ; Fri, 15 Dec 2017 12:52:00 -0800 (PST) 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" To: emacs-org list I feel this issue might have already been raised here but after researching it I could not find anything relevant. So please ignore this message and excuse me if I am returning to something already discussed in this group. Consider the following simple tree structure ----- * Trees ** Pine It is a conifer ** Oak Place cursor here -> It belongs to the genus Quercus ----- If you place the cursor where indicated (i.e. after the sentence "Place cursor here ->" above) and press (org-shifttab), your buffer will show * Trees... with the cursor placed on the first of the three dots. If you then go to the kitchen to prepare a coffee and come back, you will probably not going to remember where the cursor was before the visibility went to the OVERVIEW state. Suppose you then decide to expand your tree by pressing (org-cycle) without having changed cursor position. In this case your buffer will turn to * Trees... ** Oak Place cursor here -> It belongs to the genus Quercus and you might then be led to thinking that your header "Trees" has only one sub-header, namely "Oak". Yes I know that the three dots after "Trees" is meant to indicate that there is still some hidden text but, given that your intention was to expand "Trees" and that you pressed the correct key for this purpose you might (incorrectly) feel assured that you achieved the appropriate goal and hence not pay due attention to the three dots. The point I want to raise is that I believe users should not be required to remember the position of the cursor when it falls inside hiddent text. Even more so, the state of the system at any given time should not depend on said position. Thus, after the first press of , above, the cursor should go by default to the beginning (maybe the end) of the hidden text. By the way, this behavior is already adopted when text becomes hidden due to a call to org-table-toggle-column-width. Regards, Ruy