What is future of editor mode-lines after the switch to clang-format?

[t***@mozilla.com]

Now that all of mozilla-central is been migrated to use clang-format automated code formatting, the question of what should happen with editor modelines at the top of files should be considered.

https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format

Here are some options and some arguments I've heard. Please reply with further ideas or rationale. I've not classified points as pro/con and leave that up to the reader's interpretation.

Option 1: Remove mode lines
- Devs are expected to run clang-format anyways (hopefully automated with a hook of sorts)
- Devs are free to set their modeline configuration elsewhere
- If they aren't providing value, they deserve to be removed.
- Many of these were already inconsistent/wrong, so this might be an opportunity to phase out
- Not all devs use vim/emacs, so we should think about workflows help that doesn't need stuff in every single source file.
- The editorconfig project (https://editorconfig.org/) aims to solve this for a variety of editors without marking each file

Option 2: Fix mode lines
- A correct text-width mode-line gives a closer first approximation for devs
- Certain files (eg. moz.build, obj-C headers) use a non-standard file types.

A hybrid of these is also very possible, such as removing certain attributes or only using when file type is non-standard.

I had originally intended this discussion for js/ components, but it turns out to be a question across the whole tree (even if the solution chosen is per-module).

--Ted

[Ehsan Akhgari]

Post by t***@mozilla.com
Now that all of mozilla-central is been migrated to use clang-format
automated code formatting, the question of what should happen with editor
modelines at the top of files should be considered.
https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format
Here are some options and some arguments I've heard. Please reply with
further ideas or rationale. I've not classified points as pro/con and leave
that up to the reader's interpretation.
Option 1: Remove mode lines
- Devs are expected to run clang-format anyways (hopefully automated
with a hook of sorts)

Hopefully with the editor integrations that are available (
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style/Formatting_C++_Code_With_clang-format#Editor_Integrations).
But this would still not give consistent result while typing in all
editors, and this may bother the users of those editors. The text line
width setting especially seems important here.

Post by t***@mozilla.com
- Devs are free to set their modeline configuration elsewhere
- If they aren't providing value, they deserve to be removed.
- Many of these were already inconsistent/wrong, so this might be an
opportunity to phase out

FWIW after a cursory conversation with kmag on IRC the other day, we
realized that it seems that Vim modelines tend to be largely consistent,
whereas the same doesn't seem to be the case for Emacs modelines. So the
experience of individual developers probably depends on editor choice here.

Post by t***@mozilla.com
- Not all devs use vim/emacs, so we should think about workflows help
that doesn't need stuff in every single source file.
- The editorconfig project (https://editorconfig.org/) aims to solve
this for a variety of editors without marking each file
Option 2: Fix mode lines
- A correct text-width mode-line gives a closer first approximation for devs
- Certain files (eg. moz.build, obj-C headers) use a non-standard file types.
A hybrid of these is also very possible, such as removing certain
attributes or only using when file type is non-standard.
I had originally intended this discussion for js/ components, but it turns
out to be a question across the whole tree (even if the solution chosen is
per-module).

I think these are all great points. It seems like for Emacs, it is not
actually necessary to sprinkle modelines across all of the files in your
repository (per https://bugzilla.mozilla.org/show_bug.cgi?id=1023839#c7).
For Vim, Benjamin Bouvier just landed a patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=1511383 to update the existing
modelines to have proper line width and tab width.

It seems like for Emacs, we should probably do something similar also
relatively soon merely to address the newly introduced inconsistencies due
to the reformat. But I'd like to hear from Emacs users what they think,
and if they have a preference on updating existing modelines vs using a
.dir-locals.el file instead...

And of course, further improvements, such as supporting the editorconfig
format is also interesting to discuss, so users of other editors, please do
share feedback!

Thanks,

[Nathan Froyd]

Post by Ehsan Akhgari
I think these are all great points. It seems like for Emacs, it is not
actually necessary to sprinkle modelines across all of the files in your
repository (per https://bugzilla.mozilla.org/show_bug.cgi?id=1023839#c7).
For Vim, Benjamin Bouvier just landed a patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=1511383 to update the existing
modelines to have proper line width and tab width.
It seems like for Emacs, we should probably do something similar also
relatively soon merely to address the newly introduced inconsistencies due
to the reformat. But I'd like to hear from Emacs users what they think,
and if they have a preference on updating existing modelines vs using a
.dir-locals.el file instead...

Using .dir-locals.el sounds great, at least for things like
indent-tabs-mode and c-basic-offset. Emacs 23 is older than what
comes with Ubuntu 14.04 (LTS), so I think we're in the clear using it
as far as Emacs versions go.

Google's style guide comes with a builtin style for emacs's cc-mode:

https://raw.githubusercontent.com/google/styleguide/gh-pages/google-c-style.el

which we could just import into .dir-locals.el.

Unfortunately, it doesn't look like .dir-locals.el provides any way to
set file modes, e.g. setting python-mode for moz.build file, as some
modelines need to do, so we'd need to keep at least the mode bits
around for those files. That doesn't seem too bad.

-Nathan

[Tom Tromey]

Nathan> Unfortunately, it doesn't look like .dir-locals.el provides any way to
Nathan> set file modes, e.g. setting python-mode for moz.build file

That's correct, it's a hole in dir-locals (there's already a bug filed
against Emacs for this). It's also easy to document how to update
auto-mode-alist, though. Separate bits of elisp are already needed for
eslint, so requiring a bit more isn't really so bad.

Tom

[Ehsan Akhgari]

Post by Ehsan Akhgari

Post by Ehsan Akhgari
I think these are all great points. It seems like for Emacs, it is not
actually necessary to sprinkle modelines across all of the files in your
repository (per https://bugzilla.mozilla.org/show_bug.cgi?id=1023839#c7

).

Post by Ehsan Akhgari
For Vim, Benjamin Bouvier just landed a patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=1511383 to update the

existing

Post by Ehsan Akhgari
modelines to have proper line width and tab width.
It seems like for Emacs, we should probably do something similar also
relatively soon merely to address the newly introduced inconsistencies

due

Post by Ehsan Akhgari
to the reformat. But I'd like to hear from Emacs users what they think,
and if they have a preference on updating existing modelines vs using a
.dir-locals.el file instead...

Using .dir-locals.el sounds great, at least for things like
indent-tabs-mode and c-basic-offset. Emacs 23 is older than what
comes with Ubuntu 14.04 (LTS), so I think we're in the clear using it
as far as Emacs versions go.
https://raw.githubusercontent.com/google/styleguide/gh-pages/google-c-style.el
which we could just import into .dir-locals.el.

That sounds great, it should improve things a lot for Emacs users.

BTW in the mean time, arai kindly fixed the indentation in the Emacs
modelines: https://bugzilla.mozilla.org/show_bug.cgi?id=1511393 (thanks a
lot!).

[Andrew McCreight]

This post might be inappropriate. Click to display it.

[Gregory Szorc]

This post might be inappropriate. Click to display it.

[Ehsan Akhgari]

Post by Gregory Szorc

Post by t***@mozilla.com
Now that all of mozilla-central is been migrated to use clang-format
automated code formatting, the question of what should happen with editor
modelines at the top of files should be considered.
https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format
Here are some options and some arguments I've heard. Please reply with
further ideas or rationale. I've not classified points as pro/con and

leave

Post by t***@mozilla.com
that up to the reader's interpretation.
Option 1: Remove mode lines
- Devs are expected to run clang-format anyways (hopefully automated
with a hook of sorts)
- Devs are free to set their modeline configuration elsewhere
- If they aren't providing value, they deserve to be removed.
- Many of these were already inconsistent/wrong, so this might be an
opportunity to phase out
- Not all devs use vim/emacs, so we should think about workflows help
that doesn't need stuff in every single source file.
- The editorconfig project (https://editorconfig.org/) aims to solve
this for a variety of editors without marking each file
Option 2: Fix mode lines
- A correct text-width mode-line gives a closer first approximation for devs
- Certain files (eg. moz.build, obj-C headers) use a non-standard file types.
A hybrid of these is also very possible, such as removing certain
attributes or only using when file type is non-standard.
I had originally intended this discussion for js/ components, but it

turns

Post by t***@mozilla.com
out to be a question across the whole tree (even if the solution chosen

is

Post by t***@mozilla.com
per-module).

https://editorconfig.org/ has been gaining popularity and I think we should
adopt it. Unlike mode lines, you can control behavior for multiple files
with a single source file, making it much more convenient to use.
Unfortunately, it doesn't look like you can set the file type with
.editorconfig files. I think we should lobby for that to be added. Then in
a year's time we can ditch mode lines for the remaining non-standard
filenames in the repo.

Great idea! A future without modelines sounds really nice.

Thanks,

[Ehsan Akhgari]

Post by Ehsan Akhgari

Post by t***@mozilla.com

Post by t***@mozilla.com
Now that all of mozilla-central is been migrated to use clang-format
automated code formatting, the question of what should happen with

editor

Post by t***@mozilla.com
modelines at the top of files should be considered.
https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format
Here are some options and some arguments I've heard. Please reply with
further ideas or rationale. I've not classified points as pro/con and

leave

Post by t***@mozilla.com
that up to the reader's interpretation.
Option 1: Remove mode lines
- Devs are expected to run clang-format anyways (hopefully automated
with a hook of sorts)
- Devs are free to set their modeline configuration elsewhere
- If they aren't providing value, they deserve to be removed.
- Many of these were already inconsistent/wrong, so this might be an
opportunity to phase out
- Not all devs use vim/emacs, so we should think about workflows help
that doesn't need stuff in every single source file.
- The editorconfig project (https://editorconfig.org/) aims to solve
this for a variety of editors without marking each file
Option 2: Fix mode lines
- A correct text-width mode-line gives a closer first approximation

for

Post by t***@mozilla.com
devs
- Certain files (eg. moz.build, obj-C headers) use a non-standard file types.
A hybrid of these is also very possible, such as removing certain
attributes or only using when file type is non-standard.
I had originally intended this discussion for js/ components, but it

turns

Post by t***@mozilla.com
out to be a question across the whole tree (even if the solution chosen

is

Post by t***@mozilla.com
per-module).

https://editorconfig.org/ has been gaining popularity and I think we should
adopt it. Unlike mode lines, you can control behavior for multiple files
with a single source file, making it much more convenient to use.
Unfortunately, it doesn't look like you can set the file type with
.editorconfig files. I think we should lobby for that to be added. Then in
a year's time we can ditch mode lines for the remaining non-standard
filenames in the repo.

Great idea! A future without modelines sounds really nice.

By the way, it seems like the emacs editorconfig plugin already had
experimental support for a filetype -> mode mapping configuration open (see
file_type_ext and file_type_emacs here
https://github.com/editorconfig/editorconfig-emacs#supported-properties).
Is this sufficient for our needs as far as replacing the file type
information in the Emacs modelines go?

Thanks,

[Mike Hommey]

Post by t***@mozilla.com
Now that all of mozilla-central is been migrated to use clang-format automated code formatting, the question of what should happen with editor modelines at the top of files should be considered.
https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format
Here are some options and some arguments I've heard. Please reply with further ideas or rationale. I've not classified points as pro/con and leave that up to the reader's interpretation.
Option 1: Remove mode lines
- Devs are expected to run clang-format anyways (hopefully automated with a hook of sorts)
- Devs are free to set their modeline configuration elsewhere
- If they aren't providing value, they deserve to be removed.
- Many of these were already inconsistent/wrong, so this might be an opportunity to phase out
- Not all devs use vim/emacs, so we should think about workflows help that doesn't need stuff in every single source file.

Even more, Debian-based vim packages have the modeline-reading feature
disabled by default for security reasons (because they can, in fact, do
anything), which makes vim modelines essentially useless to even a large
number of vim users.

Mike