Jambunathan K <kjambunat...@gmail.com> writes:
> Nicolas Goaziou <n.goaz...@gmail.com> writes:
>
>> Hello,
>>
>> Achim Gratz <strom...@nexgo.de> writes:
>>
>>> Yes, that has been my impression as well. Again, I can make them go
>>> away by removing one of the byte-compiled files, so I rather suspect
>>> another case of a macro expansion that's not quite what was intented.
>>> Only this time I really don't see from the backtrace what that would
>>> be.
>>
>> It looks like table-cells have a wrong `:parent' property when
>> org-element.el is byte-compiled. In `org-element-table-cell-parser',
>> replacing backquote with `list' solves the problem.
>
>
>> This is related to modifications by side-effect of list elements, but
>> I don't know why it only happens when the file is byte-compiled and why
>> it only focus table cells.
>
> There is an interesting "pitfall" mentioned wrt `nconc' under:
> (info "(elisp) Rearrangement").
>
> I try to make sense of the pitfall by conjuring up this argument. This
> seems right to me.
> - `list' will dynamically allocate the list at runtime. It comes from
> C's heap.
>
> - A quote list is allocated at compile time (atleast the constant
> bits). It comes from memory that is allocated for global variables -
> externs or static externs. Think value of list is the pointer to an
> extern C variable.
>
> I am not sure what backquote does.
>
> Wrt above problem, you may want to verify the following:
> 1. It works right the first time. But subsequent invocations create
> side-effect.
> 2. Focus on what happens to the `head' of the list.
Do table-cell gets "composed" in a special way wrt other elements.
> I am more or less facing similar problems wrt element translation. I am
> holding off any checkin mainly because I see some undesirable
> side-effects.
I dont't have handle on it yet. May be it is just a coincidence that
the translation involves lists and tables.
ps: If only there way to see the C pointers underlying the objects one
could actually sensibly see what is happening underneath.
The closest I have come to doing so is to use a combination of
`pp-display-expression' with (setq print-circle t). This latter part
was added to my .emacs only in the last 2 days in an effort to bring out
the differnce between `eq' and `equal'.
For example a table like this
| 1 | 2 |
| a | b |
gets rendered as below. Track the :parent properties, the Ns and #es
and you have no ambiguity on what objects they point to.
#1=(org-data nil #2=(section
(:begin 2 :end 22 :contents-begin 2 :contents-end 22
:post-blank 0 :parent #1#)
#3=(table
(:begin 2 :end 22 :type org :tblfm nil :contents-begin
2 :contents-end 22 :value nil :post-blank 0 :parent #2#)
#4=(table-row
(:type standard :begin 2 :end 12 :contents-begin 3
:contents-end 11 :post-blank 0 :parent #3#)
(table-cell
(:begin 3 :end 7 :contents-begin 4 :contents-end
5 :post-blank 0 :parent #4#)
"1")
(table-cell
(:begin 7 :end 11 :contents-begin 8 :contents-end
9 :post-blank 0 :parent #4#)
"2"))
#5=(table-row
(:type standard :begin 12 :end 22 :contents-begin
13 :contents-end 21 :post-blank 0 :parent #3#)
(table-cell
(:begin 13 :end 17 :contents-begin 14
:contents-end 15 :post-blank 0 :parent #5#)
"a")
(table-cell
(:begin 17 :end 21 :contents-begin 18
:contents-end 19 :post-blank 0 :parent #5#)
"b")))))
