Auto close { before $ (math)

[AstrickHarren]

Proposal

referring to #421

It seems the markdown language somehow disables auto closing for { when the cursor is placed before any text (expect whitespace). The most prominent case is before a $. As an example, if I try to type { in the cursor positions below (denoted by |),

$here the auto closing works well \mathbf| $, $but not here \mathbf|$ 

this is what happens

$here the auto closing works well \mathbf{} $, $but not here \mathbf{$

However, if I change the setting editor: auto closing bracket from language defined to always, both of the above cases work well. That's why I'm suggesting the language extension should improve it.

One may argue to keep a white space before the closing $, as in the first case of the example above, but this disables the syntax highlighting for text.katex as it is not matched by the grammar.

[Lemmingh]

Currently, this extension does NOT provide language configuration, including autoclosing. It is contributed by VS Code itself:
https://github.com/microsoft/vscode/blob/700ee37a240d3789dbc093f9e32758f2295ea694/extensions/markdown-basics/language-configuration.json

Although, we can also define a language configuration to overwrite the built-it one to meet this request, I am not sure whether we should do it.

@yzhang-gh Your opinion? Seems you were interested in it, but VS Code does not.

---

the markdown language somehow disables auto closing for ...

Yes, it is the default behavior:

By default, VS Code only autocloses pairs if there is whitespace right after the cursor.

[Lemmingh]

Wait, let's clarify.

This request is to:

Enable autoclosing for { in more scenarios in

• Markdown.
• math area only.

@AstrickHarren
which do you mean? Thank you.

[yzhang-gh]

this is what happens

$here the auto closing works well \mathbf{} $, $but not here \mathbf{$

As @Lemmingh said, these auto-closing pairs are defined by VS Code itself (including {} already).

The problem you described is VS Code doesn't automatically close a pair if it is right before a $. You can try ([< etc.
You can also see this behavior elsewhere, e.g., foo|() in python.

I don't know when the VS Code will close the pair (or not). But what is for sure is it is out of our (the extension's) control...

@yzhang-gh Your opinion? Seems you were interested in it, but VS Code does not.

{} is already in the "auto-closing pairs" (although not in "surrounding pairs"). For me, It is good enough.

[AstrickHarren]

So I mentioned that I actually kind of fixed the problem by setting the editor: auto closing bracket from language defined to always. This is curious though, if VS Code defines two sets of auto closing, one for markdown, and one for always.

[yzhang-gh]

the markdown language somehow disables auto closing for ...

Yes, it is the default behavior:

By default, VS Code only autocloses pairs if there is whitespace right after the cursor.

Just found this (autoCloseBefore) 😮, which means we can help with this scenario (I mean right before $). But I'm hesitant whether we should override the default language configuration.

[Lemmingh]

Good. You eventually noticed it. 😄

If only for math areas, it can be quite easy: We can take advantage of other extensions.

---

when the VS Code will close the pair

1. By default, only if before whitespace.
2. Then, extensions can contribute language configurations to overwrite it.
3. Finally, users can change editor.autoClosing* settings to overwrite it again.

[yzhang-gh]

If only for math areas, it can be quite easy: We can take advantage of other extensions.

I like this way. But (if my memory serves me right) it requires a kind of language client?

[Lemmingh]

it requires a kind of language client?

No, embeddedLanguages is just a very basic scope mapping, and enables limited declarative language features. It's still fully handled by VS Code, and behaves a bit mysteriously sometimes.

We only need to add about two lines in package.json to adopt it. But I have to admit that this approach cannot solve the problem reliably.

---

If we're going to make things robust and rich, a language service for LaTeX, a proper server, and a corresponding client are indeed required. VS Code's HTML Language Features gives a good example of auto closing.

[yzhang-gh]

Then I think it doesn't add much values to adopt the embedded-language solution. Our current syntax highlight and math function completions work reasonably well (especially as KaTeX is different from LaTeX).

[Lemmingh]

it doesn't add much values to adopt the embedded-language solution

I agree.

To clarify, although the embeddedLanguages contribution point is introduced in "Syntax Highlight Guide", it's actually to ask VS Code to load language configuration and snippets. And from my experience, only comment toggling and snippets are always properly loaded. 😂

---

KaTeX is different from LaTeX

Right. You remind me. KaTeX is a subset of LaTeX. Users would be confused, if snippets for LaTeX appeared in our math areas. This a critical reason that we should not mark them as LaTeX.

[shreyasminocha]

Related: not auto-closing < and recognizing {} as surrounding pairs in math contexts.

[yfzhao20]

这里似乎可以更改这个文件：

安装目录\resources\app\extensions\markdown-basics\language-configuration.json

的自动闭合括号来达到目的：

找个位置插入”$“，如上图那样。

[yzhang-gh]

Thanks for the information. But why can't I find this line there? It doesn't seem to exist in the VS Code source code 🤔

https://github.com/microsoft/vscode/blob/main/extensions/markdown-basics/language-configuration.json

[yfzhao20]

哦，当然没有😂因为这一段是我从latex workshop抄过来的，为的就是让括号能够自动闭合。

直接把这一句代码加上就行，目前还没发现什么bug

[Lemmingh]

Found something interesting:
microsoft/vscode#133397

I guess my observation was correct.

[Lemmingh]

not auto-closing <

Let's see if VS Code can come up with a solution:
microsoft/vscode#131331

---

I don't think the problems can be correctly solved until VS Code tells us how to programmatically (dynamically) define embedded language scope.

Although, the Semantic Highlighting Guide says:

Optionally, the classification can also name a language, if the token is part of an embedded language.

no further explanation exists.

There are also a bunch of confusing discussions:

• Expanding semantic theming to support semantically embedded languages for colorization microsoft/vscode#81558

• Semantic Tokens: Embedded languages microsoft/vscode#86329

• Semantic Highlighting vs Injected Grammars microsoft/vscode#113640 (comment)