emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Help with fixing an org-mode multicolumn implementation - LaTeX


From: Aaron Ecay
Subject: Re: [O] Help with fixing an org-mode multicolumn implementation - LaTeX special characters
Date: Mon, 22 Feb 2016 15:48:41 +0000
User-agent: Notmuch/0.21+33~g570c0ae (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-unknown-linux-gnu)

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.

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]