Nicolas Goaziou <m...@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.