From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noorul Islam Subject: [PATCH] Re: bug in the :VISIBILITY: handling of nested "folded" properties? Date: Sat, 7 Aug 2010 11:34:18 +0530 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=000e0cd5d0b2cfaaaa048d358d68 Return-path: Received: from [140.186.70.92] (port=42099 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OhcW5-0005pG-Ch for emacs-orgmode@gnu.org; Sat, 07 Aug 2010 02:04:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OhcW3-0001mV-OM for emacs-orgmode@gnu.org; Sat, 07 Aug 2010 02:04:21 -0400 Received: from mail-gx0-f169.google.com ([209.85.161.169]:40042) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OhcW3-0001mM-Lf for emacs-orgmode@gnu.org; Sat, 07 Aug 2010 02:04:19 -0400 Received: by gxk4 with SMTP id 4so4147332gxk.0 for ; Fri, 06 Aug 2010 23:04:18 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rainer Stengele Cc: emacs-orgmode@gnu.org --000e0cd5d0b2cfaaaa048d358d68 Content-Type: multipart/alternative; boundary=000e0cd5d0b2cfaa9d048d358d66 --000e0cd5d0b2cfaa9d048d358d66 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jul 30, 2010 at 4:38 PM, Rainer Stengele wrote: > Having > > * headline 1 > :PROPERTIES: > :VISIBILITY: folded > :END: > ** headline 2.1 > - stuff > ** headline 2.1 > :PROPERTIES: > :VISIBILITY: folded > :END: > - stuff > > C-u C-u > Switch back to the startup visibility of the buffer, i.e. whatever is > requested by startup options and =91VISIBILITY=92 properties in individua= l > entries. > > > does not result in > > > * headline 1...> > > > as expected. Instead I get: > > > * headline 1...> > ** headline 2.1...> > ** headline 2.1...> > > > removing the second folded propertiy results correctly in: > > * headline 1...> > > > This looks like a bug in the :VISIBILITY: handling!? > > > I am not sure whether this is a bug. But it looks like the above scenario was not considered initially. I might be wrong. The attached patch seems to solve this problem. * lisp/org.el: org-set-visibility-according-to-property () Use backward search instead of forward, so that top hierarchy gets priority. Thanks and Regards Noorul --000e0cd5d0b2cfaa9d048d358d66 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 30, 2010 at 4:38 PM, Rainer = Stengele <rainer.stengele@online.de> wrote:
Having

* headline 1
:PROPERTIES:
:VISIBILITY: folded
:END:
** headline 2.1
=A0- stuff
** headline 2.1
:PROPERTIES:
:VISIBILITY: folded
:END:
- stuff

C-u C-u <TAB>
=A0 =A0Switch back to the startup visibility of the buffer, i.e. whatever = is requested by startup options and =91VISIBILITY=92 properties in individu= al entries.


does not result in


* headline 1...>


as expected. Instead I get:


* headline 1...>
** headline 2.1...>
** headline 2.1...>


removing the second folded propertiy results correctly in:

* headline 1...>


This looks like a bug in the :VISIBILITY: handling!?



I am not sure whether this is a bug. = =A0But it looks like the above scenario was not considered initially. I mig= ht be wrong.=A0

The attached patch seems to solve = this problem.

* lisp/org.el:=A0org-set-visibility-according-to-proper= ty ()
=A0=A0Use backward search instead of forward, so that top h= ierarchy gets priority.

Thanks and Regards
Noorul

--000e0cd5d0b2cfaa9d048d358d66-- --000e0cd5d0b2cfaaaa048d358d68 Content-Type: text/plain; charset=US-ASCII; name="org-visibility.txt" Content-Disposition: attachment; filename="org-visibility.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gck27csd0 ZGlmZiAtLWdpdCBhL2xpc3Avb3JnLmVsIGIvbGlzcC9vcmcuZWwKaW5kZXggMTliMjhhMy4uYzg0 MDliNSAxMDA2NDQKLS0tIGEvbGlzcC9vcmcuZWwKKysrIGIvbGlzcC9vcmcuZWwKQEAgLTU5NjIs OCArNTk2Miw4IEBAIFdpdGggYSBudW1lcmljIHByZWZpeCwgc2hvdyBhbGwgaGVhZGxpbmVzIHVw IHRvIHRoYXQgbGV2ZWwuIgogICAoaW50ZXJhY3RpdmUpCiAgIChsZXQgKG9yZy1zaG93LWVudHJ5 LWJlbG93IHN0YXRlKQogICAgIChzYXZlLWV4Y3Vyc2lvbgotICAgICAgKGdvdG8tY2hhciAocG9p bnQtbWluKSkKLSAgICAgICh3aGlsZSAocmUtc2VhcmNoLWZvcndhcmQKKyAgICAgIChnb3RvLWNo YXIgKHBvaW50LW1heCkpCisgICAgICAod2hpbGUgKHJlLXNlYXJjaC1iYWNrd2FyZAogCSAgICAg ICJeWyBcdF0qOlZJU0lCSUxJVFk6WyBcdF0rXFwoW2Etel0rXFwpIgogCSAgICAgIG5pbCB0KQog CShzZXRxIHN0YXRlIChtYXRjaC1zdHJpbmcgMSkpCg== --000e0cd5d0b2cfaaaa048d358d68 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode --000e0cd5d0b2cfaaaa048d358d68--