From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tod Middlebrook <whatifitsnot@gmail.com>
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: Mon, 11 Nov 2013 16:22:43 -0600
Message-ID: <87siv24lzg.fsf@gmail.com>
References: <87txfjy3vg.fsf@gmail.com> <874n7iho2t.fsf@bzg.ath.cx>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42679)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <whatifitsnot@gmail.com>) id 1Vfzsi-0004Jx-FE
	for emacs-orgmode@gnu.org; Mon, 11 Nov 2013 17:22:57 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <whatifitsnot@gmail.com>) id 1Vfzsd-0003oJ-N5
	for emacs-orgmode@gnu.org; Mon, 11 Nov 2013 17:22:52 -0500
In-reply-to: <874n7iho2t.fsf@bzg.ath.cx>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org

Bastien,
When there is no property drawer before the code block, C-c C-x p
affects the code block and either doesn't create a property drawer or it
leaves the 'real' property drawer unaffected.

An example for the second case, where org-set-property matches the code
block, despite an existing property drawer that happens to be below
it. The wrong "NAME" is matched, and "DEPENDS" isn't matched at
all. This could throw off for example org-dotemacs, where it would
tangle code blocks in the wrong order without the DEPENDS matching.
* stuff for bug report
#+BEGIN_SRC emacs-lisp
  
  (setq org-capture-templates
        (quote
         (
          ("c" "Contacts" entry (file+headline "~/my-stuff/file.org" "Contacts")
           "* %^{Name: }
          :PROPERTIES: 
          :EMAIL: %^{Email}
          :PHONE: %^{Phone number}
          :NAME: %^{Full Name}
          :END:
          %?
          "))))
#+END_SRC
:PROPERTIES:
:NAME: org-capture-templates
:DEPENDS: org
:END: 

Thanks,
Tod

bzg@gnu.org writes:

> Hi Tod,
>
> Tod Middlebrook <todmiddlebrook@gmail.com> writes:
>
>> The bug below prevents me from easily using dependencies in org-dotemacs.
>>
>> To reproduce,
>> start with this entry:
>>
>> *** stuff for bug report
>> #+BEGIN_SRC emacs-lisp
>>   (setq org-capture-templates
>>         (quote
>>          (
>>           ("c" "Contacts" entry (file+headline "~/my-stuff/file.org" "Contacts")
>>            "* %^{Name: }
>>           :PROPERTIES: 
>>           :EMAIL: %^{Email}
>>           :PHONE: %^{Phone number}
>>           :END:
>>           %?
>>           "))))
>> #+END_SRC
>>
>> Then do C-c C-x p EMAIL [RET] TestValue, and get the same block, with
>> the properties drawer folded. When expanded, there is:
>>
>> *** stuff for bug report
>> #+BEGIN_SRC emacs-lisp
>>     (setq org-capture-templates
>>           (quote
>>            (
>>             ("c" "Contacts" entry (file+headline "~/my-stuff/file.org" "Contacts")
>>              "* %^{Name: }
>>             :PROPERTIES: 
>>   :EMAIL:    TestValue
>>             :PHONE: %^{Phone number}
>>             :END:
>>             %?
>>             "))))
>> #+END_SRC
>
> I'm not sure to understand what the problem is exactly: if the problem
> is that `C-x C-c p' works in the context of source code blocks, we can
> easily fix it.  If the problems is that such properties are matched in
> contexts where they should not, we need more information about when
> you observe the wrong behavior, i.e. in what context do you see the
> properties taken into account while you expect them to be ignored?
>
> Thanks in advance for further details,