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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to