[bitbake-devel] bitbake.vim: detect *.bbappend files in ftdetect automatically

Submitted by Eren Türkay on Dec. 12, 2012, 6:42 p.m.

Details

Message ID 20121212184156.GA743@gmail.com
State New
Headers show

Commit Message

Eren Türkay Dec. 12, 2012, 6:42 p.m.
Currently, *.bb and *.bbclass files are automatically highlighted and
detected as a bitbake file. Since *.bbappend files are also bitbake
files, vim plugin should automatically detect and highlight it as well.
---
 contrib/vim/ftdetect/bitbake.vim |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Patch hide | download patch | download mbox

diff --git a/contrib/vim/ftdetect/bitbake.vim b/contrib/vim/ftdetect/bitbake.vim
index 179e4d9..6822e24 100644
--- a/contrib/vim/ftdetect/bitbake.vim
+++ b/contrib/vim/ftdetect/bitbake.vim
@@ -11,7 +11,7 @@  if &compatible || version < 600
 endif
 
 " .bb and .bbclass
-au BufNewFile,BufRead *.b{b,bclass}	set filetype=bitbake
+au BufNewFile,BufRead *.b{b,bappend,bclass}	set filetype=bitbake
 
 " .inc
 au BufNewFile,BufRead *.inc 		set filetype=bitbake

Comments

Robert P. J. Day Dec. 12, 2012, 6:57 p.m.
On Wed, 12 Dec 2012, Eren Türkay wrote:

> Currently, *.bb and *.bbclass files are automatically highlighted and
> detected as a bitbake file. Since *.bbappend files are also bitbake
> files, vim plugin should automatically detect and highlight it as well.
> ---
>  contrib/vim/ftdetect/bitbake.vim |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/vim/ftdetect/bitbake.vim b/contrib/vim/ftdetect/bitbake.vim
> index 179e4d9..6822e24 100644
> --- a/contrib/vim/ftdetect/bitbake.vim
> +++ b/contrib/vim/ftdetect/bitbake.vim
> @@ -11,7 +11,7 @@ if &compatible || version < 600
>  endif
>
>  " .bb and .bbclass
> -au BufNewFile,BufRead *.b{b,bclass}	set filetype=bitbake
> +au BufNewFile,BufRead *.b{b,bappend,bclass}	set filetype=bitbake

  gack.  there's no compelling reason to be that, um, pedantic with
the wildcard pattern.  just use

  *.{bb,bbappend,bbclass}

trying to save a couple characters while introducing that kind of
visual ugliness just isn't worth it.


rday
Eren Türkay Dec. 12, 2012, 7:53 p.m.
On Wed, Dec 12, 2012 at 01:57:53PM -0500, Robert P. J. Day wrote:
>   gack.  there's no compelling reason to be that, um, pedantic with
> the wildcard pattern.  just use
> 
>   *.{bb,bbappend,bbclass}
> 
> trying to save a couple characters while introducing that kind of
> visual ugliness just isn't worth it.

It can be used but I was not the one who introduced "that kind of visual
ugliness" :) I just sticked with the old one, adding bbappend.

Visual ugliness/goodness depends on person to person. To me, it doesn't
look ugly at all. I've seen things uglier than just an innocent
wildcard pattern.

Regards,
Eren
Robert P. J. Day Dec. 12, 2012, 8:02 p.m.
On Wed, 12 Dec 2012, Eren Türkay wrote:

> On Wed, Dec 12, 2012 at 01:57:53PM -0500, Robert P. J. Day wrote:
> >   gack.  there's no compelling reason to be that, um, pedantic with
> > the wildcard pattern.  just use
> >
> >   *.{bb,bbappend,bbclass}
> >
> > trying to save a couple characters while introducing that kind of
> > visual ugliness just isn't worth it.
>
> It can be used but I was not the one who introduced "that kind of
> visual ugliness" :) I just sticked with the old one, adding
> bbappend.
>
> Visual ugliness/goodness depends on person to person. To me, it
> doesn't look ugly at all. I've seen things uglier than just an
> innocent wildcard pattern.

  sorry, i didn't mean to pick on you. :-)  i would avoid that kind of
extreme optimization for a couple reasons.

  first, it just *looks* like a typo at first glance.  when i saw it,
my immediate reaction was, oops, spelling mistake and i had to look
again to see it wasn't.

  also, it's sort of just a fluke that you can do that kind of
optimization.  the instant you add another suffix that starts with
something other than a "b", it messes things up and you lose the
advantage.

  anyway, i will leave this in the hands of folks higher up the food
chain.

rday
Eren Türkay Dec. 12, 2012, 8:31 p.m.
On Wed, Dec 12, 2012 at 03:02:31PM -0500, Robert P. J. Day wrote:
>   sorry, i didn't mean to pick on you. :-)  i would avoid that kind of
> extreme optimization for a couple reasons.

No problem :)

>   also, it's sort of just a fluke that you can do that kind of
> optimization.  the instant you add another suffix that starts with
> something other than a "b", it messes things up and you lose the
> advantage.

Right, at first glance such a little code is not understood instantly.
foo.{bbclass,bbappend,bb} is more natural for suffixes.

>   anyway, i will leave this in the hands of folks higher up the food
> chain.

I'm sending V2 of the patch.
Trevor Woerner Dec. 13, 2012, 7:57 p.m.
On Wed, Dec 12, 2012 at 1:42 PM, Eren Türkay <eren@hambedded.org> wrote:
>  " .bb and .bbclass
> -au BufNewFile,BufRead *.b{b,bclass}    set filetype=bitbake
> +au BufNewFile,BufRead *.b{b,bappend,bclass}    set filetype=bitbake


Don't forget to update the comment too :-)
Eren Türkay Dec. 13, 2012, 8:39 p.m.
On Thu, Dec 13, 2012 at 02:57:29PM -0500, Trevor Woerner wrote:
> On Wed, Dec 12, 2012 at 1:42 PM, Eren Türkay <eren@hambedded.org> wrote:
> >  " .bb and .bbclass
> > -au BufNewFile,BufRead *.b{b,bclass}    set filetype=bitbake
> > +au BufNewFile,BufRead *.b{b,bappend,bclass}    set filetype=bitbake
> 
> Don't forget to update the comment too :-)

Thanks you for your feedback. V2 of the patch includes updated comment
already. I fixed it while preparing v2.

Regards,
Eren