Visuwesh <[email protected]> writes:
>>> Invalid language parameter; accepted values are c, pascal, ...
>> Yes, it would make sense.
>> I am not sure what would be breaking about this.
>
> Forcing the input language to normal would be a breaking change because
> currently, one could have calc's language set to Mathematica and have
> the source block be in Mathematica.
> However, if we are going to error out, I don't think we need to worry
> too much.
If there is explicit language specific in the src block, it is
deliberate choice that could not exist before your patch. Nothing will
break.
If there is no language specified in src block, it would make sense to
inherit it from current calc setup.
>>> +(defun org-babel-calc--format-lang (result params old-lang old-lang-opt)
>>> + "Return RESULT as per the Calc language given in PARAMS.
>>> +This resets the Calc language back to OLD-LANG, and the options to
>>> +OLD-LANG-OPT."
>>> + (calc-set-language (org-babel-calc--valid-lang-p params))
>>> + (prog1
>>> + (if (eq calc-language 'latex)
>>> + (concat "\\begin{equation*}\n"
>>> + (calc-eval result)
>>> + "\n\\end{equation*}")
>>> + (calc-eval result))
>>
>> What about inline src blocks?
>
> I don't use inline source blocks so I don't know how to handle them. We
> could go with \( \) or \[ \]. The former would be appropriate AFAICT.
I think we should simply use the machinery from org-babel-insert-result,
modifying it as needed. It already knows how to handle inline vs. normal
src blocks.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
