Clean up formatting to simplify post-Doxygen processing.

ppapi/api/ppb_message_loop.idl

 /* Copyright (c) 2012 The Chromium Authors. All rights reserved.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 /**
  * Defines the PPB_MessageLoop interface.
  */
 label Chrome {
   M25 = 1.0
@@ skipping 19 matching lines @@
  *    - Create the thread yourself (using pthreads).
  *    - Create the message loop resource.
  *    - Pass the message loop resource to your thread's main function.
  *    - Call PostWork() on the message loop to run functions on the thread.
  *
  *   From the background thread's main function:
  *    - Call AttachToCurrentThread() with the message loop resource.
  *    - Call Run() with the message loop resource.
  *
  *   Your callbacks should look like this:
- *      @code
- *      void DoMyWork(void* user_data, int32_t status) {
- *        if (status != PP_OK) {
- *          Cleanup();  // e.g. free user_data.
- *          return;
- *        }
- *        ... do your work...
- *      }
- *      @endcode
+ *   @code
+ *   void DoMyWork(void* user_data, int32_t status) {
+ *     if (status != PP_OK) {
+ *       Cleanup();  // e.g. free user_data.
+ *       return;
+ *     }
+ *     ... do your work...
+ *   }
+ *   @endcode
  * For a C++ example, see ppapi/utility/threading/simple_thread.h
  *
  * (You can also create the message loop resource on the background thread,
  * but then the main thread will have no reference to it should you want to
  * call PostWork()).
  *
  *
  * THREAD HANDLING
  *
  * The main thread has an implicitly created message loop. The main thread is
@@ skipping 50 matching lines @@
  *
  * If you post a callback to a message loop that's been destroyed, or to an
  * invalid message loop, PostWork will return an error and will not run the
  * callback. This is true even for callbacks with the "required" flag set,
  * since the system may not even know what thread to issue the error callback
  * on.
  *
  * Therefore, you should check for errors from PostWork and destroy any
  * associated memory to avoid leaks. If you're using the C++
  * CompletionCallbackFactory, use the following pattern:
- *
- *   pp::CompletionCallback callback = factory_.NewOptionalCallback(...);
- *   int32_t result = message_loop.PostWork(callback);
- *   if (result != PP_OK)
- *     callback.Run(result);
- *
+ * @code
+ * pp::CompletionCallback callback = factory_.NewOptionalCallback(...);
+ * int32_t result = message_loop.PostWork(callback);
+ * if (result != PP_OK)
+ *   callback.Run(result);
+ * @endcode
  * This will run the callback with an error value, and assumes that the
  * implementation of your callback checks the "result" argument and returns
  * immediately on error.
  */
 interface PPB_MessageLoop {
   /**
    * Creates a message loop resource.
    *
    * This may be called from any thread. After your thread starts but before
    * issuing any other PPAPI calls on it, you must associate it with a message
@@ skipping 127 matching lines @@
    *
    * @return
    *   - PP_OK: The request to quit was successfully posted.
    *   - PP_ERROR_BADRESOURCE: The message loop was invalid.
    *   - PP_ERROR_WRONG_THREAD: You are attempting to quit the main thread.
    *     The main thread's message loop is managed by the system and can't be
    *     quit.
    */
   int32_t PostQuit([in] PP_Resource message_loop, PP_Bool should_destroy);
 };