Specify language for code blocks.

docs/mojo_in_chromium.md

 # Mojo in Chromium
 
 This document is intended to serve as a Mojo primer for Chromium developers. No
 prior knowledge of Mojo is assumed.
 
 [TOC]
 
 ## Should I Bother Reading This?
 
 If you're planning to build a Chromium feature that needs IPC and you aren't
@@ skipping 77 matching lines @@
 The C++ header (`frobinator.mojom.h`) defines an abstract class for each
 mojom interface specified. Namespaces are derived from the `module` name.
 
 **NOTE:** Chromium convention for component `foo`'s module name is `foo.mojom`.
 This means all mojom-generated C++ typenames for component `foo` will live in
 the `foo::mojom` namespace to avoid collisions with non-generated typenames.
 
 In this example the generated `frob::mojom::Frobinator` has a single
 pure virtual function:
 
-```
+```cpp
 namespace frob {
 
 class Frobinator {
  public:
   virtual void Frobinate() = 0;
 };
 
 }  // namespace frob
 ```
 
 To create a `Frobinator` service, one simply implements `foo::Frobinator` and
 provides a means of binding pipes to it.
 
 ### Binding to Pipes
 
 Let's look at some sample code:
 
-```
+```cpp
 // src/components/frob/frobinator_impl.cc
 
 #include "components/frob/public/interfaces/frobinator.mojom.h"
 #include "mojo/public/cpp/bindings/binding.h"
 #include "mojo/public/cpp/bindings/interface_request.h"
 
 namespace frob {
 
 class FrobinatorImpl : public mojom::Frobinator {
  public:
@@ skipping 14 matching lines @@
 The first thing to note is that `mojo::Binding<T>` *binds* one end of a message
 pipe to an implementation of a service. This means it watches that end of the
 pipe for incoming messages; it knows how to decode messages for interface `T`,
 and it dispatches them to methods on the bound `T` implementation.
 
 `mojom::FrobinatorRequest` is a generated type alias for
 `mojo::InterfaceRequest<mojom::Frobinator>` and is essentially semantic sugar
 for a strongly-typed message pipe endpoint. A common way to create new message
 pipes is via the `GetProxy` call defined in `interface_request.h`:
 
-```
+```cpp
 mojom::FrobinatorPtr proxy;
 mojom::FrobinatorRequest request = mojo::GetProxy(&proxy);
 ```
 
 This creates a new message pipe with one end owned by `proxy` and the other end
 owned by `request`. It has the nice property of attaching common type
 information to each end of the pipe.
 
 Note that `InterfaceRequest<T>` doesn't actually **do** anything. It just scopes
 a pipe endpoint and associates it with an interface type at compile time. As
 such, other typed service binding primitives such as `mojo::Binding<T>` take
 these objects as input when they need an endpoint to bind to.
 
 `mojom::FrobinatorPtr` is a generated type alias for
 `mojo::InterfacePtr<mojom::Frobinator>`. An `InterfacePtr<T>` scopes a message
 pipe endpoint as well, but it also internally implements every method on `T` by
 serializing a corresponding message and writing it to the pipe.
 
 Hence we can put this together to talk to a `FrobinatorImpl` over a pipe:
 
-```
+```cpp
 frob:mojom::FrobinatorPtr frobinator;
 frob::FrobinatorImpl impl(GetProxy(&frobinator));
 
 // Tada!
 frobinator->Frobinate();
 ```
 
 Behind the scenes this serializes a message corresponding to the `Frobinate`
 request and writes it to one end of the pipe. Eventually (and incidentally,
 very soon after), `impl`'s internal `mojo::Binding` will decode this message and
@@ skipping 18 matching lines @@
 module frob.mojom;
 
 interface Frobinator {
   Frobinate();
   GetFrobinationLevels() => (int min, int max);
 };
 ```
 
 and update our implementation:
 
-```
+```cpp
 class FrobinatorImpl : public mojom::Frobinator {
  public:
   // ...
 
   // mojom::Frobinator:
   void Frobinate() override { /* ... */ }
   void GetFrobinationLevels(const GetFrobinationLevelsCallback& callback) {
     callback.Run(1, 42);
   }
 };
 ```
 
 When the service implementation runs `callback`, the response arguments are
 serialized and sent back over the pipe. The proxy on the other end knows how to
 read this response and will in turn dispatch it to a callback on that end:
 
-```
+```cpp
 void ShowLevels(int min, int max) {
   DLOG(INFO) << "Frobinator min=" << min << " max=" << max;
 }
 
 // ...
 
   mojom::FrobinatorPtr frobinator;
   FrobinatorImpl impl(GetProxy(&frobinator));
 
   frobinator->GetFrobinatorLevels(base::Bind(&ShowLevels));
@@ skipping 16 matching lines @@
 just a mapping from interface name to factory function -- or you can connect by
 name to services registered on the remote side.
 
 **NOTE:** In this context the "factory function" is simply a callback which
 takes a pipe endpoint and does something with it. It's expected that you'll
 either bind it to a service implementation of some kind or you will close it, effectively rejecting the connection request.
 
 We can build a simple browser-side `FrobinatorImpl` service that has access to a
 `BrowserContext` for any frame which connects to it:
 
-```
+```cpp
 #include "base/macros.h"
 #include "components/frob/public/interfaces/frobinator.mojom.h"
 #include "content/public/browser/browser_context.h"
 #include "mojo/public/cpp/system/interface_request.h"
 #include "mojo/public/cpp/system/strong_binding.h"
 
 namespace frob {
 
 class FrobinatorImpl : public mojom::Frobinator {
  public:
@@ skipping 22 matching lines @@
 
   DISALLOW_COPY_AND_ASSIGN(FrobinatorImpl);
 };
 
 }  // namespace frob
 ```
 
 Now somewhere in the browser we register the Frobinator service with each
 `RenderFrameHost` ([this](https://goo.gl/HEFn63) is a popular spot):
 
-```
+```cpp
 frame_host->GetServiceRegistry()->AddService<frob::mojom::Frobinator>(
     base::Bind(
         &frob::FrobinatorImpl::Create,
         base::Unretained(frame_host->GetProcess()->GetBrowserContext())));
 ```
 
 And in the render process we can now do something like:
 
-```
+```cpp
 mojom::FrobinatorPtr frobinator;
 render_frame->GetServiceRegistry()->ConnectToRemoteService(
     mojo::GetProxy(&frobinator));
 
 // It's IPC!
 frobinator->Frobinate();
 ```
 
 There are now plenty of concrete examples of Mojo usage in the Chromium tree.
 Poke around at existing mojom files and see how their implementions are built
 and connected.
 
 ## Mojo in Blink
 
 *TODO*
 
 This is a work in progress. TL;DR: We'll also soon begin using Mojo services
 from Blink so that the platform layer can consume browser services
 directly via Mojo. The long-term goal there is to eliminate `content/renderer`.
 
 ## Questions, Discussion, etc.
 
 A good place to find highly concentrated doses of people who know and care
 about Mojo in Chromium would be the [chromium-mojo](https://goo.gl/A4ebWB)
 mailing list[.](https://goo.gl/L70ihQ)