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. 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. --
