Previewer opens often in the wrong position

[mocenigo]

[removed]

[lnay]

Is this with the zathura config in the wiki or another config/PDF viewer?

[lnay]

Links with details for my own reference:
zed-industries/zed#18456
latex-lsp/texlab#1227
zed-industries/zed#18061

If you worked out a configuration which works well for you please share here. I'm looking at introducing "auto configurations" for some PDF viewers (experimenting on this branch https://github.com/lnay/zed-latex/tree/auto-preview). I also hadn't come across these "tasks" in Zed up until now; I will try them as I'm curious to see if there is a convenient use case with this extension.
In any case, I will eventually experiment with using this extension with skim as part of the "auto configurations" plan mentioned above.

[lnay]

Another issue it seems you came across is executing arbitrary language server requests (notably textDocument/build to texlab). I'm not aware of a way to do this. The Zed extension API does not appear to have anything relating to it. And even if it did, that API does not have anything about tasks that the user can run with keyboard shortcuts. This is why I'm hoping that these Zed "tasks" might provide some kind of solution, but I have not looked into them yet.

[mocenigo]

Links with details for my own reference: zed-industries/zed#18456 latex-lsp/texlab#1227 zed-industries/zed#18061

If you worked out a configuration which works well for you please share here. I'm looking at introducing "auto configurations" for some PDF viewers (experimenting on this branch https://github.com/lnay/zed-latex/tree/auto-preview). I also hadn't come across these "tasks" in Zed up until now; I will try them as I'm curious to see if there is a convenient use case with this extension. In any case, I will eventually experiment with using this extension with skim as part of the "auto configurations" plan mentioned above.

If you read the responses in texlab you will see that there is no current configuration that would work.
I am using skim not zathura, but that would not change anything.

[lnay]

Here's a suggestion, it does not fix the issue of building on command that you brought up elsewhere, but gives a decent result for forward-backwards search circumventing texlab, which you could adjust for skim:

Create a forward search task, for me with zathura it looks like this:

// .zed/tasks.json
[
  {
    "label": "Forward Search",
    "command": "zathura --synctex-forward \"$ZED_ROW:$ZED_COLUMN:$ZED_FILE\" -x 'zed %{input}:%{line}' main.pdf",
    "allow_concurrent_runs": true,
    "reveal": "never"
  }
]

Note that this involves hard-coding the pdf file, instead of letting texlab work out where it should be; so it would still be good to eventually have a solution via texlab.

And then you can add a keymap for this:

// ~/.config/zed/keymap.json
// ...
  {
    "context": "Workspace",
    "bindings": {
      "shift shift": ["task::Spawn", { "task_name": "Forward Search" }]
    }
  }
]

For zathura, opening the PDF beforehand stops the window from closing and reopening every time.

[mocenigo]

This works for Skim:

  {
    "label": "Forward Search",
    "command": "/Applications/Skim.app/Contents/SharedSupport/displayline -r -z -b $ZED_ROW $ZED_DIRNAME/$ZED_STEM.pdf",
    "allow_concurrent_runs": false,
    "reveal": "no",
  },

But the pdf would have the same stem as the source hardwired.
What is needed is a little script that finds a

% !TEX root = file

in the current file, removes "tex" at the end of file and appends pdf, and if not it uses the current file name.

Roberto

[mocenigo]

Solved for Skim

[
  {
    "label": "Forward Search",
    "command": "str=$(grep -e \"%.*TEX root = \" -m 1 -n $ZED_FILE); if [ \"$str\" = \"\" ]; then str=$ZED_STEM; else str=$(echo $str | sed \"s/[0-9]*:%.*TEX root = \\(.*\\).tex/\\1/\"); fi; echo $str; /Applications/Skim.app/Contents/SharedSupport/displayline -r -b $ZED_ROW $ZED_DIRNAME/$str.pdf $ZED_FILE",
    "allow_concurrent_runs": false,
    "reveal": "never ",
    "hide": "always",
  },
]

It sucks that JSON does not allow line split literals.

Note that this allows a file to be opened and previewed from an included one if the included file contains a line like
% TeX root = main-file-name.tex
or
% !TeX root = main-file-name.tex
(with or without a space after the %).

