org-collector unable to handle macros

org-collector unable to handle macros

[Mark Edgington]

I have had problems getting org-collector.el to generate tables where the
content of the tables should include macros.  At some point in the past this
worked, but at this time (latest git version of org-mode), the following
example fails (unless you remove the macro from the property definition):

# comment-macro
#+MACRO: c 

* Notes
:PROPERTIES: 
:ID: sched_table
:COLUMNS:  %WEEKNUM(Week #) %DAY(Day) %INCLASS(In-class Content)
%READINGS(Readings) %PRECLASS(Pre-class Assignments / Homework)
:END:
** WEEK 1
*** DAY
:PROPERTIES:
:INCLASS:  ABC {{{c(stuff)}}} DEF
:DAY:      T
:WEEKNUM:  1
:END:
blah

* Schedule
# type C-c C-c on the #BEGIN line to attempt to generate the table
#+BEGIN: propview :id "sched_table" :defaultval "" :conds ((not (string= DAY
""))) :cols (WEEKNUM DAY INCLASS READINGS PRECLASS) :noquote t :colnames
("Week #" Day "In-class Content" "Readings" "Pre-class Assignments / Homework")

#+END:


Any help in resolving this problem would be appreciated!  Thanks.

Re: org-collector unable to handle macros

[Charles Millar]

This may be related to the problem or is the same that I reported in 
April and May and again earlier this month when Bastien's requested 
details in his August 4th message.

org-collector does not work with org 8.3, but does with 8.2.10

Charlie Millar

On 08/28/2015 02:11 PM, Mark Edgington wrote:
> I have had problems getting org-collector.el to generate tables where the
> content of the tables should include macros.  At some point in the past this
> worked, but at this time (latest git version of org-mode), the following
> example fails (unless you remove the macro from the property definition):
>
> # comment-macro
> #+MACRO: c
>
> * Notes
> :PROPERTIES:
> :ID: sched_table
> :COLUMNS:  %WEEKNUM(Week #) %DAY(Day) %INCLASS(In-class Content)
> %READINGS(Readings) %PRECLASS(Pre-class Assignments / Homework)
> :END:
> ** WEEK 1
> *** DAY
> :PROPERTIES:
> :INCLASS:  ABC {{{c(stuff)}}} DEF
> :DAY:      T
> :WEEKNUM:  1
> :END:
> blah
>
> * Schedule
> # type C-c C-c on the #BEGIN line to attempt to generate the table
> #+BEGIN: propview :id "sched_table" :defaultval "" :conds ((not (string= DAY
> ""))) :cols (WEEKNUM DAY INCLASS READINGS PRECLASS) :noquote t :colnames
> ("Week #" Day "In-class Content" "Readings" "Pre-class Assignments / Homework")
>
> #+END:
>
>
> Any help in resolving this problem would be appreciated!  Thanks.
>
>
>

Re: org-collector unable to handle macros

[Mark Edgington]

Charles Millar <millarc <at> verizon.net> writes:

> This may be related to the problem or is the same that I reported in 
> April and May and again earlier this month when Bastien's requested 
> details in his August 4th message.

Have you (or anyone else) been able to reproduce the problem given the
example which I provided?  Is this indeed a bug, or am I misunderstanding
something?

Re: org-collector unable to handle macros

[Nicolas Goaziou]

Hello,

Mark Edgington <edgimar@gmail.com> writes:

> Charles Millar <millarc <at> verizon.net> writes:
>
>> This may be related to the problem or is the same that I reported in 
>> April and May and again earlier this month when Bastien's requested 
>> details in his August 4th message.
>
> Have you (or anyone else) been able to reproduce the problem given the
> example which I provided?  Is this indeed a bug, or am I misunderstanding
> something?

  :INCLASS:  ABC {{{c(stuff)}}} DEF

looks incorrect. Macros are not expanded in node properties (with an
exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).


Regards,

-- 
Nicolas Goaziou

