LSP does have facilities for helping editors out with syntax highlighting. Skimming the spec, I found:
https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#textDocument_semanticTokens “The request is sent from the client to the server to resolve semantic tokens for a given file. Semantic tokens are used to add additional color information to a file that depends on language specific symbol information. A semantic token request usually produces a large result. The protocol therefore supports encoding tokens with numbers. In addition optional support for deltas is available.” This looks painful to implement, but I’m guessing it could be “smarter” than a CLM when dealing with languages with weird grammars. It’s also brand new in the current version of the LSP spec, so I can’t imagine that it’s widely supported by servers yet. Cheers, -sam On 17 Aug 2021, at 1:12, Darren Duncan wrote: > Unless I'm confused, I had thought Language Server Protocol was the new big > standard created recently and used by Visual Studio Code and other popular > editors or IDEs and that it was intended to support all the usual features of > a language that an editor would care about, including all the syntax coloring > and function scanning and delimiter pair folding and so on. -- Darren Duncan > > On 2021-08-16 9:28 p.m., Christopher Waterman wrote: >> Darren, >> >> I bumped up against the limitation of the CLM’s as well. Language Server >> Protocol support is really a big deal. >> >> But I think built in support for languages will continue for a very long >> time. Outside the pedantic notion that you have to have some language >> support in order to connect to the servers. Editor makers will want to do >> things not provided by LSP. I suspect that if they add more features to LSP >> different editors will support different sets and choose to roll their own >> feature in other cases. Its a competitive market with free options, there is >> a lot of pressure to stand out. >> >> BBEdit doesn’t use it for syntax coloring now, and I wouldn’t be surprised >> if they have no plans too. I’m speculating but I think the situation with >> the coded vs codeless modules is a product of Bare Bones protecting BBEdits >> performance (I think syntax coloring like HTML rendering is surprisingly >> processor intensive). One is very limited but trivial to write, the other is >> difficult but extremely flexible. Both are fast. If Rich sees that speed as >> key to his customers no way he hands that over to a gallery of third parties. >> >> Also what if no one writes a LS for say Fish (there might be one, I don’t >> know). I banged that CLM out in an hour, it was my first one, and I am not a >> good programmer. >> >> I hadn’t really thought about the future of this. So thanks, now I’m kind of >> excited to see how this plays out. >> >> —Chris >> >>> On Aug 14, 2021, at 11:07 PM, Darren Duncan <[email protected]> wrote: >>> >>> Something I will say is that while I've found the codeless language module >>> functionality very helpful, and I have written and maintain a few of my >>> own, I have also, perhaps partly due to ignorance, ran into their >>> limitations quite a bit. >>> >>> I really appreciate BBEdit's new support for language servers, and when I'm >>> able to, intend to re-implement some codeless language modules as servers >>> for that protocol, helping them be much more capable in the process. >>> >>> I could be wrong but I get the impression that older methods of language >>> support are now deprecated in favor of the new language protocol, as it can >>> benefit from economies of scale to get maintained support for a lot more >>> languages. >>> >>> -- Darren Duncan >>> >> > > -- > This is the BBEdit Talk public discussion group. If you have a feature > request or need technical support, please email "[email protected]" > rather than posting here. Follow @bbedit on Twitter: > <https://twitter.com/bbedit> > --- You received this message because you are subscribed to the Google Groups > "BBEdit Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/bbedit/e6d9da6e-6f59-85b8-c6d5-1ba33c13abd2%40darrenduncan.net. -- This is the BBEdit Talk public discussion group. If you have a feature request or need technical support, please email "[email protected]" rather than posting here. Follow @bbedit on Twitter: <https://twitter.com/bbedit> --- You received this message because you are subscribed to the Google Groups "BBEdit Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/bbedit/33F7A68A-0A56-4D45-811B-F252F88A82BA%40munkynet.org.
