Return to Answer

There are several ways to do this.

As you specified directory tree, it excludes the .exrc approach (as it only works for one directory), and the modelines as well.

Remains the hand-rolled way: you put an autocommand in your .vimrc for pattern or specific directories. It's not my preferred approach as it clutters the .vimrc with yet another thing -- and also because my mind have been compromised with the Single Responsibility Principle.

For reference, there is also the plugin Project -- one of the oldest on vim.org. As I'm not using it, I won't detail how it works.

Then, there are many, and many, plugins with a name that looks like local vimrc. I've even been maintaining one for years: https://github.com/LucHermitte/local_vimrc

Regarding its features,

• It answers your question: being sourced for each file in a hierarchy -- actually each time we enter a related vim window, the matching _vimrc_local files are sourced.
• The plugin will look for files named _vimrc_local.vim, though the pattern used to search for files can be configured (as a string or a list of patterns)
• It permit plugins that uses per project settings to force loading the _vimrc_local file before anything else. For instance, when I run gvim foobar.cpp from the shell my template expander plugin (TEP) (mu-template) automatically fills in the project name, the project style (copyright headers, namespaces, naming conventions, ...). As TEP and vimrc_local plugins usually use the same vim event, there is a race on the event, and there is no guaranty project settings can be loaded before expanding any template. So, there is a way with my plugin to fix this kind of races.
• On the official site, you'll found some explanations on how to write the _vimrc_local.vim project files.
• It's being regularly tested and used on Windows (with/without cygwin), *nixes.
• It stops searching for project configuration at $HOME, or the root directory (/, //ip/), or don't even try to on remote files (http, ftp, ...).
• It support black and white lists, and also ask-to-the-user and sandbox lists which will work in the same way: what is done of the project-file will depend on the kind the list the project-file belongs to.
• Someday, I'll eventually have templates to generate project configurations for C & C++ project managed with/without CMake, generating (or not) Doxygen documentation, ...

There are several ways to do this.

As you specified directory tree, it excludes the .exrc approach (as it only works for one directory), and the modelines as well.

Remains the hand-rolled way: you put an autocommand in your .vimrc for pattern or specific directories. It's not my preferred approach as it clutters the .vimrc with yet another thing -- and also because my mind have been compromised with the Single Responsibility Principle.

For reference, there is also the plugin Project -- one of the oldest on vim.org. As I'm not using it, I won't detail how it works.

Then, there are many, and many, plugins with a name that looks like local vimrc. I've even been maintaining one for years: https://github.com/LucHermitte/local_vimrc

Regarding its features,

• It answers your question: being sourced for each file in a hierarchy -- actually each time we enter a related vim window, the matching _vimrc_local files are sourced.
• The plugin will look for files named _vimrc_local.vim, though the pattern used to search for files can be configured (as a string or a list of patterns)
• It permit plugins that uses per project settings to force loading the _vimrc_local file before anything else. For instance, when I run gvim foobar.cpp from the shell my template expander plugin (TEP) (mu-template) automatically fills in the project name, the project style (copyright headers, namespaces, naming conventions, ...). As TEP and vimrc_local plugins usually use the same vim event, there is a race on the event, and there is no guaranty project settings can be loaded before expanding any template. So, there is a way with my plugin to fix this kind of races.
• On the official site, you'll found some explanations on how to write the _vimrc_local.vim project files.
• It's being regularly tested and used on Windows (with/without cygwin), *nixes.
• It stops searching for project configuration at $HOME, or the root directory (/, //ip/), or don't even try to on remote files (http, ftp, ...).
• It supports black and white lists, and also ask-to-the-user and sandbox lists which will work in the same way: what is done of the project-file will depend on the kind the list the project-file belongs to.
• Someday, I'll eventually have templates to generate project configurations for C & C++ project managed with/without CMake, generating (or not) Doxygen documentation, ...

There are several ways to do this.

As you specified directory tree, it excludes the .exrc approach (as it only works for one directory), and the modelines as well.

Remains the hand-rolled way: you put an autocommand in your .vimrc for pattern or specific directories. It's not my preferred approach as it clutters the .vimrc with yet another thing -- and also because my mind have been compromised with the Single Responsibility Principle.

For reference, there is also the plugin Project -- one of the oldest on vim.org. As I'm not using it, I won't detail how it works.

Then, there are many, and many, plugins with a name that looks like local vimrc. I've even been maintaining one for years: https://github.com/LucHermitte/local_vimrc

Regarding its features,

• It answers your question: being sourced for each file in a hierarchy -- actually each time we enter a related vim window, the matching _vimrc_local files are sourced.
• The plugin will look for files named _vimrc_local.vim, though the pattern used to search for files can be configured (as a string or a list of patterns)
• It permit plugins that uses per project settings to force loading the _vimrc_local file before anything else. For instance, when I run gvim foobar.cpp from the shell my template expander plugin (TEP) (mu-template) automatically fills in the project name, the project style (copyright headers, namespaces, naming conventions, ...). As TEP and vimrc_local plugins usually use the same vim event, there is a race on the event, and there is no guaranty project settings can be loaded before expanding any template. So, there is a way with my plugin to fix this kind of races.
• On the official site, you'll found some explanations on how to write the _vimrc_local.vim project files.
• It's being regularly tested and used on Windows (with/without cygwin), *nixes.
• It stops searching for project configuration at $HOME, or the root directory (/, //ip/), or don't even try to on remote files (http, ftp, ...).
• Someday, I'll eventually have templates to generate project configurations for C & C++ project managed with/without CMake, generating (or not) Doxygen documentation, ...

There are several ways to do this.

As you specified directory tree, it excludes the .exrc approach (as it only works for one directory), and the modelines as well.

Remains the hand-rolled way: you put an autocommand in your .vimrc for pattern or specific directories. It's not my preferred approach as it clutters the .vimrc with yet another thing -- and also because my mind have been compromised with the Single Responsibility Principle.

For reference, there is also the plugin Project -- one of the oldest on vim.org. As I'm not using it, I won't detail how it works.

Then, there are many, and many, plugins with a name that looks like local vimrc. I've even been maintaining one for years: https://github.com/LucHermitte/local_vimrc

Regarding its features,

• It answers your question: being sourced for each file in a hierarchy -- actually each time we enter a related vim window, the matching _vimrc_local files are sourced.
• The plugin will look for files named _vimrc_local.vim, though the pattern used to search for files can be configured (as a string or a list of patterns)
• It permit plugins that uses per project settings to force loading the _vimrc_local file before anything else. For instance, when I run gvim foobar.cpp from the shell my template expander plugin (TEP) (mu-template) automatically fills in the project name, the project style (copyright headers, namespaces, naming conventions, ...). As TEP and vimrc_local plugins usually use the same vim event, there is a race on the event, and there is no guaranty project settings can be loaded before expanding any template. So, there is a way with my plugin to fix this kind of races.
• On the official site, you'll found some explanations on how to write the _vimrc_local.vim project files.
• It's being regularly tested and used on Windows (with/without cygwin), *nixes.
• It stops searching for project configuration at $HOME, or the root directory (/, //ip/), or don't even try to on remote files (http, ftp, ...).
• It support black and white lists, and also ask-to-the-user and sandbox lists which will work in the same way: what is done of the project-file will depend on the kind the list the project-file belongs to.
• Someday, I'll eventually have templates to generate project configurations for C & C++ project managed with/without CMake, generating (or not) Doxygen documentation, ...

There are several ways to do this.

As you specified directory tree, it excludes the .exrc approach (as it only works for one directory), and the modelines as well.

Remains the hand-rolled way: you put an autocommand in your .vimrc for pattern or specific directories. It's not my preferred approach as it clutteres the .vimrc with yet another thing -- and also because my mind have been compromised with the Single Responsibility Principle.

For reference, there is also the plugin Project -- one of the oldest on vim.org. As I'm not using it, I won't detail how it works.

Then, there are many, and many, plugins with a name that looks like local vimrc. I've even been maintaining one for years: https://github.com/LucHermitte/local_vimrc

Regarding its features,

• It answers your question: being sourced for each file in a hierarchy -- actually each time we enter a related vim window, the matching _vimrc_local files are sourced.
• The plugin will look for files named _vimrc_local.vim, though the pattern used to search for files can be configured (as a string or a list of patterns)
• It permit plugins that uses per project settings to force loading the _vimrc_local file before anything else. For instance, when I run gvim foobar.cpp from the shell my template expander plugin (TEP) (mu-template) automatically fills in the project name, the project style (copyright headers, namespaces, naming conventions, ...). As TEP and vimrc_local plugins usually use the same vim event, there is a race on the event, and there is no guaranty project settings can be loaded before expanding any template. So, there is a way with my plugin to fix this kind of races.
• On the official site, you'll found some explanations on how to write the _vimrc_local.vim project files.
• It's being regularly tested and used on Windows (with/without cygwin), *nixes.
• It stops searching for project configuration at $HOME, or the root directory (/, //ip/), or don't even try to on remote files (http, ftp, ...).
• Someday, I'll eventually have templates to generate project configurations for C & C++ project managed with/without CMake, generating (or not) Doxygen documentation, ...

There are several ways to do this.

As you specified directory tree, it excludes the .exrc approach (as it only works for one directory), and the modelines as well.

Remains the hand-rolled way: you put an autocommand in your .vimrc for pattern or specific directories. It's not my preferred approach as it clutters the .vimrc with yet another thing -- and also because my mind have been compromised with the Single Responsibility Principle.

For reference, there is also the plugin Project -- one of the oldest on vim.org. As I'm not using it, I won't detail how it works.

Then, there are many, and many, plugins with a name that looks like local vimrc. I've even been maintaining one for years: https://github.com/LucHermitte/local_vimrc

Regarding its features,

• It answers your question: being sourced for each file in a hierarchy -- actually each time we enter a related vim window, the matching _vimrc_local files are sourced.
• The plugin will look for files named _vimrc_local.vim, though the pattern used to search for files can be configured (as a string or a list of patterns)
• It permit plugins that uses per project settings to force loading the _vimrc_local file before anything else. For instance, when I run gvim foobar.cpp from the shell my template expander plugin (TEP) (mu-template) automatically fills in the project name, the project style (copyright headers, namespaces, naming conventions, ...). As TEP and vimrc_local plugins usually use the same vim event, there is a race on the event, and there is no guaranty project settings can be loaded before expanding any template. So, there is a way with my plugin to fix this kind of races.
• On the official site, you'll found some explanations on how to write the _vimrc_local.vim project files.
• It's being regularly tested and used on Windows (with/without cygwin), *nixes.
• It stops searching for project configuration at $HOME, or the root directory (/, //ip/), or don't even try to on remote files (http, ftp, ...).
• Someday, I'll eventually have templates to generate project configurations for C & C++ project managed with/without CMake, generating (or not) Doxygen documentation, ...