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

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
0
tcampbell
11/30/2018 5:57:00 PM
mozilla.dev.platform 6475 articles. 0 followers. Post Follow

10 Replies
25 Views

Similar Articles

[PageSpeed] 10

On Fri, Nov 30, 2018 at 1:00 PM <tcampbell@mozilla.com> wrote:

> 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.


>   - 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.


>   - 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,
-- 
Ehsan
0
Ehsan
11/30/2018 6:50:25 PM
On Fri, Nov 30, 2018 at 10:00 AM <tcampbell@mozilla.com> wrote:

> 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).
>

I don't know what the right answer is, but I'll mention (as I probably have
before) that I have a modeline fixing script that I've used before, and
that I could probably hack up to make whatever change. Though the heuristic
for fixing them will likely be different than I was using before to convert
them to the (former) standard Mozilla mode line (the script tried to guess
if the file was 2 space or 4 space indented).

https://github.com/amccreight/moz-source-tools/blob/master/modeline.py/


Andrew


> --Ted
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
0
Andrew
11/30/2018 6:53:01 PM
On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
> 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
0
Nathan
11/30/2018 7:06:00 PM
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
0
Tom
11/30/2018 7:15:35 PM
On Fri, Nov 30, 2018 at 10:00 AM <tcampbell@mozilla.com> wrote:

> 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).
>

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.
0
Gregory
11/30/2018 9:08:13 PM
On Fri, Nov 30, 2018 at 09:57:00AM -0800, tcampbell@mozilla.com wrote:
> 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
0
Mike
11/30/2018 9:48:27 PM
On Fri, Nov 30, 2018 at 2:06 PM Nathan Froyd <nfroyd@mozilla.com> wrote:

> On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari <ehsan.akhgari@gmail.com>
> wrote:
> > 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.
>

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!).

-- 
Ehsan
0
Ehsan
12/1/2018 1:14:02 AM
On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc <gps@mozilla.com> wrote:

> On Fri, Nov 30, 2018 at 10:00 AM <tcampbell@mozilla.com> wrote:
>
> > 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).
> >
>
> 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
0
Ehsan
12/1/2018 1:23:36 AM
On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari <ehsan.akhgari@gmail.com>
wrote:

> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc <gps@mozilla.com> wrote:
>
>> On Fri, Nov 30, 2018 at 10:00 AM <tcampbell@mozilla.com> wrote:
>>
>> > 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).
>> >
>>
>> 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,
-- 
Ehsan
0
Ehsan
12/5/2018 1:50:30 PM
On Wed, Dec 5, 2018 at 5:51 AM Ehsan Akhgari <ehsan.akhgari@gmail.com>
wrote:

> On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari <ehsan.akhgari@gmail.com>
> wrote:
>
>> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc <gps@mozilla.com> wrote:
>>
>>> On Fri, Nov 30, 2018 at 10:00 AM <tcampbell@mozilla.com> wrote:
>>>
>>> > 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).
>>> >
>>>
>>> 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?
>

That looks promising!

But this file_type_ext only solves the problem for users of the emacs
operating system. Other editors (like vim) support emacs mode lines as
well. I'm assuming we'll want to wait for more general adoption lest we
disrupt non-emacs users.

FWIW https://github.com/editorconfig/editorconfig/issues/190 seems to be
the editorconfig issue tracking this feature request. Perusing through the
discussion, it looks like it needs a champion to push through. Also, there
doesn't seem to be a good "registry" of content types. Someone linked to
https://github.com/github/linguist/blob/master/lib/linguist/languages.yml
as a suggestion. But delegating mappings to a project that GitHub maintains
seems less than ideal. Perhaps someone could chime in and guide them to
something more standard, such as using the IANA media type registry? (I
would, but I'm not a standards expert and don't want to recommend something
when it isn't appropriate.)
0
Gregory
12/10/2018 9:12:32 PM
Reply: