We currently provide indentation hints using both modelines and .editorconfig files.
It would be nice if we could drop the modelines, which add a noticeable amount of boilerplate to our source files.
Details
The modelines were added years ago, before EditorConfig existed. According to the EditorConfig home page, most editors either support .editorconfig files out of the box (Visual Studio) or can do so using a plugin (Emacs, Vim, Visual Studio Code). The one notable outlier seems to be Qt Creator, but it doesn't support modelines either.
Is there any reason we shouldn't add "make sure your editor supports EditorConfig" to the setup sections of the Developer's Guide and start dropping our modeline stanzas?
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Nitpick: Because we lack a consistent style our EditorConfig C settings have large amounts of boilerplate, it's just hidden away.
I think there should be only one system in use. Without a consistent style there is no clear advantage to either but overall I think EditorConfig has wider editor support and less security concerns.
in the top level .editorconfig, but we haven't officially declared that to be our preferred indentation style. I agree that it would be nice to get rid of all of the exceptions scattered around.
That would be nice. EditorConfig is designed around consistency. Having to repeat the same EC settings over and over for exceptions is IMO another kind of boilerplate.
A minor annoyance is that the vim EditorConfig plugin doesn't have a RPM package for RHEL/CentOS 7 or SUSE Enterprise Server 12 (but can be installed outside the package systems there), though it does for 8 and 15, respectively, whereas modelines do work out of the box.
Not a killer objection, but one more thing on the pile of "it would be good to drop RHEL 7 / SLES 12 support." Both distributions are officially supported through some time in 2024, which would mean ordinarily that if we wanted to support them through then we'd have to support them through approximately 4.4 or else lengthen the end of support for an earlier release like was done for 2.6.
@boolean263 I would highly suggest creating a .clang-format because vscode can directly import it. So in the short and long-term, it's going to facilitate new users to quickly submit PRs without worrying of formatting rules.
I've crafted a proposed .clang-format file in !6298 (closed). I ran it over tshark.c and included that in the MR so that people can see how the current settings would affect the formatting of one of our more notable source files.
I bumbled across tools/ws-coding-style.cfg which is a configuration file for Uncrustify. It was added way back in #5924 (closed) and serves a similar purpose to clang-format. Mentioning it here since it's relevant.
Remember to remove modelines from templates like docs/packet-PROTOABBREV.c, to prevent more modelines from being introduced. I'm making a new dissector and I used packet-PROTOABBREV as a base a few days ago, and now my dissector has modelines, I hadn't seen you were planning to remove them...