Closed lnay closed 3 weeks ago
qpdfview
is not on path so the user needs a custom script on PATH to launch it. When doing so, forward search works, but not inverse search (presumably to do with sandbox)Works fine with inverse-search working out of the box
Not implemented, Zed is not released for windows anyway.
Tested on intel mac, forward-search works correctly, and inverse-search requires adjusting skim settings.
Park this for now, Zed currently does not send textDocument/didSave
RPC requests to texlab
anymore for some reason, making this PR useless. Coming back to this after Zed is fixed.
@lnay, what other setting adjustments did you need to do to make inverse search with Skim work? Perhaps Issue #30 is helpful.
Also for my understanding, would zed <file>:<line number>
in the Skim > Settings > Sync Command section work instead of zed
and '%file':'%line'
in the Command and Arguments section (respectively)?
I'm new to publicly maintained repos, so please let me know if this is not an appropriate comment!
The setting I used was almost the same as that issue 30
I do not know if putting the arguments in the command also works, that will depend on how skim was written.
The quotes are so that any spaces in the file name do not split it into separate arguments (that's why %line does not need it). Single quotes have a similar but slightly stronger effect, I expect either will work.
I see where the question comes from, in the wiki it says what it says as generic advice. In the skim settings, it says somewhere that %file and %line in the inverse search command will be substituted appropriately. And different PDF viewers may use slightly different markers to substitute the file name and number. Note that the inverse-search command is executed by the PDF viewer, not Zed itself.
Park this for now, Zed currently does not send
textDocument/didSave
RPC requests totexlab
anymore for some reason, making this PR useless. Coming back to this after Zed is fixed.
It's all fixed now
New issue: zed_extensin_api::Worktree::which
is no longer finding executables in /usr/bin/
(which should be in path for any environment Zed should reasonably set up).
Possibly related issue: https://github.com/zed-industries/zed/issues/19779
All seems fine now
Listening to feedback from friends (and others), people do not want to set up a bespoke configuration for PDF preview and forwards/inverse search when starting out using this extension. The out-of-the-box experience should aim to be comparable to popular solutions such as Overleaf because that is the expectation these days. Then if the user requires something more bespoke, they can visit the wiki and create a custom configuration which should not be overriden by this extension.
This PR checks if any of the PDF viewers documented here are on PATH, or are in the standard location. If one is found, this fact is recorded. Then when workspace configurations are requested by
texlab
, if none of the user configurations definetexlab.forwardSearch
then this is automatically set with values corresponding to the detected PDF viewer to enable forwards/inverse search as much as possible.If
texlab.forwardSearch
is automatically configured, then the extension will also enable the optionstexlab.build.afterSave
andtexlab.build.forwardSearchAfter
unless they are explicitly turned off by user settings. This is to match the default experience in other LaTeX IDEs. However these two settings (texlab.build.afterSave
andtexlab.build.forwardSearchAfter
) are not automatically enabled iftexlab.forwardSearch
is not auto-configured, notably when none of the PDF viewers are detected. This is because builds would be triggered without visual feedback (pdf preview), potentially leading to confusion and issues with stuff happening in the background that the user is not aware of.This isn't fully tested but still opening this PR now for any opinions or feedback on the topic as this change is opinionated.