Re: Help with fixing an org-mode multicolumn implementation - LaTeX special characters

[mcg <giepen.m@googlemail.com>]

Hello Aaron,
[I noticed I did not answer to the list; just writing again to add it to 
the list]

this fix works perfect!  Thank you very much.
Never mind about multirow...

Michael


On 22/02/16 16:48, Aaron Ecay wrote:
> Hi mcg,
>
> 2016ko otsailak 21an, mcg-ek idatzi zuen:
>> I found a very nice implementation of LaTeX multicolumn functionality in
>> this thread:
>> https://lists.gnu.org/archive/html/emacs-orgmode/2013-02/msg00736.html
> [...]
>
>> However, using any of the characters of the left column of my example
>> table in the merged <2colc> column, I get:
>> "setq: Invalid use of `\' in replacement text"
> I think the function should be written (untested):
>
> (defun my-latex-multicolumn-filter (row backend info)
>    (when (org-export-derived-backend-p backend 'latex)
>      (while (string-match "\\(<\\([0-9]+\\)col\\([lrc]\\)?>[[:blank:]]*\\([^&]+\\)\\)" row)
>        (let ((columns (string-to-number (match-string 2 row)))
>              (start (match-end 0))
>              (contents (replace-regexp-in-string "[[:blank:]]*$" "" (match-string 4 row)))
>              (algn (or (match-string 3 row) "l")))
>          (setq row (replace-match
>                     (format "\\multicolumn{%d}{%s}{%s}" columns algn contents)
>                     nil t row 1))
>          (while (and (> columns 1) (string-match "&" row start))
>            (setq row (replace-match "" nil nil row))
>            (decf columns))))
>      row))
>
> The change is setting the third argument (‘literal’) to ‘replace-match’
> to t, and deleting an extra backslash in the "\\multicolumn..." string.
>
>>
>> Questions:
>> - How to escape the special characters in the left column properly to be
>> able to use them? (tried everything I could think of)
>> or
>> - How to modify the code above so that it allows for such characters.
>>
>> - If anyone likes the implementation and is more capable than I am, then
>> the same for multirow would be really nice...
> Unfortunately I think that’s more complicated, since it would necessitate
> examining/modifying the whole table in one go, rather than operating one
> row at a time.
>