Re: org-collector unable to handle macros

[Mark Edgington]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On Aug 31, 2015 6:43 PM, "Nicolas Goaziou" <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> Mark Edgington <edgimar@gmail.com> writes:
>
> > Charles Millar <millarc <at> verizon.net> writes:
> >
> >> This may be related to the problem or is the same that I reported in
> >> April and May and again earlier this month when Bastien's requested
> >> details in his August 4th message.
> >
> > Have you (or anyone else) been able to reproduce the problem given the
> > example which I provided?  Is this indeed a bug, or am I
misunderstanding
> > something?
>
>   :INCLASS:  ABC {{{c(stuff)}}} DEF
>
> looks incorrect. Macros are not expanded in node properties (with an
> exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).

It is not intended to be expanded when generating the table, but the table
should have the macro in it, so that it gets expanded when the table is
exported.

[-- Attachment #2: Type: text/html, Size: 1273 bytes --]

Re: org-collector unable to handle macros

[Nicolas Goaziou]

Mark Edgington <edgimar@gmail.com> writes:

> On Aug 31, 2015 6:43 PM, "Nicolas Goaziou" <mail@nicolasgoaziou.fr> wrote:
>>
>> Hello,
>>
>> Mark Edgington <edgimar@gmail.com> writes:
>>
>> > Charles Millar <millarc <at> verizon.net> writes:
>> >
>> >> This may be related to the problem or is the same that I reported in
>> >> April and May and again earlier this month when Bastien's requested
>> >> details in his August 4th message.
>> >
>> > Have you (or anyone else) been able to reproduce the problem given the
>> > example which I provided?  Is this indeed a bug, or am I
> misunderstanding
>> > something?
>>
>>   :INCLASS:  ABC {{{c(stuff)}}} DEF
>>
>> looks incorrect. Macros are not expanded in node properties (with an
>> exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).
>
> It is not intended to be expanded when generating the table, but the table
> should have the macro in it, so that it gets expanded when the table is
> exported.

OK. Then another problem:

  :ID: sched_table

ID properties are meant to be set with `org-id'. What about using
CUSTOM_ID instead?


Regards,

Re: org-collector unable to handle macros

[Mark Edgington]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

> >>
> >>   :INCLASS:  ABC {{{c(stuff)}}} DEF
> >>
> >> looks incorrect. Macros are not expanded in node properties (with an
> >> exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).
> >
> > It is not intended to be expanded when generating the table, but the
table
> > should have the macro in it, so that it gets expanded when the table is
> > exported.
>
> OK. Then another problem:
>
>   :ID: sched_table
>
> ID properties are meant to be set with `org-id'. What about using
> CUSTOM_ID instead?

When using CUSTOM_ID, I get the following message (and the table generation
fails):

condition-case: (error Cannot find entry with :ID: sched_table)

Is this not the case for you?  I have enabled org-collector via M-x
customize-variable <RET> org-modules.

[-- Attachment #2: Type: text/html, Size: 1022 bytes --]

Re: org-collector unable to handle macros

[Mark Edgington]

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:

> 
> Mark Edgington <edgimar <at> gmail.com> writes:
> 
> > On Aug 31, 2015 6:43 PM, "Nicolas Goaziou" <mail <at> nicolasgoaziou.fr>
wrote:
> >>
> >> Hello,
> >>
> >> Mark Edgington <edgimar <at> gmail.com> writes:
> >> >
> >> > Have you (or anyone else) been able to reproduce the problem given the
> >> > example which I provided?  Is this indeed a bug, or am I
> > misunderstanding
> >> > something?
> >>
> >>   :INCLASS:  ABC {{{c(stuff)}}} DEF
> >>
> >> looks incorrect. Macros are not expanded in node properties (with an
> >> exception for :EXPORT_SOMETHING: when #+SOMETHING is parsed).
> >
> > It is not intended to be expanded when generating the table, but the table
> > should have the macro in it, so that it gets expanded when the table is
> > exported.
> 
> OK. Then another problem:
> 
>   :ID: sched_table
> 
> ID properties are meant to be set with `org-id'. What about using
> CUSTOM_ID instead?

Hi Nicolas,

Can you explain what you mean about using CUSTOM_ID in the context of
org-collector?  Maybe I misunderstood something.  Do you think the reason
that a table can't be generated from my example code is that org-collector
is somehow trying to expand the macros when the table is generated?  I
assume that the correct behavior should be for it to *not* expand macros,
and just pass them through verbatim into the table-fields.

Regards,

Mark

Re: org-collector unable to handle macros

[Nicolas Goaziou]

Mark Edgington <edgimar@gmail.com> writes:

> Can you explain what you mean about using CUSTOM_ID in the context of
> org-collector?

:ID: is special property, which is usually set with `org-id-get-create'.
Creating it by any other mean can introduce error during export.

> Maybe I misunderstood something. Do you think the reason that a table
> can't be generated from my example code is that org-collector is
> somehow trying to expand the macros when the table is generated?

I didn't check org-collector library, so I don't know the problem and
didn't take time for serious debugging. I'm just trying to point out
what seems to be a mistake in your ECM.

Regards,

Re: org-collector unable to handle macros

[Aaron Ecay]

Hi Nicolas,

2015ko irailak 8an, Nicolas Goaziou-ek idatzi zuen:
> 
> Mark Edgington <edgimar@gmail.com> writes:
> 
>> Can you explain what you mean about using CUSTOM_ID in the context of
>> org-collector?
> 
> :ID: is special property, which is usually set with `org-id-get-create'.
> Creating it by any other mean can introduce error during export.
> 
>> Maybe I misunderstood something. Do you think the reason that a table
>> can't be generated from my example code is that org-collector is
>> somehow trying to expand the macros when the table is generated?
> 
> I didn't check org-collector library, so I don't know the problem and
> didn't take time for serious debugging. I'm just trying to point out
> what seems to be a mistake in your ECM.

This looks like the same problem I reported (and provided a patch for) here:
<http://mid.gmane.org/878uhfa397.fsf@nicolasgoaziou.fr>.  Some orgtbl-*
functions can’t cope with macro (or macro-resembling) text, because they
use the exporter, which expects all macros to have valid definitions.

Hopefully this time the bug can actually get fixed, instead of becoming
bogged down in irrelevant aspects of the context in which it is
reported.

-- 
Aaron Ecay

Re: org-collector unable to handle macros

[Mark Edgington]

Aaron Ecay <aaronecay <at> gmail.com> writes:

> 
> This looks like the same problem I reported (and provided a patch for) here:
> <http://mid.gmane.org/878uhfa397.fsf <at> nicolasgoaziou.fr>.  Some orgtbl-*
> functions can’t cope with macro (or macro-resembling) text, because they
> use the exporter, which expects all macros to have valid definitions.
> 
> Hopefully this time the bug can actually get fixed, instead of becoming
> bogged down in irrelevant aspects of the context in which it is
> reported.
> 

The link you provided doesn't seem to be a valid URL.  Can you check it, and
post a new one?

Re: org-collector unable to handle macros

[Nick Dokos]

Mark Edgington <edgimar@gmail.com> writes:

> Aaron Ecay <aaronecay <at> gmail.com> writes:
>
>> 
>> This looks like the same problem I reported (and provided a patch for) here:
>> <http://mid.gmane.org/878uhfa397.fsf <at> nicolasgoaziou.fr>.  Some orgtbl-*
>> functions can’t cope with macro (or macro-resembling) text, because they
>> use the exporter, which expects all macros to have valid definitions.
>> 
>> Hopefully this time the bug can actually get fixed, instead of becoming
>> bogged down in irrelevant aspects of the context in which it is
>> reported.
>> 
>
> The link you provided doesn't seem to be a valid URL.  Can you check it, and
> post a new one?

In a (probably vain) attempt to make life harder for spammers, gmane
mangles email addresses by changing the "@" sign (shift-2 on US
keyboards[fn:1]) to " <at> ". If you reverse that transformation on the
link above, you'll get to the article - which BTW can also be found at

http://article.gmane.org/gmane.emacs.orgmode/93840

Nick

Footnotes:

[fn:1]  Note that even though I typed it literally above, gmane
        will most probably change it to the mangled form when you
        see this.

Re: org-collector unable to handle macros

[Nicolas Goaziou]

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> This looks like the same problem I reported (and provided a patch for) here:
> <http://mid.gmane.org/878uhfa397.fsf@nicolasgoaziou.fr>.  Some orgtbl-*
> functions can’t cope with macro (or macro-resembling) text, because they
> use the exporter, which expects all macros to have valid definitions.
>
> Hopefully this time the bug can actually get fixed, instead of becoming
> bogged down in irrelevant aspects of the context in which it is
> reported.

Fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: org-collector unable to handle macros

[Achim Gratz]

Nicolas Goaziou writes:
> Fixed. Thank you.

That commit 6d2ab4071960f8a7f20138291424b468722ab522 breaks three R
tests for me on Linux (not that other R tests do run correctly):

3 unexpected results:
   FAILED  test-ob-R/colnames-nil-header-argument
   FAILED  test-ob-R/colnames-no-header-argument
   FAILED  test-ob-R/colnames-yes-header-argument

It seems that there is no table returned or the interpretation of the
returned data as a table fails.

Test test-ob-R/colnames-nil-header-argument condition:
    (user-error "Empty table - created default table")
   FAILED  130/599  test-ob-R/colnames-nil-header-argument
Test test-ob-R/colnames-no-header-argument condition:
    (ert-test-failed
     ((should
       (equal '...
        (org-babel-execute-src-block)))
      :form
      (equal
       (("col")
        ("a")
        ("b"))
       nil)
      :value nil :explanation
      (different-types
       (("col")
        ("a")
        ("b"))
       nil)))
   FAILED  131/599  test-ob-R/colnames-no-header-argument
Test test-ob-R/colnames-yes-header-argument condition:
    (user-error "Empty table - created default table")
   FAILED  132/599  test-ob-R/colnames-yes-header-argument


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: org-collector unable to handle macros

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:


> That commit 6d2ab4071960f8a7f20138291424b468722ab522 breaks three R
> tests for me on Linux (not that other R tests do run correctly):
>
> 3 unexpected results:
>    FAILED  test-ob-R/colnames-nil-header-argument
>    FAILED  test-ob-R/colnames-no-header-argument
>    FAILED  test-ob-R/colnames-yes-header-argument
>
> It seems that there is no table returned or the interpretation of the
> returned data as a table fails.

I just applied a patch that may fix these issues.


Regards,

-- 
Nicolas Goaziou

Re: org-collector unable to handle macros

[Achim Gratz]

Nicolas Goaziou writes:
>> It seems that there is no table returned or the interpretation of the
>> returned data as a table fails.
>
> I just applied a patch that may fix these issues.

This bug is fixed, thank you.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: org-collector unable to handle macros

[Aaron Ecay]

Hi Nicolas,

2015ko irailak 19an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay <aaronecay@gmail.com> writes:
> 
>> This looks like the same problem I reported (and provided a patch for) here:
>> <http://mid.gmane.org/878uhfa397.fsf@nicolasgoaziou.fr>.  Some orgtbl-*
>> functions can’t cope with macro (or macro-resembling) text, because they
>> use the exporter, which expects all macros to have valid definitions.
>> 
>> Hopefully this time the bug can actually get fixed, instead of becoming
>> bogged down in irrelevant aspects of the context in which it is
>> reported.
> 
> Fixed. Thank you.

Thanks.  I can confirm that the bug no longer manifests in the context I
reported (babel results).

-- 
Aaron Ecay