From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [BUG] in org-property-drawer-re? Date: Wed, 02 Oct 2013 13:38:29 +0200 Message-ID: <87txgz298q.fsf@gmail.com> References: <87r4c4519w.fsf@gmail.com> <87li2ct2t3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRKlX-0000Lx-6s for emacs-orgmode@gnu.org; Wed, 02 Oct 2013 07:38:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRKlR-0003ow-85 for emacs-orgmode@gnu.org; Wed, 02 Oct 2013 07:38:51 -0400 Received: from plane.gmane.org ([80.91.229.3]:35356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRKlQ-0003ok-Ug for emacs-orgmode@gnu.org; Wed, 02 Oct 2013 07:38:45 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VRKlP-0006nW-2M for emacs-orgmode@gnu.org; Wed, 02 Oct 2013 13:38:43 +0200 Received: from e178062065.adsl.alicedsl.de ([85.178.62.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Oct 2013 13:38:43 +0200 Received: from tjolitz by e178062065.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Oct 2013 13:38:43 +0200 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 Nicolas Goaziou writes: Hello, > Carsten Dominik writes: > >> This is just a cheep way to match any character at all, because \000 should >> not be part of any string (in C it indicates the end of a string). >> In principle you could put any character you are sure will not turn up, >> but \000 seems to be the safest choice. It is >> faster (I think) than "\\(.\\|\n\\)*" because the first will >> just run fast and streight with a table lookup while the >> latter need to always alternate between two alternatives. >> I have not timed it, though. > > On that topic, I would add that "^\000" must be used with care, as it > can lead to a stack overflow in regexp matcher error quite easily. In > particular, it may be safe to use it to match a property drawer, which > will not be very large, but I think it's wrong to use it to match > regular blocks or drawers, which can have arbitrary long size. > > For example a regexp like "[^\000]\\." will fail when matching around > 500 lines (72 characters long). Of course, constructs like > "\\(.\\|\n\\)*\\." will also fail, but my point is that it is tempting > to use "^\000" even though a regexp may not be the correct answer to the > problem. Conceptually it looks perfect(ly simple) to me, and I'm happy that I discovered the pattern now by accident (better late than never), but stack overflow is of course an important point. Reminds me of my little [[https://github.com/tj64/org-hlc][org-hlc.el]] library (hidden lines cookies) ,------------------------------------------------------------------------------- | org-hlc.el implements hidden-lines-cookies for Org-mode | | hidden-lines-cookies (hlc) are small cookies at the end of each folded (and | visible) headline in an Org-mode buffer that show the number of hidden lines | before the next visible headline. | | hidden-lines-cookies can be handled with three user commands: | org-hlc-show-hidden-lines-cookies, org-hlc-hide-hidden-lines-cookies, and the | convenience command org-hlc-toggle-hidden-lines-cookies that toggles between | the two other commands conditional on the last one executed. | | The appearance of the cookies can be customized by changing the values of four | customizable variables: org-hlc-hidden-lines-cookie-left-delimiter (with | default value "["), org-hlc-hidden-lines-cookie-right-delimiter (with default | value "]"), org-hlc-hidden-lines-cookie-left-signal-char (with default value | "#") and org-hlc-hidden-lines-cookie-right-signal-char (with default value | ""). | | Thus an exemplary folded headline with 165 hidden lines before the next | visible headline might look like this when hidden-lines-cookies are shown: | | ,----------------- | *** Headline [#165] `----------------- | `------------------------------------------------------------------------------- that was conceptually all 'wrong': - the cookies are written in the original buffer (but that could easily be changed to a temporary indirect buffer) - cookies are only shown/updated with explicit user commands but it works even in 7000 lines .el or .org files. The other attempt to 'do it right' based on a library by Francois Pinard, [[https://github.com/tj64/org-weights][org-weights.el]], uses overlays and dynamic updates of the tree-weights via change hooks - much better in theory - but somehow overwhelms Emacs capacities in big files so that user experience is affected. -- cheers, Thorsten