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

[Ehsan Akhgari]

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?

[Ehsan Akhgari]

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: Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input

[Eli Grey via dev-platform]

On Thursday, November 29, 2018 at 5:22:47 PM UTC-8, masayuki nakano wrote:
> Summary: We'll stop dispatching non-printable "keypress" events. 
> "non-printable" means that key press or key combination does not 
> introduce text input without IME.  For example, arrow key press, Ctrl+A, 
> etc.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=968056
> 
> Link to standard:
> For keys which introduce text input:
> https://w3c.github.io/uievents/#legacy-keyboardevent-event-types
> For Enter key:
> https://github.com/w3c/uievents/issues/183
> 
> Platform coverage: All
> 
> Estimated or target release: 65
> 
> DevTools bug: N/A
> 
> Do other browser engines implement this?
> 
> Yes, the other browsers use this behavior traditionally, and UI Events 
> declared the behavior as "standard".
> 
> web-platform-tests: N/A due to requiring user input, but we have 
> mochitests with synthesized events.
> 
> This new behavior was enabled in Nightly since 61. This caused breaking 
> a lot of major web apps.  However, all of them have been fixed by the 
> cooperation of the vendors.
> 
> Of course, we may meet other broken web apps especially in intranet. 
> While we're testing this behavior in Nightly, we used blacklist pref 
> (dom.keyboardevent.keypress.hack.dispatch_non_printable_keys) to disable 
> this new behavior only in specific domains.  If we'll get broken web 
> apps even after release, we and users can disable it with using this 
> blacklist.
> 
> Enabling patch has been landed from:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1496288
> because we need to manage those changes as a set.
> 
> -- 
> Masayuki Nakano 
> Software Engineer, Mozilla

I think the spec is confusing and not well-reasoned enough to introduce this 
misnomer. This change will make it so that there are two events with synonymous 
meaning, and only introduces potential site breakage. 

The event is literally called "keypress", not "input". Developers are going to 
end up using it to track keypresses regardlessly due to the incorrect name. If 
they want to track input, that's what the "input" event is for.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input

[Eli Grey via dev-platform]

On Thursday, November 29, 2018 at 5:22:47 PM UTC-8, masayuki nakano wrote:
> Summary: We'll stop dispatching non-printable "keypress" events. 
> "non-printable" means that key press or key combination does not 
> introduce text input without IME.  For example, arrow key press, Ctrl+A, 
> etc.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=968056
> 
> Link to standard:
> For keys which introduce text input:
> https://w3c.github.io/uievents/#legacy-keyboardevent-event-types
> For Enter key:
> https://github.com/w3c/uievents/issues/183
> 
> Platform coverage: All
> 
> Estimated or target release: 65
> 
> DevTools bug: N/A
> 
> Do other browser engines implement this?
> 
> Yes, the other browsers use this behavior traditionally, and UI Events 
> declared the behavior as "standard".
> 
> web-platform-tests: N/A due to requiring user input, but we have 
> mochitests with synthesized events.
> 
> This new behavior was enabled in Nightly since 61. This caused breaking 
> a lot of major web apps.  However, all of them have been fixed by the 
> cooperation of the vendors.
> 
> Of course, we may meet other broken web apps especially in intranet. 
> While we're testing this behavior in Nightly, we used blacklist pref 
> (dom.keyboardevent.keypress.hack.dispatch_non_printable_keys) to disable 
> this new behavior only in specific domains.  If we'll get broken web 
> apps even after release, we and users can disable it with using this 
> blacklist.
> 
> Enabling patch has been landed from:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1496288
> because we need to manage those changes as a set.
> 
> -- 
> Masayuki Nakano 
> Software Engineer, Mozilla

I think the spec is confusing and not well-reasoned enough to introduce this 
misnomer. This change will make it so that there are two events with synonymous 
meaning, and only introduces potential site breakage.

The event is literally called "keypress", not "input". Developers are going to 
end up using it to track keypresses regardlessly due to the incorrect name. If 
they want to track input, that's the the "input" event is for.
___
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?

[Mike Hommey]

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?

[Gregory Szorc]

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?

[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
___
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 Froyd]

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?

[Andrew McCreight]

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?

