From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: [patch] fix the behavior of C-u C-u TAB Date: Mon, 16 Dec 2013 18:57:57 -0500 Message-ID: <87vbyoe4ca.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsi37-00005p-2l for emacs-orgmode@gnu.org; Mon, 16 Dec 2013 18:58:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vsi36-0006H8-3l for emacs-orgmode@gnu.org; Mon, 16 Dec 2013 18:58:09 -0500 Received: from mail-qc0-x229.google.com ([2607:f8b0:400d:c01::229]:56862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsi35-0006H0-U5 for emacs-orgmode@gnu.org; Mon, 16 Dec 2013 18:58:08 -0500 Received: by mail-qc0-f169.google.com with SMTP id r5so4370967qcx.28 for ; Mon, 16 Dec 2013 15:58:07 -0800 (PST) Received: from localhost ([2607:f470:6:14:8a53:2eff:fe9f:5835]) by mx.google.com with ESMTPSA id n14sm50598475qav.8.2013.12.16.15.58.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Dec 2013 15:58:06 -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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "emacs-orgmode@gnu.org" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The keystroke C-u C-u TAB is supposed to set the visibility of the buffer to its initial state. At a minimum, I expect the second...nth consecutive use of this key combo to not change the visibility of the buffer at all. I have =E2=80=98org-startup-folded=E2=80=99 set to 'content= (i.e. show all headlines, but no text), and for me C-u C-u TAB instead cycles through various visibility states. Does anyone else observe this behavior? A reading of the code indicates that it should be a problem with org-startup-folded set to 'content, and possibly with the 'all value of that variable as well. The attached patch changes to a new implementation at the cost of sometimes doing extra cycling. (The problem is that we cannot rely on the org-cycle-global-status variable except immediately after a global cycle, and we can=E2=80=99t AFAICS know when we are immediately after such = an event. It might be better to set org-global-cycle-status to nil after any visibility-changing command, to indicate that its value is not to be trusted. But I think it would be difficult to exhaustively find all such functions, and then to differentiate between =E2=80=9Cgood=E2=80=9D us= es that hide e.g. archived subtrees and =E2=80=9Cbad=E2=80=9D uses that mess up the prop= er global visibility state by individually toggling a headline.) Comments welcome. Thanks, --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=0001-fix-C-u-C-u-TAB-set-visibility-to-initial-status.patch Content-Transfer-Encoding: quoted-printable >From af05e125fce67e916c317bc179461375f2eb179b Mon Sep 17 00:00:00 2001 From: Aaron Ecay Date: Mon, 16 Dec 2013 18:38:03 -0500 Subject: [PATCH] fix C-u C-u TAB -> set visibility to initial status MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * lisp/org.el (org-set-startup-visibility): refactor to work properly Previously, =E2=80=98org-set-startup-visibility=E2=80=99 would use a pre-ca= lculated number of trips through =E2=80=98org-cycle=E2=80=99 to get the right visibi= lity. This is fragile, and sometimes wrong. This new implementation instead loops until the visibility is correct (erroring out after 5 tries to avoid an infloop). --- lisp/org.el | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 59f55a8..07a2942 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6891,12 +6891,35 @@ With a numeric prefix, show all headlines up to tha= t level." =20 (defun org-set-startup-visibility () "Set the visibility required by startup options and properties." - (cond - ((eq org-startup-folded t) - (org-cycle '(4))) - ((eq org-startup-folded 'content) - (let ((this-command 'org-cycle) (last-command 'org-cycle)) - (org-cycle '(4)) (org-cycle '(4))))) + (let ((goal-state 'all) + ;; Hack the following two variables to make + ;; `org-cycle-internal-global' do the right thing; with these + ;; unbound it perseverates in the overview state. + (last-command 'org-cycle) + (this-command 'org-cycle)) + (cond + ((eq org-startup-folded t) + (setq goal-state 'overview)) + ((eq org-startup-folded 'content) + ;; Annoyingly 'content' is spelled with an 's' in one variable, + ;; and without in another. + (setq goal-state 'contents))) + ;; Cycle once unconditionally so that `org-cycle-global-status' is + ;; synced with the state of the buffer (this may turn out to be + ;; overly conservative). + (org-cycle '(4)) + (dotimes (_ 5) + ;; Now try to get into the right state. We try 5 times just to + ;; make sure, even though strictly speaking 3 is the maximum + ;; number of states we could progress thorugh; see the + ;; implementation of `org-cycle-internal-global'. + (unless (eq org-cycle-global-status goal-state) + (org-cycle '(4)))) + ;; Something weird is going on; we cannot get into the right + ;; state. Error out and hope this prompts a bug report. + (unless (eq org-cycle-global-status goal-state) + (error "Could not get the correct visibility state after trying 5 ti= mes!"))) + (unless (eq org-startup-folded 'showeverything) (if org-hide-block-startup (org-hide-block-all)) (org-set-visibility-according-to-property 'no-cleanup) --=20 1.8.5.1 --=-=-= Content-Type: text/plain -- Aaron Ecay --=-=-=--