ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] modelines

From: Chris Maynard <Chris.Maynard@xxxxxxxxx>
Date: Wed, 28 Sep 2011 01:51:05 +0000 (UTC)
Stephen Fisher <steve@...> writes:

> Since I started coding for Wireshark in 2006, the convention wisdom (as 
> I understood it) has always been to stick with the formatting method 
> that the file already has, whatever that may be.  

Right, but what if there's a file already consistently using tabs throughout,
but with no current modelines?  (Example: packet-igmp.c)  What value to use for
the tabstop, for example?  It would seem that tabstop=8 is preferred, judging by
the number of epan/dissectors/packet-*.c files using that value (54) as opposed
to using tabstop=4 (3); however, I am wondering if 8 is simply used more than 4
because that's what the Wireshark modeline generation tool happens to default
to, so I just wanted to check if that was in fact the recommendation or if it
was just a somewhat arbitrary choice, and if arbitrary, then what the actual
recommendation would be.

>                                                   Emacs is pretty good 
> about keeping the same indentation as the line above the one you're 
> inserting, although it may differ in spaces vs. tabs.  

Hence the inquiry about adding setq tab-width, [and implicitly indent-tabs-mode
too).  As more and more modelines get added, I was just thinking that it might
be nice to have as many common editors covered as reasonably possible instead of
adding some now and having to go back again to add more later.

>                                                        I'm one of the 
> few fans of actual tabs.  Whatever the preference, I think having mode 
> lines is a great choice so we don't have to bother (we can be lazy) 
> changing our editor/remembering to format it a certain way to keep it 
> consistent :).

I really like the modelines too; I guess I'm also lazy.