[Ehsan Akhgari]

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

Re: The tree has been reformatted now!

[Emilio Cobos Álvarez]

And https://hg.mozilla.org/mozilla-central/rev/138f65958545 if you use 
the git driver if you don't want sadness :)


 -- Emilio

On 11/30/18 6:20 PM, Andi-Bogdan Postelnicu wrote:

Hello all,

I’m coming back with a followup email since I don’t think that in the previous 
email we mentioned what is the minimum version that should be used for rebasing.

o  changeset:   501271:bf92aff5b93d
|  tag: tip
|  fxtree:  central
|  user:Andi-Bogdan Postelnicu 
|  date:Fri Nov 30 14:04:46 2018 +0200
|  summary: Bug 1511285 - Make 'mach clang-format' more efficient when 
outputting to stdout. r=ehsan, a=aryx
|
o  changeset:   501270:3acb179a1759
|  user:Ehsan Akhgari 
|  date:Fri Nov 30 06:32:29 2018 -0500
|  summary: Bug 1511319 - Ensure that tools/clang-tidy/test doesn't get 
reformatted using clang-format; r=sylvestre a=Aryx
|
o  changeset:   501269:4a8721265f7e
|  user:Andi-Bogdan Postelnicu 
|  date:Fri Nov 30 13:25:44 2018 +0200
|  summary: Bug 1511181 - Quick fix for .hg-format-source that has an empty 
line. r=ehsan, a=aryx
|
@  changeset:   501268:6f3709b38781
|  user:Sylvestre Ledru 
|  date:Fri Nov 30 11:46:48 2018 +0100
|  summary: Bug 1511181 - Reformat everything to the Google coding style 
r=ehsan a=clang-format
|
o  changeset:   501267:2ac59ec6f8de
|  user:Sylvestre Ledru 
|  date:Fri Nov 30 10:46:09 2018 +0100
|  summary: Added tag PRE_TREEWIDE_CLANG_FORMAT for changeset 58a0412e1557

We have the above ‘hg log -G’, where we can see that the change-set that 
doesn’t have the format is `2ac59ec6f8de` and the one that introduces the tree 
formatting ‘6f3709b38781’, but after that change-set we did a couple of more 
fixes in order to resolve the fallout of the format.
In conclusion in order to be able to rebase without any issues please use any 
change-set greater than ‘bf92aff5b93d’.

Many thanks,
Andi


On 30 Nov 2018, at 16:46, Andi-Bogdan Postelnicu  wrote:

Hello all

Starting with revision 6f3709b3878117466168c40affa7bca0b60cf75b 

 mozilla-central has been formatted using ./mach clang-format following the Google 
coding style.
In order to diminish as much as possible the effort of merging pre-format 
patches into our newly formatted repo we devised the following plan for the two 
SCMs that we use:

Mercurial

Please make sure you run ‘mach bootstrap’ and allow the install of the 
‘format-source’ extension before pulling the reformat changeset. This extension 
provides a simple and behind-the-curtains way on how you can integrate 
un-formatted code into a formatted repo.
 
 Example

Let’s assume the patch that need rebasing is at rev: 1000 and mozilla-central 
is at rev: 2000.

hg rebase -b 1000 -d 2000

Or in case you want to have a more verbose output:

hg rebase -b 1000 -d 2000 -debug

The extension registers at the merge level and it will format both sides and 
after that uses the original merge tool to combine for the final result.
 
 For more detailed information on the process please also see this  document.


  Git
 Courtesy of Ehsan and Emilio there are two ways that help with the merge:
 Ehsan’s implementation 

 Emilio’s implementation 
For your convenience, the parent changeset of the reformat changeset has been 
tagged in Mercurial as “PRE_TREEWIDE_CLANG_FORMAT”.  This will allow easily 
updating to that version using the following command for example when rebasing 
local changes:

hg up -r PRE_TREEWIDE_CLANG_FORMAT


Hope this transition goes smooth as possible but if something comes up and you 
need assistance please ping Andi on IRC.

Many thanks,
Ehsan, Sylvestre and Andi



___
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

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

[tcampbell]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in San Diego, California

[Botond Ballo]

Hi everyone,

