On Wed, Dec 5, 2018 at 5:51 AM Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc <g...@mozilla.com> wrote: >> >>> On Fri, Nov 30, 2018 at 10:00 AM <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. >>> > - 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
