-
Notifications
You must be signed in to change notification settings - Fork 389
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
[Feature request] Support texlab language server #1371
Comments
I'm happy you like it! :)
I do not quite see how. That is, I agree that it may be relevant to mention TexLab and perhaps some information about how to use it with Vim in the docs. But I have not used it myself and I have quite limited time. As such, I will gladly review and accept PRs for this, but I will probably not do anything myself in any time soon. |
@lervag Okay here are my thoughts. How about vimtex provides a user option Now, this option is just a shortcut for disabling the features set by the LSP (to avoid conflict). As far as I am aware, LSPs won't ever provide 80-90% of the stuff that vimtex currently handles (correctly handling tex root file, folding, setting tex engines and options, LaTeX specific text objects etc.), so I see that using vimtex is an absolute must i.e LSP is not a replacement for vimtex. IMHO, an LSP complements vimtex's strengths with only a small overlap. My request here is to implement a design whereby vimtex acts merely like a "passthrough" to the LSP for majority of the features. Being a modular codebase, I think this isn't as difficult as it initially appears. |
You raise a fair point, and I can agree to adding such an option. But as said, I do not have the time to investigate this in detail myself. If anyone would be able/willing to provide a reproducible example of how to setup Vim with vimtex, an LSP plugin and the TexLab server, and with that a way to reproduce overlap issues, then I could implement a robust version if this option. Note that vimtex does already provide a lot of |
Looks like texlab is being rewritten in rust so let's wait and see what features get available as it's very immature. As LSP providers improve, vimtex could lose some weight (i.e, lines of code) :) |
If (and when) other plugins/providers are made available that renders some of vimtexs features deprecated, then I'm just glad. I would be happy to make vimtex work well alongside LSP plugins. In the meantime, I'm closing this as there is nothing to do right now. |
Out of curiosity, I spent some time yesterday playing around with this. TL;DR: it works, offers some neat functions that vimtex doesn't, doesn't do many things that vimtex does, and where there is overlap, vimtex does it better. If anyone else wants to play with it (or is just interested in what it does), here's more details: SetupFirst, download the binary from https://github.com/latex-lsp/texlab/releases and put it somewhere in your path. Next, install a LSP client. I used prabirshrestha/vim-lsp for this (there's also natebosch/vim-lsc, but that worked less well for me). It's a pure VimL implementation, so all you have to do is to add the following to your .vimrc: Plug 'prabirshrestha/async.vim'
Plug 'prabirshrestha/vim-lsp'
au User lsp_setup call lsp#register_server({
\ 'name': 'texlab',
\ 'cmd': {server_info->['PATH_TO_texlab']},
\ 'whitelist': ['bib','tex'],
\ })
set hidden The language server should now start automatically as soon as you open a tex or bib file. (Alternatives would be neoclide/coc.nvim and autozimu/LanguageClient, which are more full-featured but need a binary install. If anybody has tested this and gotten better results than I report below, I'd be interested to hear about it.) LSP-only featuresYou can then do the following things, which may or may not be useful:
\section{A}%
\label{sec:A} everywhere.) I should stress that none of this relies on aux files, so it works even if the project hasn't been compiled yet. LSP and vimtex featuresThe biggest overlap that I noticed was completion; you can hook the language server up to omnicomplete via So the LSP has quite some way to go to be on par with vimtex feature-wise (which is a pretty high bar, admittedly). But it's possible to hook up the language server to autocomplete (using, e.g., ncm2-vim-lsp) for speed and leave vimtex as manual omnicomplete provider for features to get the best of both worlds. The language server also can (automatically) trigger compilation via latexmk on save. It currently doesn't have any callbacks, though. |
@clason That's awesome! Have you tried to see if it plays well with coc-vimtex, which is an extension to the LSP client |
No; as I wrote, I don't want to mess with binary installs. I only tried pure VimL clients. (EDIT: I did try LanguageClient-neovim in the meantime; it works, but the experience with vim-lsp was smoother.) But if you can check coc, please report your experiences! (And some of these problems also occur with the vscode extension, so they are definitely texlab bugs. EDIT: I've opened issues about them. EDIT2: And most of them have been fixed.) |
I'm happy to see more information about this. I would be happy to document this somehow. If any of you would be willing and able to suggest something, that would be very good. I'm thinking this might earn a spot at the top of |
I was planning to offer to write up my notes properly as a section for the Wiki, once texlab has a full release (probably very soon) and I get the last kinks in the setup ironed out (TeX is not a standard language for a server, and vim is not a standard editor for a client, so there are some edge cases both ways. Also, I can't brain.) |
Great, and thanks!
I can relate to this too often these days... |
Thinking a bit more about this, LSP integration may not have to be a Clearly, that would be a massive refactor, and the reliance on an external binary for important functionality might be distasteful (it certainly goes against the vim principle of ubiquity and platform-independent scripting). So unless you need a new hobby -- "vimtex 2.0" -- it would probably need to be a fork -- "nvimtex", if it uses the new neovim hooks -- and hence "someone elses problem" :) (Regarding "nvimtex": Neovim is also working on adding multiprocessing, and the first pull request reports an impressive speedup of 20x for |
I thought this was already well provided by the language server plugins such as
Thanks, this is very interesting information! I am happy to see that there are more enhancements in the pipeline for neovim. |
Well, the point of LSP (the protocol) is that it defines standard actions that all language servers (can) provide and all clients (can) trigger -- independent of the language. There is of course some room for adaptation here -- for example, the "symbols" for python (variables, functions) are different than the ones for TeX (labels, bib keys). But the actions are fixed: rename, list, preview, etc. Many things that vimtex does do not easily fit into that mold (for example, the table of contents functionality is much more nuanced than simply "list all references"). And things like "change surrounding environment" or "toggle star" are far outside the protocol. Nevertheless, the basic infrastructure of the language server (compiled syntax-aware document parsing) might be leveraged in place of interpreted VimL regexp parsing for this if it is exposed to a higher level, which the neovim pull request seems to be allowing (if I interpret it correctly). Imagine what you could do if you had access to a list of all labels with their location in all files in the current project without having to manually parse the TeX (and aux!) files yourself. Of course, at this time, it's just pie-in-the-sky futurist hot air... (And if you think that's cool, you should look at the tree-sitter pull-requests -- direct access to the syntax tree of a document generated by a compiled parser -- in other words, super fast highlighting :)) |
Good point, that would of course be very nice! I'm also looking forward to the tree-sitter stuff, although I currently only know about it from reading on reddit. But it sounds very useful! |
Of course, the first thing I did was google "tree-sitter latex" and was happy to find https://github.com/yitzchak/tree-sitter-latex :) One thing I'm wondering is how to best pay forward the huge work that went into the vim-based features to the new kids (language servers and tree-sitter grammars)... |
Would it be a possibility to turn vimtex to a language-server? |
@astier That doesn't really make sense -- the whole point of a language server is that it's independent of the editor. Are there any specific features from texlab that you think vimtex should implement directly? (@lervag If you're using coc, there's now https://github.com/fannheyward/coc-texlab that should make it fairly easy to try out in case you're curious. Watch out for issues with non-ASCII characters -- LSP is based on UTF-16, and that trips up for example vim-lsp. If it works for you, let us know!) |
Just forget my idea. |
@astier I did not mean to be dismissive, just asking for more specific details about your idea. |
No worries. I did not perceive it as dismissive. I just had a thought but it doesn't make sense. |
@clason sorry to dig and old thread but vimtex is extraordinary as an plugin with auto-completion , previously I have used coc nvim , but have ever since moved to vim-lsc, is there any plan to support or is already supported ? |
@motorto Vimtex is not a language server (and coc is not exactly an lsp client), so you're looking for the wrong thing, I'm afraid. What you want is a general-purpose completion plugin like deoplete, ncm2, or asyncomplete. (I personally am not using autocomplete for vimtex and just trigger it manually.) |
@clason. You are right ! I am aware that coc.nvim is more than lsc client. Unfortunately texlab server is not on pair to vimtex at the moment so I am moving back to coc nvim to use coc-vimtex. |
Why can't you use both? And if you're not using a language server, why do you want to switch to vim-lsc? (But if coc works well for you, no reason to switch from it.) |
Vimtex and texlab ?
Well to be honest I am having trouble configuring the texlab, their
documentation is not great (at least from my point of view).
Texlab gives me the autocompletition that I want Packages for example (I
couldn't make texlab do that).
If its the move from vim-lsc to coc-nvim , well then coc-nvim does
everything that vim-lsc does so , it's redundant having both :)
…On 2020/09/05 01:39, Christian Clason wrote:
Why can't you use both?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1371 (comment)
|
@lervag I think now is a great time to revisit this. LSPs have become incredibly popular and are frankly quite awesome (I have started using @teto texlab has indeed been re-written in pure rust, and have been making regular releases. Indeed, the project repo is super active with frequent commits. Why is this the best time to revisit this issue?Neovim 0.5 has been just released. In my view, this is a game changer, with its built-in LSP integration, and the possibility of allowing lua plugins, tree-sitter integration etc. In fact, @clason and I were briefly discussing an issue this morning about tree-sitter diff-ing in neovim. Frankly, the availability of some high quality plugins leveraging the I think that Of course, we need to thoroughly think this through, if there is further interest in this issue. |
I have been summoned! Frankly, the arguments against are still the same -- VimTeX targets a much broader audience than just neovim 0.5+ folks, and the overlap with LSP is not that large, considering what VimTeX offers. (The argument may be different from the other side, but again, texlab is primarily -- although happily not exclusively -- aimed at VS Code users.) And as the release newsletter hopefully makes clear, tree-sitter is not ready yet for production use and cannot replace the extensive (in particular, package-specific!) syntax support of VimTeX. It's also very important to keep in mind that texlab is constrained by the LSP specification, which is not written with markup languages like LaTeX in mind (which are also quite difficult to parse for tree-sitter, I might add), while VimTeX has no such constraints. And there is nothing preventing you from using both texlab and VimTeX (and tree-sitter, if you're feeling brave) in parallel; I've been doing so for more than Is there an opportunity for an "NvimTeX" built on top of LSP, tree-sitter, and whatever other goodies Neovim's Lua API offers (Telescope? LuaSnip?) Absolutely. But It Is Not This Day. |
(And I know you don't intend it that way, but this suggestion has an aftertaste of "now that LSP is out, you can stop trying and leave this to the experts" -- you're essentially suggesting that @lervag abandon years of work and start from scratch!) |
@clason Absolutely not. Karl is one of my favourite open-source developers, and has been an absolutely awesome human being to interact with (I have talked with him once). My point was to provide a user-flag to selectively disable certain groups of configs that can be better done by an external tool. For instance, it is well-known that I advocate co-existence of vimtex and LSP. My point was to have users a bit of control through user setting flag, and if no LSP is found, then we fall back to the complete set of features that |
It's still not clear what exactly you want changed, then; there's zero conflict between VimTeX and texlab (and tree-sitter), they happily coexist already. You're 100% in control of it by setting your mappings according to taste. No options necessary. Let me be clear here: I have been doing this for two years now and never noticed a conflict. If you have, you should give a concrete example! |
This has already had many words, so I'll try to first make some general responses and comments, then I'll close with coments to the more concrete suggestions. First, I really do not mind these discussions. I don't want to end up maintaining a plugin that "lives in the stoneage", so I need to be aware of what is happening around me. But my time is quite limited, so it is very good that the community helps me get informed! Tree-sitter and LSPs are huge, and at some point in time I believe it will impact how I shape VimTeX! General
I strongly agree on the usefulness of LSPs!
I'm glad to hear it! I still don't really use texlab much.
I agree this is all good! :)
I would not really mind offloading things, but it has to be done very carefully. I personally don't see any good reason to look into this right now. As @clason writes (and I could not write it better myself):
Concrete
I don't really see a very simple way to do this. VimTeX would have to properly detect the settings of the LSP. Some people may want some parts of the LSP, others may want other parts. So, it seems to me to be much better to simply allow people to properly disable parts of VimTeX that they want and let them customize their environment manually.
My last point stands: I don't really see any clear/simple way for VimTeX to
HOWEVER: I do see how it could be beneficial to the community to have a better documentation on how to use and configure VimTeX alongside texlab. Currently, there is only a very small section that explains what texlab is. I would be both grateful and happy to get help from someone (perhaps @clason?) to write a better guide on how to make these plugins coexist; e.g. suggested configuration and describe where there is an overlap and so on. Since I still don't really use texlab, I don't know enough to write something like this myself. |
Well, my
As for overlap, my initial comment still stands. (texlab has improved a lot, and I can't recommend the project enough -- there's something about TeX that attracts great people ;) but the basic functionality is the same.) In particular, you'll see that I don't have any LSP-motivated changes to the VimTeX cconfiguration. The only thing worthy of mentioning is that I use texlab for autocompletion and reserve VimTeX for omnicompletion. |
How does the texlab completion work compared to VimTeX? |
Thanks! |
(you could also link neovim's builtin LSP client: https://github.com/neovim/nvim-lspconfig/blob/master/CONFIG.md#texlab ;) |
@clason Thank you for the useful comments. Can you please clarify what you meant by @lervag Thanks a lot for providing detailed explanatory answers. I think we can rest this case for now, bearing in mind the awareness that the neovim ecosystem is undergoing some big changes. |
@clason this is an unfair comparison: lsp clients usually provide a preview when a completion entry is selected |
Sorry, I stand by this, which was a specific and not a general point: VimTeX offers a better preview than texlab. (I use both -- and they're both great at what they do -- so I know.) |
Both Putting texlab to the side and thinking about the LSP ecosystem in general, the protocol is evolving well, and the information exchange between a client and server is a rather elegant JSON RPC dataframe. The simplicity of the protocol is encouraging more developers to contribute to various LSP servers, and generally I have seen better/faster completions, definition support etc in python/C++. The LSP protocol itself is evolving in positive directions. Why did I say all these? I have truly benefited from VimTeX, and I agree with clason that it is currently superior to texlab. It is imperative that, with the 7.5 years of hard work put into vimtex to make it so brilliant, it needs to remain relevant in the next decade. VimTeX has been tested against so many corner cases, and lervag writes up test cases with each PR to ensure that regressions are rare. I think, a visionary/prudent approach for VimTeX to thrive would be to:
The modus operandi would be to try this out in a feature branch, and announce |
I think VimTeX is thriving very well by doing what it is doing currently; I don't see any grounds on thinking that this will change in the near future. And at the risk of sounding like a broken record: VimTeX and Texlab coexist very well already; if there is an overlap of functionality, you can set up your mappings to use one over the other as you prefer. There is nothing VimTeX needs to do to support Texlab! In general: such "philosophical" comments are rarely helpful; it's much better to focus on single concrete issues and tackle them one at a time. |
I disagree that philosophical comments are rarely helpful. The Agile manifesto, which is now considered the backbone of modern software development, is entirely philosophical in nature! I think major open-source projects welcome discussions about user experiences, and have RFCs regarding its future direction. It would provide a more inclusive environment which will empower less technical people to contribute to the project.
Yes. I echoed this exact feeling in my post, with currently being a keyword. We were just considering how to keep it the best going into the future. Ignoring a new entrant to the field is not the answer, imho. Can we at least provide an objective comparison of each overlapping capability in the documentation?
Great. That sounds useful. @clason, would you be willing to provide a write-up or documentation update on how these two can co-exist? Finally, there may not be a 100% right or wrong approach to think about future directions for software. In my interaction with him, I have observed that VimTeX's main developer is flexible and adaptable to acknowledge the potential of LSP servers like texlab, and hoping that he'd use the best approaches from any competitor, or somehow provide ways to co-operate well with any such technologies in the future. |
@krishnakumarg1984 Thanks; I actually do appreciate philosophical comments and thoughts, and it is useful to get this kind of input. I agree with @clason's sentiment that concrete issues are in general much more helpful, but sometimes it is also very good to take a step back and consider things in a larger perspective. Some thoughts to your concerns:
Well, I'll try, or at least I'll accept PRs with updates to the docs and similar.
In this I agree with @clason:
However, I will admit that this is also somewhat "lucky". I currently (and still) do not use texlab myself, and as such, I do not experience problems that I thus fix for my own needs. So if there are concrete shortcomings, these should be raised by users. And in this particular case; ...
... as mentioned, I agree with @clason. The more "day to day" improvement and maintenance of VimTeX is very much dependent on users raising specific and concrete issues that I and (as I'm very glad to see!) others can address.
I do not fully understand what this integration would mean, specifically.
I am not knowingly ignoring texlab. But I am not able to spend as much time with VimTeX as I need to get on top of everything (there are still ~10 open issues and a couple of PRs, and some of these will correspond to major efforts). I don't think you mean it that way, of course.
I think this sounds like a reasonable request. However, I would not call it comparison, instead I would call it a documentation of "integration" in the sense of explaining a "best practise" manner to combine VimTeX and texlab. I would welcome a PR for this. texlab is currently described in In this sense, I think the following are things that would be useful for me to know in order to understand "the future of VimTeX":
|
@lervag Thanks for your receptive and detailed response. I agree to everything you have said here. Just one minor point
The non-features wording might be perceived as sending out a stronger negative signal. I know its pure semantics, but it appears as saying "No. This particular aspect is not vimtex's job. If you want feature X, read this section and DIY". Instead, I think the section could be titled "Integration with other relevant technologies" or "Interoperation with other plugins" or something which conveys a more inclusive/welcoming tone (reflecting the openness of your response here). In such a documentation section, providing an initial example set of keymaps and configs explaining how to co-operate with texlab shall enrich the user experience, imo. I have been reassured (even by large-scale projects) that open source is as much about the community as it is about the code. In my experience, fixing a simple sentence typo or providing an entire language translation for the documentation of a software has been welcomed as much as implementing a new technical feature. I believe that some initial config/documentation section for LSP shall encourage others who have experimented here shall submit their own configs as PRs. @lervag For visibility/discoverability reasons, would you be okay to indicate that you are willing to accept example LSP configs as documentation PRs. It would be good to indicate this inline in the documentation, but I suspect that might be too deeply embedded in the text to make an impact. The PS: Treesitter for LaTeX is currently nascent, but I suspect texlab development may accelerate treesitter as one feeds on the other. |
I didn't want to comment anymore but feel like I must correct you here: the |
Thanks for pointing that out, didn't know. |
Good point; I agree.
Good suggestion. I think you have good points here. I've pushed an update that I hope you find agreeable; and please, if you have further ideas for improving this, don't hesitate to open a PR!
Agreed, at least in part. I believe the keymaps for texlab are not specific. Instead, you define keymaps for the LSP in general, and these should be valid across languages and LSP servers. But I agree it could be expanded upon. Again, feel free to suggest improvements!
I want to keep the docs as concise as possible. But I don't mind PRs that improve and expand upon topics in way that make sense (e.g. for visibility and discoverability). I would be OK to indicate this type of willingness - feel free to suggest how in a PR.
This issue is both old and closed, so I don't think it will help to tag it. Perhaps better to open a new issue with a "feature" request to improve docs with a suggestion on how to integrate VimTeX with texlab. If you both refer to the current text, this particular issue, and add the tag "help-wanted", then it may attract a contribution. I don't think the README.md is a good place to indicate this, but you could open a PR to show me what you mean. If I agree, I would merge the PR. :) |
(By the way - this thread is now so long that I'll lock it when we've settled these final points.) |
Just wanted to let you know that the links to the gists for configuring for the co-existence of texlab and vimtex are now invalid, and give 404 errors. @clason Would you mind pointing us to updated links for your texlab and vimtex configuration? These could be a good starting point for users who arrive in this issue thread by following vimtex's documentation. |
Those links were never meant to be public; just some snippets I shared privately. At the risk of sounding like a broken record: there's nothing special about using VimTeX and Texlab in parallel; you just set each of them up as you like it. |
Are you referring to something in the docs; i.e., should I update the docs? |
No. Just clason's links in this thread. VimTeX's doc mentions this thread, and when I tried to follow the gists linked here, they are gone. This could be frustrating for others who similarly come to this thread by following the documentation. |
I had lots of fun using
vimtex
for writing a paper and my PhD thesis :). Thank you for developing and maintaining this modern plugin.It is 2019 and Language servers are here! VSCode seems to be having a runaway success due to sharing common origins at the same company that formulated the nicely documented, open & editor-agnostic language server protocol (LSP).
Servers
The idea is that all aspects that are specific to a particular programming language are left to a dedicated language server. A compatible client (i.e. a text editor) can simply ask questions to the server and populate its UI with the response received. Various common tasks such as
completions
,hover-text
, andgo-to-definitions
are thus offloaded to the server. Though not all language servers are mature yet, the well-documented, open specification means that these get continuous refinements from the community. The official set of language servers for various programming languages is available here.Clients (for vim)
For
vim
, the language server capability (i.e. the client functionality that understands LSP lingo) is provided by a couple of plugins, notablylanguageclient-neovim
(python) andvim-lsp
(vimscript). A pull-request to bring in native LSP functionality toneovim
is fairly mature & scheduled to land for v0.5.LaTeX-specific information
The officially supported language server for LaTeX is TexLab which also handles BibTeX. I have had a positive experience using it in VSCode for which there exists a client plugin bearing the same name (TexLab).
Question
Can
vimtex
provide support for (i.e. play nicely with) TexLab? Already the modular codebase & design goals of vimtex instruct to use dedicated plugins for tasks such as completion, folding and reference doc. Instead of using a variety of plugins, using a language server might be a really good idea.I am not sure what
vimtex
needs to do to support LSP. At the least, this possibility should be mentioned in the documentation (but only after testing).The text was updated successfully, but these errors were encountered: