vim-projectionist VS vim-localvimrc

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.

A big part of 'project awareness' implies (to me at least!) that a project is organized in some meaningful way: test/view/model/service/domain files all relate to one another by their naming conventions and location in the project tree.When I start/join a project I look for documentation of the project's structure (or document it myself!). Then for vim:- use https://github.com/embear/vim-localvimrc - drop a .vimrc in the project so I can tweak vim to suit the project.

Something like Localvimrc?

Project-specific editor config: vim-localvimrc, vim-addon-local-vimrc

Is vim modeline a good way to do it? What do you think about that solution: https://github.com/embear/vim-localvimrc?

This is pretty much the last one, but with available commands. One I find particularly useful is LocalVimRCCleanup. I'm not sure how common of a use-case this is, but AutoSource stores the hashes of each file you approved, and a common command I run while testing is rm ~/.autosource_hashdir/* :p

Nice video. I have a similar approach for isolating project specific commands and configurations. I may borrow your idea for a project specific menu to run tasks. For a project dedicated vimrc I use embear/vim-localvimrc for a few years because it has auto discovery and auto change directory for a project, and require confirmation for loading the vimrc file.