typst: Rendering of R source code block

Very disappointing. on your statement, “I do not want to add support for Markdown image syntax”. You have taken Markdown syntax for your source code block. But, you will not support its image referencing.

You have taken Asciidoc syntax for heading and have put behind it your heading function. There are so many instances.

Since you don’t want, it can’t be done at all. If somebody doesn’t want, it can’t be forced upon. It seems that you are the final decision maker, and not the team.

Your one of the developers wanted to see the workflow. I took twice the pains to create the workflow. But, when I did that, you have taken a stand that you don’t want.

It means that everything in typst is not on the merits of the feature request, but on your wishes.

I can’t do anything but to leave typst. But, I am one of those R users who at least tried typst. Not many users experiment so much,

You are not rejecting my request, but rejecting a whole lot of R users, who are quite a lot too many. You are are rejecting them at the initial stage of typst.

If such wishes are dominant on this forum, it is destined to die it’s own death. There are so many other markup languages who died in their scope, because they don’t have users.

And you are rejecting users of such a popular language as R having a very large user base.

Good luck. Quitting typst.

Thanks and regards,

Dr. A. K. Singh

Thanks for your kind words, @frozolotl. Frankly speaking, I was hurt by the declaration of @laurmaedje, that he does not “want”. I got disappointed that if a large chunk of users cannot be given importance for such a small feature that I requested on behalf of R users, what is the use of being here.

Still you have spoken very kind words. I am thankful for that, and feel sorry for whatever followed. and express the same to you, to @laurmaedje and to anybody else on Typst who didn’t feel good for all this.

Now, back on the topic. You have suggested various workaround solutions. But, none of them works for me, because it is beyond my capacity to create a WASM plugin of R to be used in Typst. And if it is already present, I could not find it on net, nor do I know how to use it, if it is available somewhere. Moreover, you have yourself expressed its limitations that it sandboxes the codes. Moreover, it is not possible to ask knitr developer to include Typst type of image referencing. I had tried that in case of Asciidoctor type of source code block support. They said if R users would largely ask for that they would that. But, then Asciidoctor obliged.

I am a simple Professor of Statistics, and teach my students the same using R codes. I have written 2 books on Statistical aspects using R. One in Rmarkdown, which ultimately I disliked because of the difficulties I faced in formatting the book.

The second I wrote in Asciidoctor. There also I found a similar problem as in Typst. Then I had raised that issue there. And they had very kindly created a separate kind of R code blocks in Asciidoc and they were already supporting Markdown type of image referencing behind the curtain, although they had their different image referencing syntax. I rendered my book in HTML and Docbook but could not do the same in pdf, because they have some serious drawback issues with pdf rendering, especially with respect to math codes. It was Docbook because of which my book could be published, with some difficulty.

The third book I have started with Lyx. By this time I came to know about Typst. I tried to write an article in Typst. I liked its pdf rendering, and also that it already had Markdown type of source code block type. So I wrote some of my R codes into it and rendered the same with the workflow I have described above. Everything worked well, except its image rendering. Then I was disappointed with Typst, and kept away from it for a few months.

Then, suddenly one day, an idea dawned on me that the help pages of Typst say that they have some of their markup syntax, which are very familiar, but have kept the respective Typst functions behind such markups. So, I thought that if that is so, a small feature of supporting from behind, not popularizing, the markdown type of image referencing would not be a big deal for Typst, although they may keep their image referencing function behind that, as it already supports the markdown type of source code blocks, may that be by chance.

Thinking these, I raised my feature request. At present it is my request. But, in future, it would ultimately affect a large R user group as and when they start coming to know about it. They generally follow two workflows. One is Rmarkdown, which I think is the worst in most of its advanced syntax. So, it is not good for books and large articles. The other is LATEX one, which is very good but difficult.

Thus, not to repeat what followed so far. I again express my “sorry” to anybody who did not feel good about everything.

And if Typst could fulfill the feature request raised on behalf of R users, I would come back to Typst, and tell about it to my students too. Otherwise with no other option for R users on Typst, I would have to fallback on Lyx.

Thanks and regards,

Dr. A.K. Singh

As I understand it, you, @aksigkvgithub, want to use knitr to run R code embedded in typst source files and then generate a document with the results. Your workflow appears to rely on the fact that code blocks especially have similar syntax to RMarkdown. As such, knitr reads a file, thinking it is a Markdown file, and then generates Markdown code. Some aspects of that only work out of mere chance.

Typst does not try to replicate the syntax from any other markup or programming language. It is its own thing. The fact that raw blocks in typst use a similar (but not the same!) syntax as in Markdown is not a decision driven by increasing compatibility between tools. The decision was taken because that syntax is familiar, and most importantly, good syntax.

In my opinion, Markdown’s syntax for including links and embed images is hard to remember and not that readable. I have forgotten the order of brackets and parentheses in the past, multiple times. The syntax does not easily integrate itself into typst’s way of creating figures.

The decision to not support Markdown’s image inclusion syntax was not taken in a whim. Neither was it taken to annoy current R users. It is simply not a good fit for typst itself.

There could be alternative solutions that fit better into the typst ecosystem, however:

• Knitr supports typst input and output. This should work decently enough for simple documents. Your workflow would stay largely the same. A problem with that approach might be that typst’s scripting support would not be compatible with that.

• Using the recently added WASM plugin support, someone develops a plugin that looks for R expressions, runs them and returns the results. This would have two major benefits:

  • Typst’s scripting language would be well-integrated. This could have some major benefits for layouting the evaluation results.
  • The workflow would be your typical typst workflow as it is right now. The document could be compiled simply by running typst compile. And you could also write the document and evaluate the R results in the web application. Sadly, it does have its drawbacks:
  • R code would be sandboxed, as typst code is right now.
  • For typst watch and typst’s live preview, long-term (meaning, between runs) caching might be required. Otherwise, long-running R programs might decrease the editing experience a lot.
  • It is probably quite a bit of work to write a WASM plugin that integrates knitr and R.

• The last solution I have would be to not use R within typst. Ideally, typst’s scripting language should support the things you would embed R code for. This solution would require people to rebuild R packages in typst, and it would require you to change your workflow in some ways.

I have described some problems with the approach you have suggested so far and proposed alternative ways of solving the issue.

I don’t like to end this comment this way, but I think it has to be said. In my opinion, your comment was harsher than it deserved to be. @laurmaedje stated some of his reasoning behind closing the issue in a comment. I believe he was respectful in his writing. He also suggested an alternative solution. If you disagree with that decision, constructively write why you do so. Do not make the comment personal and do not invoke inflammatory language. Only that will incite support for the feature change.