Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some Diagnostics have line number NaN #3774

Closed
4 tasks done
torik42 opened this issue Mar 14, 2023 · 0 comments · Fixed by #3778
Closed
4 tasks done

Some Diagnostics have line number NaN #3774

torik42 opened this issue Mar 14, 2023 · 0 comments · Fixed by #3778
Labels
bug Issue identified by LW maintainers as bug

Comments

@torik42
Copy link
Contributor

torik42 commented Mar 14, 2023

Pre-checks*

  • The issue has not been reported in this repository.
  • The issue remains after disabling all other extensions and restarting Visual Studio Code.
  • The FAQ cannot address the issue.
  • The issue is not related to compiling a document, or the document can be successfully compiled in the OS terminal but not in Visual Studio Code with this extension.

Environment*

  • Operating System: macOS 13.2.1
  • Visual Studio Code Version: 1.76.1 (actually VSCodium)
  • LaTeX Workshop Version: 9.7.0 (also tested with commit 911ada6)
  • TeX Distribution Version: TeX Live 2020

Please list the environment and version number if you are using VSCodium, Snap or Flatpack versions of Visual Studio Code, and/or Visual Studio Code Remote Containers/SSH/WSL.

  • I am using VSCodium whose version is 1.76.1

The Issue*

Some Warnings in the LaTeX Output don’t have a line number in the LaTeX source associated with them. LaTeX Workshop then gives them the line NaN and positions 0 and 65535 when publishing them to VSCode. This is not a problem per se, and I only encountered it, because VSCode will send Code Action Requests to LSP servers that don’t follow the Language Server Protocol. (See the related VSCode issue.)

However, I think it would be good to decide where the Problem should appear in the Editor. If there is no way to determine a better position, I think line 0 from first to last character is a good option. In my specific case (see details below), the warnings were Package Warnings starting with Package unicode-math Warning:, where it would be even nicer, if they could be moved to the \usepackage{unicode-math} statement if no specific line is provided.

Reproduction Steps

To see how I encountered the issue while writing my own LSP server, see the related VSCode issue.
To see the NaN value here, we will run the Extension in Debug Mode:

  1. Clone the LaTeX-Workshop repo, run npm ci from within the directory
  2. Set a breakpoint in …parserlib/parserutils.ts line 59.
  3. Start a debugging session
  4. Create a new LaTeX document
    \documentclass{article}
    
    \usepackage{mathtools}
    \usepackage{unicode-math}
    
    \begin{document}
        This is some text.
    \end{document}
  5. Build the document with recipe xelatex and inspect the range object in the debugger.

Expected Behaviour

I would prefer, if the LaTeX Workshop extension decides where to show the Problem. If no line number is given in the LaTeX output and the Problem is a Package-Warning, it might be nice to show them where the package was loaded. Otherwise, the first line is still a good place but might be used explicitly.

Logs

As this issue is somewhere between a feature request and a bug, I will not fill out the rest for now. If you think something else is really needed, I am happy to provide it.

@jlelong jlelong added the bug Issue identified by LW maintainers as bug label Mar 19, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by LW maintainers as bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants