On Thu, Jan 10, 2019 at 10:05:49AM +0000, Daniel P. Berrangé wrote: > On Thu, Jan 10, 2019 at 10:23:07AM +0100, Erik Skultety wrote: > > On Wed, Jan 09, 2019 at 07:35:54PM +0100, Andrea Bolognani wrote: > > > Vim won't recognize them, and thus not enable niceties > > > such as syntax highlighting, otherwise. > > > > So, is there a strict reason for the *inc.am naming? Reading through [1] gave me > > the necessary background, but is there an inherent issue naming all of the > > Makefiles in subdirectories to Makefile.am, I mean, we'd still end up including > > those, or does that go against some automake rules? > > I picked Makefile.inc.am because I think it would be confusing to name > them Makefile.am when they are not self-contained automake files. They > can only ever be used when included from teh real Makefile.am. I'm not > inclined to rename them just for sake of editor mode settings. > > We previously removed editor settings from all files, in favour of > putting such configs in the root of the source tree. eg the emacs > .dir-locals.el, .ctags, .color_coded.in, etc Yeah, I didn't like the vim annotation, since we should not favour a single editor, what you suggest makes more sense if the below plugin works reliably and doesn't mess with all of your favourite .vimrc settings. > > Assuming this plugin: > > https://www.vim.org/scripts/script.php?script_id=441 > > it appears we could have a $GIT/.vimrc file for this purpose. So, I'm not sure I 100% understand what it does from the description, would it only replace ("patch") the stuff that is relevant to the project, leaving all of the other settings coming from your ~/.vimrc config in effect? Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list