[FEATURE REQUEST]: `\input foo` (without curly brackets) does not work as expected

[FedericoBruzzone]

trafficstars

I'm going to make a premise, two things:

• I am aware that this is a bad practice, but LaTeX compilers do not reject this code.
• I am willing to implement this proposal if it is accepted.

---

Problem Statement

LaTeX supports this syntax :

 \input sects/introduction

(I do not know for what type of Command Name::[...]Include the omission of curly brackets is supported.)

Anyway, currently texlab parse it as

#[test]
fn test_input_without_brackets() {
    check(
        r#"\input foo"#,
        expect![[r#"
            [email protected]
              [email protected]
                [email protected]
                  [email protected] "\\input"
                  [email protected] " "
                [email protected]
                  [email protected] "foo"

        "#]],
    );
}

which causes the lack of name resolution (e.g., citations) within the file. Additionally, of course, the go-to-def and find-ref features for the specified file (e.g., sects/introduction) do not work as we expect.

---

Current AST

When the path is wrapped between curly brackets:

#[test]
fn test_input_without_brackets() {
    check(
        r#"\input{foo}"#,
        expect![[r#"
            [email protected]
              [email protected]
                [email protected]
                  [email protected] "\\input"
                  [email protected]
                    [email protected] "{"
                    [email protected]
                      [email protected] "foo"
                    [email protected] "}"

        "#]],
    );
}

---

Issue in Source Code

The problem is that https://github.com/latex-lsp/texlab/blob/c609974cfcf8acab6302589ad685069ec57244b2/crates/parser/src/latex.rs#L719-L732 takes into account only paths when the peek is a Token::LCurly.

---

A Proposed Solution

My suggestion would be to add a new formal parameter (e.g., option_curly: bool) to generic_include in order to match only the next word as a KEYWORD, by hooking it up as a subtree [email protected].

For instance, something like:

#[test]
fn test_input_without_brackets() {
    check(
        r#"\input foo"#,
        expect![[r#"
            [email protected]
              [email protected]
                [email protected]
                  [email protected] "\\input"
                  [email protected] " "
                  [email protected]
                    [email protected] "foo"

        "#]],
    );
}

[clason]

LaTex supports this syntax

Akshually, this is incorrect: This is (plain) TeX syntax, not LaTeX. As this is a parser for LaTeX and not plain TeX (which is not a subset of LaTeX!), this is expected.

[FedericoBruzzone]

LaTex supports this syntax

Akshually, this is incorrect: This is (plain) TeX syntax, not LaTeX. As this is a parser for LaTeX and not plain TeX (which is not a subset of LaTeX!), this is expected.

Thank you for your immediate reply, I was not aware that TeX was not a subset.

Anyway, since TeX syntax is supported wouldn't it be considered to support it?

[clason]

TeX syntax is supported

I am saying it is not, except where it coincides with LaTeX.

[FedericoBruzzone]

Is this a texlab's design choice?

Because \input foo is currently supported by all LaTeX parsers in action in common LaTeX compilers.

[clason]

LaTeX compilers

There are no "LaTeX compilers"; there are just TeX compilers that load the LaTeX format by default.

But this is nitpicking; it is a design choice that I'll leave to the maintainers to clarify (one way or the other).

[FedericoBruzzone]

There are no "LaTeX compilers"; there are just TeX compilers that load the LaTeX format by default.

Yes I know. By "LaTeX compiler" I was referring to the set of macros written in TeX + the TeX compiler, if you prefer.

it is a design choice that I'll leave to the maintainers to clarify (one way or the other)

I will wait for a response from @pfoerster on whether to implement this or not