✨ Feature: Latex rendering appears faulty at times

[ChrisGVE]

🔖 Feature description:

First of all, I love your plugin! (and I'm glad you like your laptop)

I have a few rendering problems in LaTeX, and I don't know if this should be a bug report or a feature request. I'm using neovim with WezTerm on macOS (non-beta)

When writing:

$C<C_{\epsilon}:T:=0$

I am getting this, which shows phi instead of epsilon:

When writing

$T=\Delta h / H_\text{max}$

I am getting this, where the text should be written as an index:

Are these bugs, or are these edge cases out of scope? And would you consider bringing them in scope?

📂 Possible solutions:

No response

🧾 Feature reference:

No response

[OXY2DEV]

The first issue is a bug in the plugin.

The second one is a bug in the LaTeX parser since it parses _\text as one thing and {max} as another thing.

[OXY2DEV]

Okay, the first issue is fixed. I unfortunately couldn't find a subscript version of \epsilon in Unicode(closest I got was ɞ). So, I had to remove it.

[OXY2DEV]

So, I have looked into the tree-sitter grammar for subscript text,

    subscript: $ =>
      seq(
        '_',
        field('subscript', choice($.curly_group, $.letter, $.command_name)),
      ),

It looks like you can only have _a, _{a} & _\command. You could open an issue in their repo to add support \text.

[ChrisGVE]

Ok, I've raised issue #208 in the tree-sitter-latex repo. We'll see what comes back.

[ChrisGVE]

I got an answer that it was not on their side. But they mentioned to try $H_{\text{max}}$, which I tried and it gives:

For the epsilon, while it is not perfect, I would have taken the small e instead of nothing; that's my personal take, it might not fit with your development philosophy.

Anyway, I'm not sure what your priorities are; it would be great to have a full-featured rendering, but it may be too much work to achieve. I leave it to you to keep this open or close it. I won't complain either ways.

[OXY2DEV]

For the epsilon, while it is not perfect, I would have taken the small e instead of nothing;

If it doesn't cause confusion, I am fine with adding it as a small e.

For now, I think it's okay to be slightly inaccurate with the symbols. So, it should be fine to add it.

it would be great to have a full-featured rendering, but it may be too much work to achieve.

I don't think it's exactly viable( with just tree-sitter at least) as the parser doesn't understand the context of the language itself and can sometimes parse invalid code.

There's also the issue of nesting commands where I have to manually check the parents of a command to figure out what style to apply to the text(and can cause slight performance issues if used too frequently).