emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export


From: Timothy
Subject: Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export
Date: Tue, 04 May 2021 02:03:00 +0800
User-agent: mu4e 1.4.15; emacs 28.0.50

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> This sounds reasonable.

I'm glad to hear that!

>> +(defun org-md-latex-environment [...]
> Nitpick: I would use `format', also the final newline character is
> useless, since it will be removed later during the export process.

Actually, since writing this patch I'm not sure that $$-surrounding
\begin{}...\end{} environments is also a good idea. I'm inclined to
leave this out of the patch.

>> +;;;; Latex Fragment
>> +
>> +(defun org-md-latex-fragment (latex-fragment contents info)
>> +  "Transcode a LATEX-FRAGMENT object from Org to Markdown.
>> +CONTENTS is nil.  INFO is a plist holding contextual information."
>> +  (when (plist-get info :with-latex)
>> +    (let ((frag (org-html-latex-fragment contents info)))
>> +      (cond
>> +       ((string-match-p "^\\\\(" frag)
>> +        (concat "$" (substring frag 2 -2) "$"))
>> +       ((string-match-p "^\\\\\\[" frag)
>> +        (concat "$$" (substring frag 2 -2) "$$"))
>> +       (t (message "unrecognised fragment: %s" frag)
>> +          frag)))))
>
> Nitpick: I suggest to use `rx' macro. It really makes the code base
> a better place.

I do rather like the `rx' macro, however I'm not sure that
(rx bol "\\(") is really an improvement over "^\\\\(" in this particular
case.

> You are missing some cases. The fragment could be $...$ or $$...$$
> already, so you can return it as-is without sending the message.

Ah yep, after getting your thoughts on this message I'll send a revised
patch with fixes this (along with any other changes).

> Otherwise, it is a macro. We can assume it lives outside math mode. So
> maybe the "Unrecognized fragment: %S" is in order in that situation. We
> could also let HTML export back-end deal with it. I don't know what is
> better.

I'm not sure what to do here either. Perhaps nothing/HTML backend?

Finally, I think if this case (lone macro) is handled, there aren't any
possible "Unrecognized fragment"s that could be passed, and so that
condition would no longer be necessary?

--
Timothy.



reply via email to

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