IntelliSense triggered by a specific situation

[yarakos95]

IntelliSense triggered by a specific situation

Please forgive me that this post is not Q&A.

Premise

This discussion is a feature we hope to be implemented in LaTeX workshop.

However, since collecting IntelliSense data is expected to be very laborious and complicated to expand the functionality, so it is okay to propose an alternative extension. If presented with an alternative extension, I think I'll have to create the data myself, but that's not a problem. Also, this feature is ambitious and I don't mind if it ends up being just an idea.

But if someone can make it happen, users will have a better and more comfortable LaTeXing life.

Expected features

IntelliSense for package settings

For example, settings for the hyperref package can be specified from \hypersetup, but it is very difficult to enter the settings name correctly and it is often difficult to remember. Of course, this is especially true for beginners.

% Example
\hypersetup{
    colorlinks = false,
    citebordercolor = green,
    linkbordercolor = red,
    urlbordercolor = cyan,
}

The example of process by which IntelliSense suggestion is displayed:

1. When the cursor is in \hypersetup triggers IntelliSense data about hyperref settings.
2. Typing c suggests colorlinks and citebordercolor and more.

It would be very useful if \hypersetup could trigger the IntelliSense of these option names and avoid typography. Of course, it would be nice if this feature was also provided for other major packages.

The important thing is that this IntelliSense suggestion only display in \hypersetup.

IntelliSense for command line in TeX file

When using magic comments or llmk (toml field), you need to write the following command line in the TeX file.

% !TEX program = LuaLaTeX
% !TEX options = -synctex=1 -interaction=nonstopmode -file-line-error "%DOC%"

% +++++
% sequece = ["lualatex","bibtex","lualatex"]
% [programs.lualatex]
%   command = "lualatex"
%   opts = ["-interaction=nonstopmode", "-file-line-error",]
%   aux_file = "%B.aux"
%   aux_empty_size = 9
%   args = ["%T"]
% +++++

I don't know what to do about this, but I think it would be nice to suggest options such as -interaction=nonstopmode.

In the case of llmk, it may be sufficient to have a snippet of toml available between +++

[James-Yu]

Thanks for the long suggestion. The second point is good but may not be covered by this extension. We are in a phase to gradually rule out magic comments (vscode config is far more flexible). Therefore advanced magic comment will not be implemented.

For the first one, the workload is quite huge! I myself is happy to see it happen, but I am not sure how it can/should be implemented technically.

[yarakos95]

We are in a phase to gradually rule out magic comments (vscode config is far more flexible). Therefore advanced magic comment will not be implemented.

I didn't know that LaTeX Workshop was in the phase of excluding magic comments. If so, the feature to suggest LaTeX command options would not be necessary.

On the other hand, llmk is a build tool, a bit different from magic comments themselves, so the type may be different. I may have written a bit poorly on this part.

The purpose of llmk is explained as follows:

Light LaTeX Make (llmk) is yet another build tool specific for LaTeX documents. Its aim is to provide a simple way to specify a workflow of processing LaTeX documents and encourage people to always explicitly show the right workflow for each document.

cf. CTAN: Package Light LaTeX Make

Execution is done by only $ llmk foo.tex. The actual command executed looks the same as the magic comment, but there is no editor or other dependencies in that it is executed via a command that uses texlua. Also, as in latexmk, the specified LaTeX command will be automatically executed multiple times.

I don't know how popular it is, but I like the fact that the workflow is explicit for each document.

For the first one, the workload is quite huge! I myself is happy to see it happen, but I am not sure how it can/should be implemented technically.

I haven't done any extension development activities, but I agree that the workload will be quite huge.

However, I am sure that there are many people, including myself, who would be happy to have such a feature. If someone sees this post and is interested and in trying to develop it, I would be very happy. (I don't want to increase the burden on maintainer and contributors. So I posted it in discussion instead of issue. I'm sorry if I seem selfish.)

As I mentioned in the beginning, I don't mind if it ends up being just an idea, but I couldn't help but remark on this idea. I hope it catches the attention of ambitious people.

[James-Yu]

No you are absolutely not selfish. If I understand correctly this llmk is something like latexmk but requires additional info in tex to guide the process. This is also the objective tools and recipes of this extension want to achieve. Is that a duplication?

It seems that at the current stage the core devs indeed do not have additional effort to maintain this feature. However, we are happy to see contributions from the community (not limited to us or you) on this feature. It would be better if the feature is vividly integrated with the existing tool-recipe system, as the latter is the foundation of this extension.

[jlelong]

Looking closer at the llmk documentation, there are actually 2 ways of writing workflows

1. Either directly in the .tex file as you describe in your post
2. In a dedicated llmk.toml file, see https://github.com/wtsnjp/llmk#using-llmktoml. For more detailed explanations, you can read Section 3 of https://mirrors.chevalier.io/CTAN/support/light-latex-make/llmk.pdf, in particular have a look to 3.2

