Open AssertionBit opened 1 year ago
Note that with CMake support, CMake presets usually offers the best integration with editors. If the CMake plugin support for generating a base config or adds a UI to configure CMake, it should be done through CMakePreset.json
/CMakeUserPresets.json
Dropping these here as well since this issue seems to also be tagged for cmake language support and a good experience editing the CMake project files themselves is the more important part of this for me personally. LSP: https://github.com/Decodetalkers/neocmakelsp tree-sitter: https://github.com/uyha/tree-sitter-cmake
zed editor called suitable for c++ development without even supporting syntax coloring for .cmake files?
when is it going to have cmake support zed editor wtf????
As soon as someone implements it. Wanna volunteer?
I actually had a rough plugin wired up to provide syntax highlighting + neocmakelsp but it broke when the plugin interface was refactored last week. I might find time to fix that plugin and push it to the extension repo eventually but I have no interest in developing a configuration GUI as that does not really have any value to me. There is currently also no way for extensions to define their own GUI so that is going to have to wait a while longer anyway.
That said the syntax highlighting + LSP plugin is very straightforward to replicate based on e.g. the uiua language plugin, in case someone else wants to take a stab before I get to it.
Im not even joking this is how cmakelists.txt looks like.
there is no need for complex features like LSP.
just syntax coloring could be a great addition, I already had the same issue with xcode, but in there I just enabled c++ coloring and it "did the trick", they also offer no cmake LSP but just syntax coloring. . .
(what I meant https://stackoverflow.com/questions/63455480/xcode-11-and-cmake-syntax-highlighting)
You can do the same trick in Zed
how
when is it going to have cmake support zed editor wtf????
As soon as someone implements it. Wanna volunteer?
I actually had a rough plugin wired up to provide syntax highlighting + neocmakelsp but it broke when the plugin interface was refactored last week. I might find time to fix that plugin and push it to the extension repo eventually but I have no interest in developing a configuration GUI as that does not really have any value to me. There is currently also no way for extensions to define their own GUI so that is going to have to wait a while longer anyway.
That said the syntax highlighting + LSP plugin is very straightforward to replicate based on e.g. the uiua language plugin, in case someone else wants to take a stab before I get to it.
please let me know if you manage to complete your task
how
language selector: toggle
and then chosing c++
.
how do I get to the language selector thingy
cmd-shift-p
or click on the file type down here:
how
language selector: toggle
and then chosingc++
.
I this this is not a solution. It is a trick. Maybe I will start working on plugin for CMake and general C/C++ support.
and general C/C++ support
There already is syntax highlighting and LSP (clangd) support for C and C++. If you mean build/debug support then I hope you aren't in a hurry because you'll find that Zed is still lacking integration APIs for implementing those.
I think a first step could be to add CMakeLists.txt
to these two lists:
https://github.com/zed-industries/zed/blob/c0d117182fc4c20f750c28345967e64855265227/crates/languages/src/c/config.toml#L3 https://github.com/zed-industries/zed/blob/c0d117182fc4c20f750c28345967e64855265227/crates/languages/src/cpp/config.toml#L3
That's also how we handle highlighting Gemfile
s as Ruby files, for example:
But obviously the downside of that is that it treats CMakeLists.txt
as C/CPP files, even though they are not.
The better solution would be to use https://github.com/uyha/tree-sitter-cmake and add a language extension to that.
is someone fixing this shit or not
Redirecting caches to cmake-build-debug folder, like CLion does (with cmake -B . -S cmake-build-debug).
I wanted to add you probably meant
cmake -B cmake-build-debug -S .
-B flag is for build, -S flag is for source
but the point got across please let me know if someone is fixing this shit or not
and general C/C++ support
There already is syntax highlighting and LSP (clangd) support for C and C++. If you mean build/debug support then I hope you aren't in a hurry because you'll find that Zed is still lacking integration APIs for implementing those.
I read through all API and will be working on providing general support. I know that there is only syntax highlighting and LSP, but (I hope) that in future this issue will be fixed ASAP
I think a first step could be to add
CMakeLists.txt
to these two lists:That's also how we handle highlighting
Gemfile
s as Ruby files, for example:But obviously the downside of that is that it treats
CMakeLists.txt
as C/CPP files, even though they are not.The better solution would be to use https://github.com/uyha/tree-sitter-cmake and add a language extension to that.
I don't think so. Tree-Sitter is just general parser and doesn't provides required cabilities (like other C/C++ tools) does. So there is a lot of work to be done
Hi, I maintain zed cmake extension, which has tree sitter and LSP (https://github.com/k0tran/zed_neocmake). It also has README with short instructions on integrating clangd (C++ LSP) and creating cmake task (shortcut for building your project). It has enough features at least for me. I would like a way to add template of CMake C++ task into the extension/editor interface so you don't need to open github page every time.
On the first iterations of the extension I put path_suffixes = ["CMakeLists.txt"]
and it worked then. But recently it broke and now Zed considers CMakeLists.txt a Plain Text file. I siffed through Zed source code and found this line (https://github.com/zed-industries/zed/blob/17b9d1976fd443f8ed3689b2e00a0840d6c9c313/assets/settings/default.json#L838). I propose (if it is possible) to somehow exclude CMakeLists.txt from Plain Text mask. Or add new line for CMake. Maybe there other parts of source code that can be tweaked to make this work again.
I also would like an addition here https://github.com/zed-industries/zed/blob/17b9d1976fd443f8ed3689b2e00a0840d6c9c313/crates/extensions_ui/src/extension_suggest.rs#L16
If it's required I can make two separate issues for those problems
@k0tran yeah, I think specific issues such as "CMakeLists.txt
is considered a text file" would be good to have.
@k0tran yeah, I think specific issues such as "
CMakeLists.txt
is considered a text file" would be good to have.
Opened one issue https://github.com/zed-industries/zed/issues/20291 And one pull request https://github.com/zed-industries/zed/pull/20292
Check for existing issues
Is your feature request related to a problem?
I think, that CMake language and as the build tool is not related to language requests. CMake language is separate thing, but the build system is other.
Previous mention of this topic: zed-industries/zed#5269. Also related: zed-industries/zed#5437, zed-industries/extensions#135
Related issue just got mention of CMake support, but primary just asks for plugins support. For now Zed is not parsing make file, not loading caches provided by make and so on. For now C/C++/ObjC/... projects are working on file based project structure.
All build tools for C languages (cmake, ninja, mason) are not working for now.
Describe the solution you'd like
I would like to see project loading, like CLion have. JetBrains added support for it in their primary IntelliJ IDEA and in CLion. VSCode also has that feature with CMake plugin. Both of them could be good references for quite good project indexing.
For the UI, I think, that we need in commands in command pallet like building target, reloading project and so on. They could appear in case of CMake project detected and loaded successfully. For developing support, there is one helpful option: cmake caches. In them cmake contains tons of useful information about structure, loading and so on.
I see two ways of solution.
Native support of CMake
This way requires more time and code for achieving result, but it will provide cross-platform support for C/C++ projects (CMake is only one native way of building projects on windows, according to official documentation of Microsoft).
So this way probably will cause the two steps to do:
cmake-build-debug
folder, like CLion does (withcmake -B . -S cmake-build-debug
).After that, You will have folder, that contains structured information about all targets, languages, errors and so on. I look through cargo's and there is no of them, doing this job.
Shadow calling of CMake
Cmake is just preprocessor to other things (ninja, make, mason, xcode). Probably, You may add support for Make projects and then just invoke cmake with generating Makefile (that appears on top of cache folder). This way maybe more useful, because make projects are more widely used and automatically adding support to tons of other languages.
For developers
I am working on monorepo tool that must support CMake build system tool. Because of that, I was need in some sort of parser for it too. I tried to find some sort of solution to these problem for half a year, but there is no tool for getting information from CMake projects.
Just making this note is not useful. For developers I may provide some sort of beta-parser of cmake projects in rust, c or cpp, which may help during Your work in development. Or more detailed documentation about cache folder structure. Like I mentioned in zed-industries/zed#5104 issue, the way that You propably may use is single interface for build tools.
If applicable, add mockups / screenshots to help present your vision of the feature
Example UI of working with CMake from command pallet