The Skim displaylike allows to give also a tex file name as the parameter AFTER the pdf file and this version allows to jump also to the right place FROM an included file, as long as there is a commented line containint
"TEX root = " followed by the file name (also, respect the spaces between these words and after the "=", as in TeXshop and similar programs.

I guess this should be included in the latex-lsp extension with an option to install the Skim.app command.

Roberto

[lnay]

Finding the location of the PDF file is difficult in general (for example, it can be affected values set in latexmk config files). This is a problem that is tackled by texlab.

Here is a recap of the situation that this extension finds itself in:

• build on save
• forward search after save (approximate)
• manual build
• manual forward search (accurate)

This is not far off the default experience in Overleaf so is not too bad (albeit requires extra user config atm).

Those last two features are held back by this Zed issue.
Zed tasks can be created to trigger a build but there are two drawbacks:

• texlab does not recommend this as it needs to have knowledge about when a build takes place
• the build command that texlab would use cannot feasibly be determined in general from a shell command since it does not have access to the zed api that is available for the wasm extensions to access workspace settings.

As for forward-search Zed tasks:

• the location of the PDF is difficult to determine in general, and another tool does that already (texlab)
• creating a shell command for such a task cannot rely on tools such as grep if it is to be shipped in this extension since there is no guarantee it is available for the user

However the wiki could include examples for tasks such as the ones in this discussion, that users may inevitably need to adjust. And then when the above Zed issue is addressed, all of these problems disappear anyway. My main point is that any task.json allowing manual build and forward-search will inevitably need to be tailored to individual users.

I guess this should be included in the latex-lsp extension with an option to install the Skim.app command.

I don't think any of the relevant projects that would install Skim themselves. Overreaching aside, if a tool commits to installing a PDF viewer, it would have to be an opiniated choice. Something I do see this extension doing, is testing if it can find a supported PDF viewer, setting up a config if so, otherwise notifying the user (not currently possible I believe) with a link to a wiki page suggesting various PDF viewers to install.

[mocenigo]

Finding the location of the PDF file is difficult in general (for example, it can be affected values set in latexmk config files). This is a problem that is tackled by texlab.

Does it? Because apparently there are issues with the included files and there are bugs there. Sometimes a workaround is necessary. Many LaTeX programs have a command like
% TEX root = main_file.tex
and they are not standard. No program can be expected to support all variants, and neither does texlab, since apparently one has to tell it precisely which is the main file, and if this is available through yet another syntax, this reminds me of the following xkcd comic
Standards

Here is a recap of the situation that this extension finds itself in:

• build on save
• forward search after save (approximate)
• manual build
• manual forward search (accurate)

This is not far off the default experience in Overleaf so is not too bad (albeit requires extra user config atm).

Nope, it is bad since the experience in Overleaf is bad. Even simple programs like TeXShop get precisely these features just right and TeXShop even compiles a yet-unsaved file. But I do not need the last thing. I want a file to be saved before compiling it, so build on save is fine (since it re-builds also when no save is necessary).

Those last two features are held back by this Zed issue. Zed tasks can be created to trigger a build but there are two drawbacks:

• texlab does not recommend this as it needs to have knowledge about when a build takes place

Too bad. Either they support what it necessary or people will have to use workarounds.

• the build command that texlab would use cannot feasibly be determined in general from a shell command since it does not have access to the zed api that is available for the wasm extensions to access workspace settings.

This is a zed problem. However $ZED_STEM, $ZED_ROW $ZED_DIRNAME $ZED_FILE exists for shell commands. I wonder whether they are also available for the executables passed to texlab in the setting.json file.

As for forward-search Zed tasks:

• the location of the PDF is difficult to determine in general, and another tool does that already (texlab)

So i can pass a tex file and texlab finds the right pdf from it, even if the synctex has a different name? Or I need yet another configuration file? If this is possible with a "project" file, fine, but my first cursory look did not achieve this. Also, there may be more than one compilable tex file in the same directory.

• creating a shell command for such a task cannot rely on tools such as grep if it is to be shipped in this extension since there is no guarantee it is available for the user

This is serious, but you can remove this and assume a 1-1 mapping of tex to pdf files, without inclusions, and without parsing for the % TEX root = main_file.tex string. Then the command reduced to
"command": "/Applications/Skim.app/Contents/SharedSupport/displayline -r -b $ZED_ROW $ZED_DIRNAME/$STR_STEM.pdf $ZED_FILE",
and it works well in this case. I was just parsing for a string like the above since it is common.

However the wiki could include examples for tasks such as the ones in this discussion, that users may inevitably need to adjust.

My examples were not really more than that.

And then when the above Zed issue is addressed, all of these problems disappear anyway. My main point is that any task.json allowing manual build and forward-search will inevitably need to be tailored to individual users.

Of course! I just wanted to show that this was still possible using the current state of texlab (incomplete) and zed (incomplete).

I guess this should be included in the latex-lsp extension with an option to install the Skim.app command.

I don't think any of the relevant projects that would install Skim themselves.

Any LaTeX user on macOS would use Skim since it is the only previewer that supports synctex, unless they are using TeXShop or some other environment that has a builtin previewer, or zathura, which looks anbd behaves like an extraneous body under macOS. So offering to install Skim, or telling where it is, is definitely a must-be-offered option under macOS.

Overreaching aside, if a tool commits to installing a PDF viewer, it would have to be an opiniated choice. Something I do see this extension doing, is testing if it can find a supported PDF viewer, setting up a config if so, otherwise notifying the user (not currently possible I believe) with a link to a wiki page suggesting various PDF viewers to install.

This would definitely be the right way. However, under macOS, AFAIK the choices are limited.

[lnay]

personal notes relating to this

• texlab does not recommend this as it needs to have knowledge about when a build takes place

That comment was made from the memory of reading this page however it turns out it was only referring to keeping the PDF view in sync. Maybe this extension could enable users to build and preview using Zed tasks completely outside of texlab, not needing access to Zed user settings instead relying on config files for other build scripts instead (i.e. latexmk, arara). This way keymaps could be set with the current state of Zed. Considerations for this:

• One can recover the location of the extension (even if dev-extension) from ${XDG_DATA_HOME:-~/.local/share}/zed/extensions/installed/latex so shell scripts for tasks could be stored there
• The pdf output can be recovered reliably from the build output by scanning for Output written on x.pdf (y pages, z bytes). Could tee off build output and grep/sed? The task could prompt the user to install those (unreasonable?) or maybe rely only on perl which should be present in any latex distribution.