My blog post about the C++ standards meeting that took place earlier
this month is now published:

https://botondballo.wordpress.com/2018/11/30/trip-report-c-standards-meeting-in-san-diego-november-2018/

Cheers,
Botond

On Mon, Oct 22, 2018 at 5:52 PM Botond Ballo  wrote:
>
> Hi everyone!
>
> The next meeting of the C++ Standards Committee will be November 5-10
> in San Diego, California.
>
> This is promising to be the Committee's largest meeting to date, both
> in terms of attendees (expected over 150), and submitted proposals
> (over 250 in the pre-meeting mailing). This is encouraging, as it
> reflects a heightened level of interest in the language and its
> standardization. At the same time, the committee is undertaking some
> procedural changes to stay afloat this sea of proposals, notably
> spinning up new Incubator subgroups to process / filter through
> proposals for new extensions before the main Evolution and Library
> Evolution groups look at them.
>
> Meanwhile, work continues on C++20, with Ranges and "natural syntax"
> Concepts on the brink of consensus, Modules making really good
> progress with the committee working extra hard to get them into C++20,
> and Coroutines continuing to be under debate with two competing
> proposals. 2D Graphics is dead for now, though it may yet rise from
> the ashes [1]. Reflection, Executors, and several other features are
> moving forward in the form of Technical Specifications.
>
> If you're curious about the state of C++ standardization, I encourage
> you to check out my blog posts where I summarize each meeting in
> detail (most recent one here [2]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [3] and here [4]).
>
> I will be attending this meeting, likely splitting my time between
> Evolution Working Group (where new language features are discussed at
> the design level), and the EWG Incubator group (where proposals bound
> for Evolution undergo a preliminary round of feedback). As always, if
> there's anything you'd like me to find out for you at the meeting, or
> any feedback you'd like me to communicate, please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
>
> [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1200r0.pdf
> [2] 
> https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/
> [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/#mailing2018-06
> [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/#mailing2018-10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The tree has been reformatted now!

[Andi-Bogdan Postelnicu]

Hello all,

I’m coming back with a followup email since I don’t think that in the previous 
email we mentioned what is the minimum version that should be used for rebasing.

o  changeset:   501271:bf92aff5b93d
|  tag: tip
|  fxtree:  central
|  user:Andi-Bogdan Postelnicu 
|  date:Fri Nov 30 14:04:46 2018 +0200
|  summary: Bug 1511285 - Make 'mach clang-format' more efficient when 
outputting to stdout. r=ehsan, a=aryx
|
o  changeset:   501270:3acb179a1759
|  user:Ehsan Akhgari 
|  date:Fri Nov 30 06:32:29 2018 -0500
|  summary: Bug 1511319 - Ensure that tools/clang-tidy/test doesn't get 
reformatted using clang-format; r=sylvestre a=Aryx
|
o  changeset:   501269:4a8721265f7e
|  user:Andi-Bogdan Postelnicu 
|  date:Fri Nov 30 13:25:44 2018 +0200
|  summary: Bug 1511181 - Quick fix for .hg-format-source that has an empty 
line. r=ehsan, a=aryx
|
@  changeset:   501268:6f3709b38781
|  user:Sylvestre Ledru 
|  date:Fri Nov 30 11:46:48 2018 +0100
|  summary: Bug 1511181 - Reformat everything to the Google coding style 
r=ehsan a=clang-format
|
o  changeset:   501267:2ac59ec6f8de
|  user:Sylvestre Ledru 
|  date:Fri Nov 30 10:46:09 2018 +0100
|  summary: Added tag PRE_TREEWIDE_CLANG_FORMAT for changeset 58a0412e1557

We have the above ‘hg log -G’, where we can see that the change-set that 
doesn’t have the format is `2ac59ec6f8de` and the one that introduces the tree 
formatting ‘6f3709b38781’, but after that change-set we did a couple of more 
fixes in order to resolve the fallout of the format. 
In conclusion in order to be able to rebase without any issues please use any 
change-set greater than ‘bf92aff5b93d’.

Many thanks,
Andi

> On 30 Nov 2018, at 16:46, Andi-Bogdan Postelnicu  wrote:
> 
> Hello all
> 
> Starting with revision 6f3709b3878117466168c40affa7bca0b60cf75b 
> 
>  mozilla-central has been formatted using ./mach clang-format following the 
> Google coding style. 
> In order to diminish as much as possible the effort of merging pre-format 
> patches into our newly formatted repo we devised the following plan for the 
> two SCMs that we use:
> 
> Mercurial
> 
> Please make sure you run ‘mach bootstrap’ and allow the install of the 
> ‘format-source’ extension before pulling the reformat changeset. This 
> extension provides a simple and behind-the-curtains way on how you can 
> integrate un-formatted code into a formatted repo. 
> 
> Example
> Let’s assume the patch that need rebasing is at rev: 1000 and mozilla-central 
> is at rev: 2000.
> 
> hg rebase -b 1000 -d 2000
> 
> Or in case you want to have a more verbose output:
> 
> hg rebase -b 1000 -d 2000 -debug
> 
> The extension registers at the merge level and it will format both sides and 
> after that uses the original merge tool to combine for the final result.
> 
> For more detailed information on the process please also see this 
> 
>  document.
> 
>  Git
> Courtesy of Ehsan and Emilio there are two ways that help with the merge:
> Ehsan’s implementation 
> 
> Emilio’s implementation 
> For your convenience, the parent changeset of the reformat changeset has been 
> tagged in Mercurial as “PRE_TREEWIDE_CLANG_FORMAT”.  This will allow easily 
> updating to that version using the following command for example when 
> rebasing local changes:
> 
> hg up -r PRE_TREEWIDE_CLANG_FORMAT
> 
> 
> Hope this transition goes smooth as possible but if something comes up and 
> you need assistance please ping Andi on IRC.
> 
> Many thanks,
> Ehsan, Sylvestre and Andi 
> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

The tree has been reformatted now!

[Andi-Bogdan Postelnicu]

Hello all

Starting with revision 6f3709b3878117466168c40affa7bca0b60cf75b 

 mozilla-central has been formatted using ./mach clang-format following the 
Google coding style. 
In order to diminish as much as possible the effort of merging pre-format 
patches into our newly formatted repo we devised the following plan for the two 
SCMs that we use:

Mercurial

Please make sure you run ‘mach bootstrap’ and allow the install of the 
‘format-source’ extension before pulling the reformat changeset. This extension 
provides a simple and behind-the-curtains way on how you can integrate 
un-formatted code into a formatted repo. 

Example
Let’s assume the patch that need rebasing is at rev: 1000 and mozilla-central 
is at rev: 2000.

hg rebase -b 1000 -d 2000

Or in case you want to have a more verbose output:

hg rebase -b 1000 -d 2000 -debug

The extension registers at the merge level and it will format both sides and 
after that uses the original merge tool to combine for the final result.

For more detailed information on the process please also see this 

 document.

 Git
Courtesy of Ehsan and Emilio there are two ways that help with the merge:
Ehsan’s implementation 

Emilio’s implementation 
For your convenience, the parent changeset of the reformat changeset has been 
tagged in Mercurial as “PRE_TREEWIDE_CLANG_FORMAT”.  This will allow easily 
updating to that version using the following command for example when rebasing 
local changes:

hg up -r PRE_TREEWIDE_CLANG_FORMAT


Hope this transition goes smooth as possible but if something comes up and you 
need assistance please ping Andi on IRC.

Many thanks,
Ehsan, Sylvestre and Andi 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: set keyCode or charCode of "keypress" event to the other's non-zero value

[James Graham]

On 30/11/2018 01:37, Masayuki Nakano wrote:
web-platform-tests: N/A due to requiring user input, but we have 
mochitests with synthesized events.


I think it should be possible to write web-platform-tests for this kind 
of thing now, using the testdriver API and in particular the actions 
support see e.g. [1], [2]


If this still doesn't meet your use case please let me know because we 
should work out how to make testing this kind of stuff possible 
cross-browser; as you well know UI events have been an interop nightmare 
in the past and we can't afford to let that situation continue into the 
future for new devices and APIs.


[1] https://web-platform-tests.org/writing-tests/testdriver.html
[2] 
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/infrastructure/testdriver/actions/multiDevice.html

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform