Enhance build for rnw files

[jlelong]

Related to #2005

This PR implements

• alt+ctrl+v to view the pdf file
• Accept projects with several .rnw files
• alt+ctrl+b to trigger the build
• Choose an appropriate default recipe for .rnw files.
• The following extensions are associated to the Rsweave language Id : .[rRsS]nw, .[sR]tex
• Report LaTeX errors/warnings in the Problems pane

[jlelong]

This PR provides a quite satisfying support for .rnw files. Yet, there are two difficulties related to the same technical problem

• The logs showed in the Problems pane refer to the .tex file not the .rnw one
• Synctex links the .tex and .pdf files. We would rather use the .rnw file instead of the .tex one.

Fixing these points requires an important effort because we have to introduce the mapping between the .tex and .rnw files defined by the generated -concordance.tex file generated by knit when setting knitr::opts_knit$set(concordance = TRUE);. Once the mapping is available, it must be introduced both in the synctex and log parsing mechanisms. This will undoubtedly introduce a lot of code change. Is it worth it?

@RaghuNaik @maikol-solis @ChristopheRoyer21 @armarti You all showed some interest in editing .rnw using LaTeX-Workshop. How useful would the concordance mechanism be?

[jlelong]

This PR fiddles with the placeholders and the build mechanism. It requires some heavy testing before merging.

@tamuratak Could you have a look at it when you have time? Sometimes I am wondering if we (I ?) do not go too far beyond the scope of the extension to offer full .rnw support.

[tamuratak]

VS Code is supporting Jupyter Notebook. See microsoft/vscode#93265. I guess that users who want to embed R code and graphics to their documents will start using that directly. I am not sure supporting rnw is promising.

I never use R. So this is just a guess.

I have a question. I am not sure why we cannot detect languageId from the suffix of rootFile.

LaTeX-Workshop/src/components/manager.ts

Lines 178 to 194 in d454bcf

	const findMethods = [
	() => this.findRootFromMagic(),
	() => this.findRootFromActive(),
	() => this.findRootFromCurrentRoot(),
	() => this.findRootInWorkspace()
	]
	for (const method of findMethods) {
	const res = await method()
	const rootFile = res[0]
	const languageId = res[1]
	if (rootFile === undefined) {
	continue
	}
	if (this.rootFile !== rootFile) {
	this.extension.logger.addLogMessage(`Root file changed from: ${this.rootFile} to ${rootFile}. Find all dependencies.`)
	this.rootFile = rootFile
	this.rootFileLanguageId = languageId

[jlelong]

I do not use R that much myself but a lot of colleagues of mine do and they .rnw quite a lot to generate several PDF from a single .tex file with different data sets for instance. It seems to be quite popular. I think it is a good point for the extension to support .rnw file. The real question is how elaborate the support should be (concordance stuff). For the moment, I do not plan to go beyond this PR.

I am not sure why we cannot detect languageId from the suffix of rootFile.

This is a really good question and that was actually my first thought. Then, I thought that it would be more robust to read the document.languageId property when available. Looking back on this, I think you are right as the document.languageId property is only available in findRootFromActive. I will change this.

[tamuratak]

I have no reason to be against this PR if you can see real use cases.

[ChristopheRoyer21]

Same here, it looks fine to me.