Re: What is future of editor mode-lines after the switch to clang-format?
On Wed, Dec 5, 2018 at 5:51 AM Ehsan Akhgari wrote: > On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari > wrote: > >> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote: >> >>> On Fri, Nov 30, 2018 at 10:00 AM 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.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari wrote: > On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote: > >> On Fri, Nov 30, 2018 at 10:00 AM 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote: > On Fri, Nov 30, 2018 at 10:00 AM 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 2:06 PM Nathan Froyd wrote: > On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 09:57:00AM -0800, tcampb...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 10:00 AM 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 10:00 AM 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 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is future of editor mode-lines after the switch to clang-format?
On Fri, Nov 30, 2018 at 1:00 PM 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
