mellery451

6 months agodiscuss

one topic not mentioned is creating refactoring tools. My sense is that LSPs generally have the advantage here because they have the full parsed tree, but I suspect it would be possible to build simple syntactic refactorings in TS with the potential to be both faster and less sensitive to broken syntax.

mellery451

2 years agodiscuss

agree - what's more, the author is really talking about blaze, where everything "just works" because there are massive dedicated resources maintaining it. He literally admits that he likes the copy-pasta-no-think-about-it:

> Surprisingly, I didn’t need to fiddle with blaze, nor did I have to understand how it worked. I could copy some build targets and edit the dependency list, and the build worked as expected.

Sure, systems that just work are great, until they break.

bazel on the other hand, not so much. Heaven help you if it doesn't support your use-cases - you will wish you had Google to maintain your build.

mellery451

5 years agodiscuss

yes - I use coc + clangd and there is no comparison with cscope. The level of accuracy you get with clangd is significantly better than tags/cscope. The main thing you need to make clangd work properly is an accurate compile DB. Yes, you can general/coarse compile settings, but the accuracy drops off for a project of any size. I also suggesting staying reasonably up-to date with clangd releases since they are adding important features/fixes with each release.

mellery451

5 years agodiscuss

it's also generally preferred because it can avoid certain narrowing conversions in construction: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

mellery451

6 years agodiscuss

as to how clangd sees your current translation unit, it comes down to the compile_commands.json (which is per-TU settings) or the more general compile settings in the config file(s) (https://clangd.llvm.org/config.html). If you need to change your TU settings, you could have a simple scheme that symlinks compile_commands to different files depending on build type and then restart the server. I've not typically needed to do this (I tend to just stick with a debug build compile DB...), but it's something you could do pretty easily.

There is one clangd process per editor process. If you have multiple projects with distinct compile_commands you might be able to come-up with a scheme to switch between DBs and relaunch clangd. Alternatively, you could try merge all compile_commands together, but I'm not sure the effort would be worth it -- just running separate vims seems like it makes the most sense to me.

For switching between branches, you can typically regenerate the compile commands DB pretty easily (if you use cmake...), but it's really only necessary if there are big differences in files and/or compile settings between branches.

mellery451

10 years agodiscuss

looks interesting, but I'd rather have a tool that exposes a data API so that it can be plugged into vim/emacs

comments