It seems that the second approach is less versatile.

[yarakos95]

@James-Yu

I'm sorry for the late reply.

If I understand correctly this llmk is something like latexmk but requires additional info in tex to guide the process. This is also the objective tools and recipes of this extension want to achieve. Is that a duplication?

I think it can be considered a duplicate because the specification of processing in LaTeX Workshop and llmk is almost the same: tools corresponds to [programs.], and recipes corresponds to [sequence].

On the contrary, the differences are as follows.

• It seems that LaTeX and other commands handle it a little differently. See https://github.com/wtsnjp/llmk#default-programs-table
• You can also specify the execution in llmk.toml file, as @jlelong also shows.

You can specify one or more files from source in the llmk.toml file. The reason why there is such a specification method is explained in the developer's article as follows.

[Translation by Google]
Instead of specifying the workflow directly in the document source in the form of a comment, you can also write the workflow in a special external file named llmk.toml. If the system or co-authors do not know which file is the document source in the first place, this method is more suitable.

llmk basics

[Original text]
文書ソースにコメントの形で直接ワークフローを指定する代わりに，llmk.toml という名前の特別な外部ファイルにワークフローを記述することもできます．そもそもどのファイルが文書ソースなのかをシステムや共著者が知り得ないような場合には，こちらの方法を用いる方が適しています．

llmk の基本 | ラング・ラグー

You can write it in a .tex file directly or in a dedicated llmk.toml file, but llmk developer seem to prefer in a .tex file directly.

I'm not using this llmk.toml method, so I'm not sure what it would be like if I specified more than one file with source. However, I feel that it is not a pattern that can be processed on editor side.

If you want to know more about llmk, you can watch the following TUG talks or read TUGboat articles:

• YouTube: https://www.youtube.com/watch?v=kzqlNHKmzBo
• PDF: https://www.tug.org/TUGboat/tb41-2/tb128asakura-llmk.pdf

---

It seems that at the current stage the core devs indeed do not have additional effort to maintain this feature. However, we are happy to see contributions from the community (not limited to us or you) on this feature. It would be better if the feature is vividly integrated with the existing tool-recipe system, as the latter is the foundation of this extension.

There is one problem with using the currently confirmed llmk. It is introduced in the following article (Japanese only).

LaTeX Workshopでllmkしてみたらアレだった件 - マクロツイーター

In summary, LaTeX Workshop picks up all the warning messages (often cross-reference warnings) that are generated by multiple runs, so you can't receive the correct message.

This issue doesn't seem to occur with latexmk, as LaTeX Workshop only picks up the warnings generated by the last run of latexmk . This process seems to be done in:

LaTeX-Workshop/src/components/parser/log.ts

Line 78 in 58e0bb9

private trimLaTeXmk(log: string): string {

According to the article, latexmk prints the following message before LaTeX runs, so it seems that you are looking for the last run with this as a landmark.

Latexmk: applying rule 'latex'

However, for llmk, there are no messages printed before such LaTeX is run. By default, messages are listed without such a break. You need to give the --verbose option to output this kind of message. If you give the --verbose option, you will see a message similar to the following before LaTeX etc. is executed.

llmk info: Running command

I personally created a batch file that was run with the --verbose option and only output the message of the last LaTeX run. (But this batch file is incomplete and doesn't work as expected at a reasonable frequency ... and also includes features other than llmk.)

https://gist.github.com/Yarakashi-Kikohshi/d83547b4e5ec1c9093cc6ad07f203da8

I use this batch file to output all the logs output to terminal to a .llmk.log file and type the last LaTeX message in terminal. (I couldn't think of a better method other than this one)

---

Another function that can use external commands is to delete auxiliary files, but llmk can also do this well.

  "latex-workshop.latex.clean.method": "cleanCommand",
  "latex-workshop.latex.clean.command": "llmk",
  "latex-workshop.latex.clean.args": [
    "-c",
    "%TEX%"
  ]

[jlelong]

The first point is related to #2098. I would love to have intellisense for package options but the implementation effort is really huge.
Besides, there is a technical difficulty/limitation: we currently limit the context used by intellisense to build the completion list to the current line. Changing this would require an enormous workload. Determining if the cursor is inside a multi-line

\somecommand{
...
}

can basically be only achieved by parsing the file from the beginning. This is not reasonable to parse the whole file every time intellisense is triggered. So, we could deal with

% Example
\hypersetup{colorlinks = false, citebordercolor = green, linkbordercolor = red, urlbordercolor = cyan}

but not

% Example
\hypersetup{
    colorlinks = false,
    citebordercolor = green,
    linkbordercolor = red,
    urlbordercolor = cyan,
}