lh-cpp VS vim-projectionist

In lh-cpp, gotoimpl_with_libclang branch, I have been working on a new implementation of :GOTOIMPL (generate an empty body in a .cpp file from the signature) and :MOVEIMPL (move an inline definition from an header file to an implementation file, while leaving a declaration behind) that rely on libclang to parse C++ code. :GOTOIMPL & :MOVEIMPL have existed for ages now. The difference is that I'm now able to correctly handle template classes and functions, and more complex parameter types as C++ parsing is no longer done with regexes.

In lh-cpp, I tweak lh-brackets mapping on { to insert the semi-colon as well, but only if one of struct, class, enum... is detected on the current line when { key is hit.

On those topic I provide mu-template that is somewhat hybrid as it supports template inserted when a new file is opened-created, but also snippets. It can be completed by lh-cpp for even more advanced C++ related snippets. Note: they are definitively not trendy but I'm still using and maintaining them.

We already have a kind-of central registry, it's vim-pi. Thanks to it, and VAM, you can install my lh-cpp plugin and all its dependencies with a single :InstallAddon lh-cpp

Tim Pope's projectionist for navigating to files of a particular category or to related files from the current one: https://github.com/tpope/vim-projectionist.

> For myself, I'm fine with the typing being in a separate .rbs file

We type[0] by having one separate .rbs file per .rb file. Works really well with an editor's vertical splits: type outline on one side, code on the other. That, or use something like vim-projectionist[1].

[0]: (WIP: there's a huge codebase to type, but we're progressively getting there) https://github.com/DataDog/dd-trace-rb/tree/master/sig

[1]: https://github.com/tpope/vim-projectionist

One of the originals I guess must be tim pope's https://github.com/tpope/vim-projectionist

use https://github.com/tpope/vim-projectionist - define the relationships between files (example: app/*js are 'source' files and test/*js are 'test' files). Projectionist sets up `:A` to jump to the 'alternate' file (jump between a 'source' file and its 'test' for instance), and `:Esource` and `:Etest` commands to find/navigate by the kind of file. This is very powerful IMO - for projects with good structure I can quickly jump between related test/source/model/blah files very quickly using these commands. For projects without good structure I rethink or get the team to talk about how we might improve the project organization (ie, lack of structure is a code smell!)

I love Tpope’s https://github.com/tpope/vim-projectionist but this one seems like a great replacement 😎

Tim Pope's excellent Projectionist plug-in has an alternate file feature, which makes it very easy to switch between test and implementation files.

The plugin is inspired by vim-projectionist and https://github.com/vim-scripts/a.vim

This feels like a bug, since the plugin doesn't behave as expected when following the installation section verbatim. I filed a bug here: https://github.com/tpope/vim-projectionist/issues/168

You need https://github.com/tpope/vim-projectionist. Gotta have a file structure for unit tests though.