From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Bug: property drawers within code blocks interfere [8.2.2 (8.2.2-elpa @ /home/tod/.emacs.d/.cask/24.3.50.1/elpa/org-20131108/)] Date: Tue, 12 Nov 2013 22:44:08 +0100 Message-ID: <87vbzxqorb.fsf@bzg.ath.cx> References: <87txfjy3vg.fsf@gmail.com> <874n7iho2t.fsf@bzg.ath.cx> <87siv24lzg.fsf@gmail.com> <87mwladulx.fsf@bzg.ath.cx> <87y54t28y2.fsf@gmail.com> <87vbzx6g31.fsf@bzg.ath.cx> <8761rxb97r.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgLkz-0000ib-Ju for emacs-orgmode@gnu.org; Tue, 12 Nov 2013 16:44:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgLkr-0005YH-7c for emacs-orgmode@gnu.org; Tue, 12 Nov 2013 16:44:21 -0500 Received: from mail-wg0-x22c.google.com ([2a00:1450:400c:c00::22c]:43328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgLkr-0005Xy-0i for emacs-orgmode@gnu.org; Tue, 12 Nov 2013 16:44:13 -0500 Received: by mail-wg0-f44.google.com with SMTP id k14so5001268wgh.23 for ; Tue, 12 Nov 2013 13:44:12 -0800 (PST) In-Reply-To: <8761rxb97r.fsf@gmail.com> (Aaron Ecay's message of "Tue, 12 Nov 2013 16:28:56 -0500") 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: Aaron Ecay Cc: Tod Middlebrook , emacs-orgmode@gnu.org Hi Aaron and Tod, Aaron Ecay writes: > This seems like an excellent use case for the parser: basically a bunch > of uses of org-*-regexp and org-re-property need to be augmented with > a check like: > (not (memq (org-element-type (org-element-at-point)) '(src-block example-block ...))) > > A better alternative might be to use the parser to find the property > drawer in the first place (instead of a regex). Either way, it seems > like the best strategy might be to fix all uses of these problem > variables at once, which is a big undertaking. Also don't forget the cost in terms of speed. It's fine to fix the behavior of Org for such cases, but those cases are rare, and could be explicitely prevented. If the general fix does not slow down the parsing too much, then I'm all for it. Nicolas might have better insight here than me. 2 cents, -- Bastien