Change monospace text formatting

Summary: Using `##` can cause some formatting issues, see D13071.

Test Plan: See D13071.

Reviewers: epriestley, #blessed_reviewers, chad

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D13072

src/docs/contributor/adding_new_css_and_js.diviner

···
 `webroot/rsrc/css/` or `webroot/rsrc/js/` inside your `phabricator/`
 directory.
 
-Each file must ##@provides## itself as a component, declared in a header
-comment:
+Each file must `@provides` itself as a component, declared in a header comment:
 
   LANG=css
   /**

src/docs/contributor/darkconsole.diviner

···
 = Plugin: Error Log =
 
 The "Error Log" plugin shows errors that occurred while generating the page,
-similar to the httpd ##error.log##. You can send information to the error log
+similar to the httpd `error.log`. You can send information to the error log
 explicitly with the @{function@libphutil:phlog} function.
 
 If errors occurred, a red dot will appear on the plugin tab.

src/docs/contributor/javascript_coding_standards.diviner

···
 
   - Use two spaces for indentation. Don't use literal tab characters.
   - Use Unix linebreaks ("\n"), not MSDOS ("\r\n") or OS9 ("\r").
-  - Put a space after control keywords like ##if## and ##for##.
+  - Put a space after control keywords like `if` and `for`.
   - Put a space after commas in argument lists.
-  - Put space around operators like ##=##, ##<##, etc.
+  - Put space around operators like `=`, `<`, etc.
   - Don't put spaces after function names.
   - Parentheses should hug their contents.
   - Generally, prefer to wrap code at 80 columns.
···
 The Javascript language unambiguously dictates casing/naming rules; follow those
 rules.
 
-  - Name variables using ##lowercase_with_underscores##.
-  - Name classes using ##UpperCamelCase##.
-  - Name methods and properties using ##lowerCamelCase##.
-  - Name global functions using ##lowerCamelCase##. Avoid defining global
+  - Name variables using `lowercase_with_underscores`.
+  - Name classes using `UpperCamelCase`.
+  - Name methods and properties using `lowerCamelCase`.
+  - Name global functions using `lowerCamelCase`. Avoid defining global
     functions.
-  - Name constants using ##UPPERCASE##.
-  - Write ##true##, ##false##, and ##null## in lowercase.
+  - Name constants using `UPPERCASE`.
+  - Write `true`, `false`, and `null` in lowercase.
   - "Internal" methods and properties should be prefixed with an underscore.
     For more information about what "internal" means, see
     **Leading Underscores**, below.
 
 = Comments =
 
-  - Strongly prefer ##//## comments for making comments inside the bodies of
+  - Strongly prefer `//` comments for making comments inside the bodies of
     functions and methods (this lets someone easily comment out a block of code
     while debugging later).
 
 = Javascript Language =
 
-  - Use ##[]## and ##{}##, not ##new Array## and ##new Object##.
+  - Use `[]` and `{}`, not `new Array` and `new Object`.
   - When creating an object literal, do not quote keys unless required.
 
 = Examples =
···
   }
 
 You should always put braces around the body of an if clause, even if it is only
-one line. Note that operators like ##>## and ##===## are also surrounded by
+one line. Note that operators like `>` and `===` are also surrounded by
 spaces.
 
 **for (iteration):**
···
   }
 
 `break` statements should be indented to block level. If you don't push them
-in, you end up with an inconsistent rule for conditional ##break## statements,
-as in the ##2## case.
+in, you end up with an inconsistent rule for conditional `break` statements,
+as in the `2` case.
 
-If you insist on having a "fall through" case that does not end with ##break##,
+If you insist on having a "fall through" case that does not end with `break`,
 make it clear in a comment that you wrote this intentionally. For instance:
 
   lang=js

src/docs/contributor/n_plus_one.diviner

···
     // ...
   }
 
-Assuming ##load_cats()## has an implementation that boils down to:
+Assuming `load_cats()` has an implementation that boils down to:
 
   SELECT * FROM cat WHERE ...
 
-..and ##load_hats_for_cat($cat)## has an implementation something like this:
+..and `load_hats_for_cat($cat)` has an implementation something like this:
 
   SELECT * FROM hat WHERE catID = ...
 

src/docs/contributor/phabricator_code_layout.diviner

···
 
 = Best Practice Class and Subdirectory Organization =
 
-Suppose you were working on the application ##Derp##.
+Suppose you were working on the application `Derp`.
 
   phabricator/src/applications/derp/
 
-If ##Derp## were as simple as possible, it would have one subdirectory:
+If `Derp` were as simple as possible, it would have one subdirectory:
 
   phabricator/src/applications/derp/controller/
 
-containing the file ##DerpController.php## with the class
+containing the file `DerpController.php` with the class
 
- - ##DerpController##: minimally implements a ##processRequest()## method
+ - `DerpController`: minimally implements a `processRequest()` method
    which returns some @{class:AphrontResponse} object. The class would probably
    extend @{class:PhabricatorController}.
 
-If ##Derp## were (relatively) complex, one could reasonably expect to see
+If `Derp` were (relatively) complex, one could reasonably expect to see
 the following directory layout:
 
   phabricator/src/applications/derp/conduit/
···
   phabricator/webroot/rsrc/js/application/derp/
   phabricator/webroot/rsrc/css/application/derp/
 
-These directories under ##phabricator/src/applications/derp/## represent
+These directories under `phabricator/src/applications/derp/` represent
 the basic set of class types from which most Phabrictor applications are
-assembled. Each would contain a class file. For ##Derp##, these classes could be
+assembled. Each would contain a class file. For `Derp`, these classes could be
 something like:
 
- - **DerpConstants**: constants used in the ##Derp## application.
+ - **DerpConstants**: constants used in the `Derp` application.
  - **DerpController**: business logic providing functionality for a given
    URI. Typically, controllers load data via Storage or Query classes, then
    present the data to the user via one or more View classes.
  - **DerpEditor**:  business logic for workflows that change one or more
    Storage objects. Editor classes are only necessary for particularly
    complicated edits and should be used pragmatically versus Storage objects.
- - **DerpException**: exceptions used in the ##Derp## application.
- - **DerpQuery**: query one or more storage objects for pertinent ##Derp##
+ - **DerpException**: exceptions used in the `Derp` application.
+ - **DerpQuery**: query one or more storage objects for pertinent `Derp`
    application data. @{class:PhabricatorOffsetPagedQuery} is particularly
    handy for pagination and works well with @{class:AphrontPagerView}.
  - **DerpReplyHandler**: business logic from any configured email interactions
-   users can have with the ##Derp## application.
- - **DerpStorage**: storage objects for the ##Derp## application. Typically
+   users can have with the `Derp` application.
+ - **DerpStorage**: storage objects for the `Derp` application. Typically
    there is a base class which extends @{class:PhabricatorLiskDAO} to configure
    application-wide storage settings like the application (thus database) name.
    Reading more about the @{class:LiskDAO} is highly recommended.
- - **DerpView**: view objects for the ##Derp## application. Typically these
+ - **DerpView**: view objects for the `Derp` application. Typically these
    extend @{class:AphrontView}.
- - **DerpConduitAPIMethod**: provides any and all ##Derp## application
+ - **DerpConduitAPIMethod**: provides any and all `Derp` application
    functionality that is accessible over Conduit.
 
-However, it is likely that ##Derp## is even more complex, and rather than
+However, it is likely that `Derp` is even more complex, and rather than
 containing one class, each directory has several classes. A typical example
 happens around the CRUD of an object:
 
  - **DerpBaseController**: typically extends @{class:PhabricatorController},
-   implements ##buildStandardPageResponse## with the ##Derp## application name
-   and other ##Derp##-specific meta-data, and contains any controller-specific
-   functionality used throughout the ##Derp## application.
- - **DerpDeleteController**: typically extends ##DerpBaseController## and
-   presents a confirmation dialogue to the user about deleting a ##Derp##.
- - **DerpEditController**: typically extends ##DerpBaseController## and
-   presents a form to create and edit ##Derps##. Most likely uses
-   @{class:AphrontFormView} and various ##AphrontFormXControl## classes such as
+   implements `buildStandardPageResponse` with the `Derp` application name
+   and other `Derp`-specific meta-data, and contains any controller-specific
+   functionality used throughout the `Derp` application.
+ - **DerpDeleteController**: typically extends `DerpBaseController` and
+   presents a confirmation dialogue to the user about deleting a `Derp`.
+ - **DerpEditController**: typically extends `DerpBaseController` and
+   presents a form to create and edit `Derps`. Most likely uses
+   @{class:AphrontFormView} and various `AphrontFormXControl` classes such as
    @{class:AphrontFormTextControl} to create the form.
- - **DerpListController**: typically extends ##DerpBaseController## and displays
-   a set of one or more ##Derps##. Might use @{class:AphrontTableView} to create
-   a table of ##Derps##.
- - **DerpViewController**: typically extends ##DerpBaseController## and displays
-   a single ##Derp##.
+ - **DerpListController**: typically extends `DerpBaseController` and displays
+   a set of one or more `Derps`. Might use @{class:AphrontTableView} to create
+   a table of `Derps`.
+ - **DerpViewController**: typically extends `DerpBaseController` and displays
+   a single `Derp`.
 
-Some especially awesome directories might have a ##__tests__## subdirectory
+Some especially awesome directories might have a `__tests__` subdirectory
 containing all pertinent unit test code for the class.
 
 = Next Steps =

src/docs/contributor/php_coding_standards.diviner

···
 
   - Use two spaces for indentation. Don't use tab literal characters.
   - Use Unix linebreaks ("\n"), not MSDOS ("\r\n") or OS9 ("\r").
-  - Put a space after control keywords like ##if## and ##for##.
+  - Put a space after control keywords like `if` and `for`.
   - Put a space after commas in argument lists.
-  - Put a space around operators like ##=##, ##<##, etc.
+  - Put a space around operators like `=`, `<`, etc.
   - Don't put spaces after function names.
   - Parentheses should hug their contents.
   - Generally, prefer to wrap code at 80 columns.
 
 = Case and Capitalization =
 
-  - Name variables and functions using ##lowercase_with_underscores##.
-  - Name classes using ##UpperCamelCase##.
-  - Name methods and properties using ##lowerCamelCase##.
+  - Name variables and functions using `lowercase_with_underscores`.
+  - Name classes using `UpperCamelCase`.
+  - Name methods and properties using `lowerCamelCase`.
   - Use uppercase for common acronyms like ID and HTML.
-  - Name constants using ##UPPERCASE##.
-  - Write ##true##, ##false## and ##null## in lowercase.
+  - Name constants using `UPPERCASE`.
+  - Write `true`, `false` and `null` in lowercase.
 
 = Comments =
 
···
 = PHP Language Style =
 
   - Use "<?php", not the "<?" short form. Omit the closing "?>" tag.
-  - Prefer casts like ##(string)## to casting functions like ##strval()##.
-  - Prefer type checks like ##$v === null## to type functions like
-    ##is_null()##.
+  - Prefer casts like `(string)` to casting functions like `strval()`.
+  - Prefer type checks like `$v === null` to type functions like
+    `is_null()`.
   - Avoid all crazy alternate forms of language constructs like "endwhile"
     and "<>".
   - Always put braces around conditional and loop blocks.

src/docs/contributor/unit_tests.diviner

···
 framework. This document is aimed at project contributors and describes how to
 use it to add and run tests in these projects or other libphutil libraries.
 
-In the general case, you can integrate ##arc## with a custom unit test engine
+In the general case, you can integrate `arc` with a custom unit test engine
 (like PHPUnit or any other unit testing library) to run tests in other projects.
 See @{article:Arcanist User Guide: Customizing Lint, Unit Tests and Workflows}
 for information on customizing engines.
···
 
 To add new tests to a libphutil, Arcanist or Phabricator module:
 
-  - Create a ##__tests__/## directory in the module if it doesn't exist yet.
-  - Add classes to the ##__tests__/## directory which extend from
+  - Create a `__tests__/` directory in the module if it doesn't exist yet.
+  - Add classes to the `__tests__/` directory which extend from
     @{class:PhabricatorTestCase} (in Phabricator) or
     @{class@arcanist:PhutilTestCase} (elsewhere).
-  - Run ##arc liberate## on the library root so your classes are loadable.
+  - Run `arc liberate` on the library root so your classes are loadable.
 
 = Running Tests =
 
 Once you've added test classes, you can run them with:
 
-  - ##arc unit path/to/module/##, to explicitly run module tests.
-  - ##arc unit##, to run tests for all modules affected by changes in the
+  - `arc unit path/to/module/`, to explicitly run module tests.
+  - `arc unit`, to run tests for all modules affected by changes in the
     working copy.
-  - ##arc diff## will also run ##arc unit## for you.
+  - `arc diff` will also run `arc unit` for you.
 
 = Example Test Case =
 
···
     is reasonable.
   - Build a real database simulation layer (fairly complex).
   - Disable isolation for a single test by using
-    ##LiskDAO::endIsolateAllLiskEffectsToCurrentProcess();## before your test
-    and ##LiskDAO::beginIsolateAllLiskEffectsToCurrentProcess();## after your
+    `LiskDAO::endIsolateAllLiskEffectsToCurrentProcess();` before your test
+    and `LiskDAO::beginIsolateAllLiskEffectsToCurrentProcess();` after your
     test. This will disable isolation for one test. NOT RECOMMENDED.
   - Disable isolation for your entire test case by overriding
-    ##getPhabricatorTestCaseConfiguration()## and providing
-    ##self::PHABRICATOR_TESTCONFIG_ISOLATE_LISK => false## in the configuration
+    `getPhabricatorTestCaseConfiguration()` and providing
+    `self::PHABRICATOR_TESTCONFIG_ISOLATE_LISK => false` in the configuration
     dictionary you return. This will disable isolation entirely. STRONGLY NOT
     RECOMMENDED.

src/docs/contributor/using_oauthserver.diviner

···
 
 If the token has expired or is otherwise invalid, the client will receive
 an error indicating as such. In these cases, the client should re-initiate
-the entire ##Authorization Code Grant## flow.
+the entire `Authorization Code Grant` flow.
 
 NOTE: See "Scopes" section below for more information on what data is
 currently exposed through the OAuth Server.

src/docs/flavor/javascript_object_array.diviner

···
 = Primitives =
 
 Javascript has two native datatype primitives, Object and Array. Both are
-classes, so you can use ##new## to instantiate new objects and arrays:
+classes, so you can use `new` to instantiate new objects and arrays:
 
   COUNTEREXAMPLE
   var a = new Array();    //  Not preferred.
···
 
 = Objects are Maps, Arrays are Lists =
 
-PHP has a single ##array## datatype which behaves like as both map and a list,
+PHP has a single `array` datatype which behaves like as both map and a list,
 and a common mistake is to treat Javascript arrays (or objects) in the same way.
 **Don't do this.** It sort of works until it doesn't. Instead, learn how
 Javascript's native datatypes work and use them properly.
···
 
 NOTE: There's some sparse array nonsense being omitted here, see below.
 
-If you try to use ##for (var k in ...)## syntax to iterate over an Array, you'll
+If you try to use `for (var k in ...)` syntax to iterate over an Array, you'll
 pick up a  whole pile of keys you didn't intend to and it won't work. If you try
-to use ##for (var ii = 0; ...)## syntax to iterate over an Object, it won't work
+to use `for (var ii = 0; ...)` syntax to iterate over an Object, it won't work
 at all.
 
 If you consistently treat Arrays as lists and Objects as maps and use the
···
 = hasOwnProperty() =
 
 An issue with this model is that if you write stuff to Object.prototype, it will
-show up every time you use enumeration ##for##:
+show up every time you use enumeration `for`:
 
   COUNTEREXAMPLE
   var o = {};
···
 
 There are two ways to avoid this:
 
-  - test that ##k## exists on ##o## by calling ##o.hasOwnProperty(k)## in every
+  - test that `k` exists on `o` by calling `o.hasOwnProperty(k)` in every
     single loop everywhere in your program and only use libraries which also do
     this and never forget to do it ever; or
   - don't write to Object.prototype.

src/docs/flavor/javascript_pitfalls.diviner

···
 places where insertion of a semicolon would not make the unparseable parseable,
 usually after operators.
 
-= ##with## is Bad News =
+= `with` is Bad News =
 
 `with` is a pretty bad feature, for this reason among others:
 
···
     property = 3; // Might be on object, might be on window: who knows.
   }
 
-Avoid ##with##.
+Avoid `with`.
 
-= ##arguments## is not an Array =
+= `arguments` is not an Array =
 
-You can convert ##arguments## to an array using JX.$A() or similar. Note that
-you can pass  ##arguments## to Function.prototype.apply() without converting it.
+You can convert `arguments` to an array using JX.$A() or similar. Note that
+you can pass  `arguments` to Function.prototype.apply() without converting it.
 
 = Object, Array, and iteration are needlessly hard =
 
···
 Number.prototype, etc.) and their logical behavior is at best absurd and at
 worst strictly wrong.
 
-**Never use** ##new Number()##, ##new String()## or ##new Boolean()## unless
+**Never use** `new Number()`, `new String()` or `new Boolean()` unless
 your Javascript is God Tier and you are absolutely sure you know what you are
 doing.

src/docs/flavor/php_pitfalls.diviner

···
 
 = isset(), empty() and Truthiness =
 
-A value is "truthy" if it evaluates to true in an ##if## clause:
+A value is "truthy" if it evaluates to true in an `if` clause:
 
   $value = something();
   if ($value) {
···
 COMMENT IS TOTALLY AWESOME AND I MAKE IT ALL THE TIME SO YOU HAD BETTER NOT
 BREAK IT!!!// A better test is probably strlen().
 
-In addition to truth tests with ##if##, PHP has two special truthiness operators
+In addition to truth tests with `if`, PHP has two special truthiness operators
 which look like functions but aren't: empty() and isset(). These operators help
 deal with undeclared variables.
 
···
 
 These functions are much slower for even moderately large inputs than
 array_intersect_key() and array_diff_key(), because they can not make the
-assumption that their inputs are unique scalars as the ##key## varieties can.
-Strongly prefer the ##key## varieties.
+assumption that their inputs are unique scalars as the `key` varieties can.
+Strongly prefer the `key` varieties.
 
 = array_uintersect() and array_udiff() are Definitely Slow Too =
 
-These functions have the problems of both the ##usort()## family and the
+These functions have the problems of both the `usort()` family and the
 `array_diff()` family. Avoid them.
 
 = foreach() Does Not Create Scope =
···
   $x = 41;
   call_user_func('add_one', $x);
 
-...##$x## will not be modified. The solution is to use call_user_func_array()
+...`$x` will not be modified. The solution is to use call_user_func_array()
 and wrap the reference in an array:
 
   $x = 41;
···
 
 = Invoking "new" With an Argument Vector is Really Hard =
 
-If you have some ##$class_name## and some ##$argv## of constructor
+If you have some `$class_name` and some `$argv` of constructor
 arguments and you want to do this:
 
   new $class_name($argv[0], $argv[1], ...);

src/docs/flavor/recommendations_on_revision_control.diviner

···
 conceptual changeset ("add a foo widget") is represented in the remote as
 exactly one commit (in some form), not a sequence of checkpoint commits.
 
-  - In SVN, this means don't ##commit## until after an idea has been completely
+  - In SVN, this means don't `commit` until after an idea has been completely
     written. All reasonable SVN workflows naturally enforce this.
-  - In Git, this means squashing checkpoint commits as you go (with ##git commit
-    --amend##) or before pushing (with ##git rebase -i## or ##git merge
-    --squash##), or having a strict policy where your master/trunk contains only
+  - In Git, this means squashing checkpoint commits as you go (with `git commit
+    --amend`) or before pushing (with `git rebase -i` or `git merge
+    --squash`), or having a strict policy where your master/trunk contains only
     merge commits and each is a merge between the old master and a branch which
     represents a single idea. Although this preserves the checkpoint commits
     along the branches, you can view master alone as a series of single-idea

src/docs/flavor/soon_static_resources.diviner

···
 = Caches and Serving Content =
 
 In the simplest implementation of static resources, you write out a raw JS tag
-with something like ##src="/js/base.js"##. This will break disastrously as you
+with something like `src="/js/base.js"`. This will break disastrously as you
 scale, because clients will be running with stale versions of resources. There
 are bunch of subtle problems (especially once you have a CDN), but the big one
 is that if a user is browsing your site as you push/deploy, their client will

src/docs/tech/celerity.diviner

···
 resource for inclusion when a response is rendered (e.g., when the HTML page is
 generated, or when the response to an Ajax request is built). For instance, if
 you use a CSS class like "widget-view", you must ensure the appropriate CSS is
-included by calling ##require_celerity_resource('widget-view-css')## (or
+included by calling `require_celerity_resource('widget-view-css')` (or
 similar), at your use site.
 
 This function uses @{class:CelerityAPI} to access the active
···
 generate fewer resource requests, improving performance). It then generates
 `<script />` and `<link />` references to these resources.
 
-These references point at ##/res/## URIs, which are handled by
+These references point at `/res/` URIs, which are handled by
 @{class:CelerityResourceController}. It responds to these requests and delivers
 the relevant resources and packages, managing cache lifetimes and handling any
 neessary preprocessing. It uses @{class:CelerityResourceMap} to locate resources
 and read packaging rules.
 
-The dependency and packaging maps are generated by ##bin/celerity map##,
-which updates ##resources/celerity/map.php##.
+The dependency and packaging maps are generated by `bin/celerity map`,
+which updates `resources/celerity/map.php`.
 
 @{class:CelerityStaticResourceResponse} also manages some Javelin information,
 and @{function:celerity_generate_unique_node_id} uses this metadata to provide

src/docs/tech/chatbot.diviner

···
 
 These are the configuration values it reads:
 
-  - ##server## String, required, the server to connect to.
-  - ##port## Int, optional, the port to connect to (defaults to 6667).
-  - ##ssl## Bool, optional, whether to connect via SSL or not (defaults to
+  - `server` String, required, the server to connect to.
+  - `port` Int, optional, the port to connect to (defaults to 6667).
+  - `ssl` Bool, optional, whether to connect via SSL or not (defaults to
     false).
-  - ##nick## String, nickname to use.
-  - ##user## String, optional, username to use (defaults to ##nick##).
-  - ##pass## String, optional, password for server.
-  - ##nickpass## String, optional, password for NickServ.
-  - ##join## Array, list of channels to join.
-  - ##handlers## Array, list of handlers to run. These are like plugins for the
+  - `nick` String, nickname to use.
+  - `user` String, optional, username to use (defaults to `nick`).
+  - `pass` String, optional, password for server.
+  - `nickpass` String, optional, password for NickServ.
+  - `join` Array, list of channels to join.
+  - `handlers` Array, list of handlers to run. These are like plugins for the
     bot.
-  - ##conduit.uri##, ##conduit.user##, ##conduit.cert## Conduit configuration,
+  - `conduit.uri`, `conduit.user`, `conduit.cert` Conduit configuration,
     see below.
-  - ##notification.channels## Notification configuration, see below.
+  - `notification.channels` Notification configuration, see below.
 
 = Handlers =
 
···
     up, and says their name with a link to the object. Requires conduit.
   - @{class:PhabricatorBotFeedNotificationHandler} This handler posts
     notifications about changes to revisions to the channels listed in
-    ##notification.channels##.
+    `notification.channels`.
   - @{class:PhabricatorBotLogHandler} This handler records chatlogs which can
     be browsed in the Phabricator web interface.
   - @{class:PhabricatorBotSymbolHandler} This handler posts responses to lookups
     for symbols in Diffusion
   - @{class:PhabricatorBotMacroHandler} This handler looks for users mentioning
     macros, if found will convert image to ASCII and output in chat. Configure
-    with ##macro.size## and ##macro.aspect##
+    with `macro.size` and `macro.aspect`
 
 You can also write your own handlers, by extending
 @{class:PhabricatorBotHandler}.
···
 `People -> Create New Account`. Create a new account and flag them as a
 "Bot/Script". Then in your configuration file, set these parameters:
 
-  - ##conduit.uri## The URI for your Phabricator install, like
-    ##http://phabricator.example.com/##
-  - ##conduit.user## The username your bot should login to Phabricator with --
-    whatever you selected above, like ##phabot##.
-  - ##conduit.cert## The user's certificate, from the "Conduit Certificate" tab
+  - `conduit.uri` The URI for your Phabricator install, like
+    `http://phabricator.example.com/`
+  - `conduit.user` The username your bot should login to Phabricator with --
+    whatever you selected above, like `phabot`.
+  - `conduit.cert` The user's certificate, from the "Conduit Certificate" tab
     in the user's administrative view.
 
 Now the bot should be able to connect to Phabricator via Conduit.
 
 = Starting the Bot =
 
-The bot is a Phabricator daemon, so start it with ##phd##:
+The bot is a Phabricator daemon, so start it with `phd`:
 
   ./bin/phd launch phabricatorbot <absolute_path_to_config_file>
 
-If you have issues you can try ##debug## instead of ##launch##, see
+If you have issues you can try `debug` instead of `launch`, see
 @{article:Managing Daemons with phd} for more information.

src/docs/tech/conduit.diviner

···
 Conduit provides an authenticated HTTP API for Phabricator. It is informal and
 extremely simple: you post a JSON blob and you get a JSON blob back. You can
 access Conduit in PHP with @{class@libphutil:ConduitClient}, or in any language
-by executing ##arc call-conduit method## (see ##arc help call-conduit## for
-more information). You can see and test available methods at ##/conduit/## in
+by executing `arc call-conduit method` (see `arc help call-conduit` for
+more information). You can see and test available methods at `/conduit/` in
 the web interface.
 
 Arcanist is implemented using Conduit, and @{class:PhabricatorBot} is
···
 
 = Class Relationships =
 
-The primary Conduit workflow is exposed at ##/api/##, which routes to
+The primary Conduit workflow is exposed at `/api/`, which routes to
 @{class:PhabricatorConduitAPIController}. This controller builds a
 @{class:ConduitAPIRequest} representing authentication information and POST
 parameters, instantiates an appropriate subclass of @{class:ConduitAPIMethod},
···
 A log of connections and calls is stored by
 @{class:PhabricatorConduitConnectionLog} and
 @{class:PhabricatorConduitMethodCallLog}, and can be accessed on the web via
-@{class:PhabricatorConduitLogController} at ##/conduit/log/##.
+@{class:PhabricatorConduitLogController} at `/conduit/log/`.
 
 Conduit provides a token-based handshake mechanism used by
 `arc install-certificate` at `/conduit/token/`, implemented by

src/docs/user/configuration/configuration_guide.diviner

···
 down to their sections.
 
 Get Apache running and verify it's serving a test page. Consult the Apache
-documentation for help. Make sure ##mod_php## and ##mod_rewrite## are enabled,
-and ##mod_ssl## if you intend to set up SSL.
+documentation for help. Make sure `mod_php` and `mod_rewrite` are enabled,
+and `mod_ssl` if you intend to set up SSL.
 
 If you haven't already, set up a domain name to point to the host you're
 installing on. You can either install Phabricator on a subdomain (like
···
 
   phabricator/ $ ./bin/storage upgrade --user <user> --password <password>
 
-You can avoid the prompt the script issues by passing the ##--force## flag (for
+You can avoid the prompt the script issues by passing the `--force` flag (for
 example, if you are scripting the upgrade process).
 
   phabricator/ $ ./bin/storage upgrade --force

src/docs/user/configuration/configuring_outbound_email.diviner

···
     default. If your domain is `example.org`, set this to something like
     `[e-mail]`.
   - **metamta.domain** should be set to your domain, e.g. `example.org`.
-  - **metamta.can-send-as-user** should be left as ##false## in most cases,
+  - **metamta.can-send-as-user** should be left as `false` in most cases,
     but see the documentation for details.
 
 = Configuring Mail Adapters =
···
 To choose how mail will be sent, change the `metamta.mail-adapter` key in
 your configuration. Possible values are listed in the UI:
 
-  - ##PhabricatorMailImplementationAmazonMailgunAdapter##: use Mailgun, see
+  - `PhabricatorMailImplementationAmazonMailgunAdapter`: use Mailgun, see
     "Adapter: Mailgun".
-  - ##PhabricatorMailImplementationAmazonSESAdapter##: use Amazon SES, see
+  - `PhabricatorMailImplementationAmazonSESAdapter`: use Amazon SES, see
     "Adapter: Amazon SES".
-  - ##PhabricatorMailImplementationPHPMailerLiteAdapter##: default, uses
+  - `PhabricatorMailImplementationPHPMailerLiteAdapter`: default, uses
     "sendmail", see "Adapter: Sendmail".
-  - ##PhabricatorMailImplementationPHPMailerAdapter##: uses SMTP, see
+  - `PhabricatorMailImplementationPHPMailerAdapter`: uses SMTP, see
     "Adapter: SMTP".
-  - ##PhabricatorMailImplementationSendGridAdapter##: use SendGrid, see
+  - `PhabricatorMailImplementationSendGridAdapter`: use SendGrid, see
     "Adapter: SendGrid".
-  - ##Some Custom Class You Write##: use a custom adapter you write, see
+  - `Some Custom Class You Write`: use a custom adapter you write, see
     "Adapter: Custom".
-  - ##PhabricatorMailImplementationTestAdapter##: this will
+  - `PhabricatorMailImplementationTestAdapter`: this will
     **completely disable** outbound mail. You can use this if you don't want to
     send outbound mail, or want to skip this step for now and configure it
     later.
···
   - **amazon-ses.secret-key**: set to your Amazon SES secret key.
 
 NOTE: Amazon SES **requires you to verify your "From" address**. Configure which
-"From" address to use by setting "##metamta.default-address##" in your config,
+"From" address to use by setting "`metamta.default-address`" in your config,
 then follow the Amazon SES verification process to verify it. You won't be able
 to send email until you do this!
 
···
 <http://sendgrid.com/>. It is easy to configure, but not free.
 
 You can configure SendGrid in two ways: you can send via SMTP or via the REST
-API. To use SMTP, just configure ##sendmail## and leave Phabricator's setup
+API. To use SMTP, just configure `sendmail` and leave Phabricator's setup
 with defaults. To use the REST API, follow the instructions in this section.
 
 To configure Phabricator to use SendGrid, set these configuration keys:
···
 
 Run `bin/mail help <command>` for more help on using these commands.
 
-You can monitor daemons using the Daemon Console (##/daemon/##, or click
+You can monitor daemons using the Daemon Console (`/daemon/`, or click
 **Daemon Console** from the homepage).
 
 = Next Steps =

src/docs/user/configuration/managing_daemons.diviner

···
 @title Managing Daemons with phd
 @group config
 
-Explains Phabricator daemons and the daemon control program ##phd##.
+Explains Phabricator daemons and the daemon control program `phd`.
 
 = Overview =
 
···
 
 = phd =
 
-**phd** is a command-line script (located at ##phabricator/bin/phd##). To get
-a list of commands, run ##phd help##:
+**phd** is a command-line script (located at `phabricator/bin/phd`). To get
+a list of commands, run `phd help`:
 
   phabricator/ $ ./bin/phd help
   NAME
···
 = Daemon Console =
 
 You can view status and debugging information for daemons in the Daemon Console
-via the web interface. Go to ##/daemon/## in your install or click
+via the web interface. Go to `/daemon/` in your install or click
 **Daemon Console** from "More Stuff".
 
 The Daemon Console shows a list of all the daemons that have ever launched, and

src/docs/user/userguide/arcanist.diviner

···
 unit tests, and manages common workflows like getting changes into Differential
 for review.
 
-A detailed command reference is available by running ##arc help##. This
+A detailed command reference is available by running `arc help`. This
 document provides an overview of common workflows and installation.
 
 Arcanist has technical, contributor-focused documentation here:
···
 
 Arcanist allows you to do things like:
 
-  - get detailed help about available commands with ##arc help##
-  - send your code to Differential for review with ##arc diff## (for detailed
+  - get detailed help about available commands with `arc help`
+  - send your code to Differential for review with `arc diff` (for detailed
     instructions, see @{article:Arcanist User Guide: arc diff})
-  - show pending revision information with ##arc list##
-  - find likely reviewers for a change with ##arc cover##
-  - apply changes in a revision to the working copy with ##arc patch##
-  - download a patch from Differential with ##arc export##
-  - update Git commit messages after review with ##arc amend##
-  - commit SVN changes with ##arc commit##
-  - push Git and Mercurial changes with ##arc land##
-  - view enhanced information about Git branches with ##arc branch##
+  - show pending revision information with `arc list`
+  - find likely reviewers for a change with `arc cover`
+  - apply changes in a revision to the working copy with `arc patch`
+  - download a patch from Differential with `arc export`
+  - update Git commit messages after review with `arc amend`
+  - commit SVN changes with `arc commit`
+  - push Git and Mercurial changes with `arc land`
+  - view enhanced information about Git branches with `arc branch`
 
 Once you've configured lint and unit test integration, you can also:
 
-  - check your code for syntax and style errors with ##arc lint##
+  - check your code for syntax and style errors with `arc lint`
     (see @{article:Arcanist User Guide: Lint})
-  - run unit tests that cover your changes with ##arc unit##
+  - run unit tests that cover your changes with `arc unit`
 
 Arcanist integrates with other tools:
 
-  - upload and download files with ##arc upload## and ##arc download##
-  - create and view pastes with ##arc paste##
+  - upload and download files with `arc upload` and `arc download`
+  - create and view pastes with `arc paste`
 
 Arcanist has some advanced features as well, you can:
 
-  - execute Conduit method calls with ##arc call-conduit##
-  - create or update libphutil libraries with ##arc liberate##
-  - activate tab completion with ##arc shell-complete##
+  - execute Conduit method calls with `arc call-conduit`
+  - create or update libphutil libraries with `arc liberate`
+  - activate tab completion with `arc shell-complete`
   - ...or extend Arcanist and add new commands.
 
 Except where otherwise noted, these workflows are generally agnostic to the
···
     arcanist/           # Arcanist-specific code and libraries.
     libphutil/          # A shared library Arcanist depends upon.
 
-Now add ##some_install_path/arcanist/bin/## to your PATH environment variable.
+Now add `some_install_path/arcanist/bin/` to your PATH environment variable.
 When you type "arc", you should see something like this:
 
   Usage Exception: No command provided. Try 'arc help'.
···
 
 == Installing Tab Completion ==
 
-If you use ##bash##, you can set up tab completion by adding something like this
-to your ##.bashrc##, ##.profile## or similar:
+If you use `bash`, you can set up tab completion by adding something like this
+to your `.bashrc`, `.profile` or similar:
 
   source /path/to/arcanist/resources/shell/bash-completion
 

src/docs/user/userguide/arcanist_coverage.diviner

···
   arc unit --detailed-coverage src/some/file.php
 
 Depending on how your test engine is configured, this will run tests relevant
-to ##src/some/file.php## and give you a detailed coverage report.
+to `src/some/file.php` and give you a detailed coverage report.
 
 If the test engine enables coverage by default, it will be uploaded to
 Differential and displayed in the right gutter when viewing diffs.
···
 
 = Building Coverage Support =
 
-To add coverage support to a unit test engine, just call ##setCoverage()## when
+To add coverage support to a unit test engine, just call `setCoverage()` when
 building @{class@arcanist:ArcanistUnitTestResult} objects. Provide a map of
 file names (relative to the working copy root) to coverage report strings.
 Coverage report strings look like this:

src/docs/user/userguide/arcanist_extending_lint.diviner

···
 
 By default, most linters raise lint messages as errors. You may want to reduce
 the severity of some messages (e.g., reduce errors to warnings). Do this by
-calling ##setCustomSeverityMap()##:
+calling `setCustomSeverityMap()`:
 
   $linter = new ArcanistTextLinter();
 
···
 
 = Disabling Rules =
 
-To disable rules entirely, set their severities to ##SEVERITY_DISABLED##:
+To disable rules entirely, set their severities to `SEVERITY_DISABLED`:
 
   $linter = new ArcanistTextLinter();
 
···
 
 == ArcanistTextLinter ==
 
-  - Use ##setMaxLineLength()## to change the 80-column warning to something
+  - Use `setMaxLineLength()` to change the 80-column warning to something
     else.
 
 == ArcanistXHPASTLinter ==
 
-  - Use ##lint.xhpast.naminghook## in ##.arcconfig## to override naming
+  - Use `lint.xhpast.naminghook` in `.arcconfig` to override naming
     convention rules. See @{class@arcanist:ArcanistXHPASTLintNamingHook}
     for details.
-  - Use ##getXHPASTTreeForPath()## to reuse the AAST in other linters.
+  - Use `getXHPASTTreeForPath()` to reuse the AAST in other linters.

src/docs/user/userguide/arcanist_lint_unit.diviner

···
 make this work, you need to do three things:
 
   - actually write the class;
-  - add the library where the class exists to your ##.arcconfig##;
-  - add the class name to your ##.arcconfig## as the **lint.engine**,
+  - add the library where the class exists to your `.arcconfig`;
+  - add the class name to your `.arcconfig` as the **lint.engine**,
     **unit.engine**, or **arcanist_configuration**.
 
 = Create a libphutil Library =
···
 If you haven't created a library for the class to live in yet, you need to do
 that first. Follow the instructions in
 @{article:libphutil Libraries User Guide}, then make the library loadable by
-adding it to your ##.arcconfig## like this:
+adding it to your `.arcconfig` like this:
 
   {
     // ...
···
   }
 
 You can either specify an absolute path, or a path relative to the project root.
-When you run ##arc list --trace##, you should see a message to the effect that
+When you run `arc list --trace`, you should see a message to the effect that
 it has loaded your library.
 
 For debugging or testing, you can also run Arcanist with the
···
 
 = Use the Class =
 
-This step is easy: just edit ##.arcconfig## to specify your class name as
+This step is easy: just edit `.arcconfig` to specify your class name as
 the appropriate configuration value.
 
   {
···
 Now, when you run Arcanist in your project, it will invoke your class when
 appropriate.
 
-For lint and unit tests, you can also use the ##--engine## flag override the
+For lint and unit tests, you can also use the `--engine` flag override the
 default engine:
 
   arc lint --engine MyCustomArcanistLintEngine

src/docs/user/userguide/arcanist_new_project.diviner

···
 == History Mutability: Git ==
 
 In a workflow with //mutable// history, you rewrite local history. You develop
-in feature branches, but squash or amend before pushing by using ##git commit
---amend##, ##git rebase -i##, or `git merge --squash`. Generally, one idea in
+in feature branches, but squash or amend before pushing by using `git commit
+--amend`, `git rebase -i`, or `git merge --squash`. Generally, one idea in
 the remote is represented by one commit.
 
 In a workflow with //immutable// history, you do not rewrite local history. You
 develop in feature branches and push them without squashing commits. You do not
-use ##git commit --amend## or ##git rebase -i##. Generally, one idea in the
+use `git commit --amend` or `git rebase -i`. Generally, one idea in the
 remote is represented by many commits.
 
 Practically, these are the differences you'll see based on your setting:

src/docs/user/userguide/differential_test_plans.diviner

···
   - **Concurrent Change Robustness:** If you're making a refactoring change, is
     it robust against people introducing new calls between the time you started
     the change and when you commit it? For example, if you change the parameter
-    order of some function from ##f(a, b)## to ##f(b, a)## and a new callsite is
+    order of some function from `f(a, b)` to `f(b, a)` and a new callsite is
     introduced in the meantime, could it go unnoticed? How bad would that be?
     (Because of this risk, you should almost never make parameter order
     changes in weakly typed languages like PHP and Javascript.)

src/docs/user/userguide/diffusion_symbols.diviner

···
   ./scripts/symbols/generate_ctags_symbols.php
 
 If you want to identify symbols from another language, you need to write a
-script which can export them (for example, maybe by parsing a ##ctags## file).
+script which can export them (for example, maybe by parsing a `ctags` file).
 
 The output format of the script should be one symbol per line:
 
···
 defined. For object-oriented languages, this is probably a class name. The
 symbols with that context are class constants, methods, properties, nested
 classes, etc. When printing symbols without a context (those that are defined
-globally, for instance), the ##<context>## field should be empty (that is, the
+globally, for instance), the `<context>` field should be empty (that is, the
 line should start with a space).
 
 Your script should enumerate all the symbols in your project, and provide paths
 from the project root (where ".arcconfig" is) beginning with a "/".
 
-You can look at ##generate_php_symbols.php## for an example of how you might
+You can look at `generate_php_symbols.php` for an example of how you might
 write such a script, and run this command to see its output:
 
   $ cd phabricator/
···
 Then just set up a cronjob to run that however often you like.
 
 You can test that the import worked by querying for symbols using the Conduit
-method ##diffusion.findsymbols##. Some features (like that method, and the
+method `diffusion.findsymbols`. Some features (like that method, and the
 IRC bot integration) will start working immediately. Others will require more
 configuration.
 

src/docs/user/userguide/events.diviner

···
 This event is dispatched before a task is edited, and allows you to respond to
 or alter the edit. Data available on this event:
 
-  - ##task## The @{class:ManiphestTask} being edited.
-  - ##transactions## The list of edits (objects of class
+  - `task` The @{class:ManiphestTask} being edited.
+  - `transactions` The list of edits (objects of class
     @{class:ManiphestTransaction}) being applied.
-  - ##new## A boolean indicating if this task is being created.
-  - ##mail## If this edit originates from email, the
+  - `new` A boolean indicating if this task is being created.
+  - `mail` If this edit originates from email, the
     @{class:PhabricatorMetaMTAReceivedMail} object.
 
 This is similar to the next event (did edit task) but occurs before the edit
···
 This event is dispatched after a task is edited, and allows you to react to the
 edit. Data available on this event:
 
-  - ##task## The @{class:ManiphestTask} that was edited.
-  - ##transactions## The list of edits (objects of class
+  - `task` The @{class:ManiphestTask} that was edited.
+  - `transactions` The list of edits (objects of class
     @{class:ManiphestTransaction}) that were applied.
-  - ##new## A boolean indicating if this task was newly created.
-  - ##mail## If this edit originates from email, the
+  - `new` A boolean indicating if this task was newly created.
+  - `mail` If this edit originates from email, the
     @{class:PhabricatorMetaMTAReceivedMail} object.
 
 This is similar to the previous event (will edit task) but occurs after the
···
 This event is dispatched before Differential decides if a file is generated (and
 doesn't need to be reviewed) or not. Data available on this event:
 
-  - ##corpus## Body of the file.
-  - ##is_generated## Boolean indicating if this file should be treated as
+  - `corpus` Body of the file.
+  - `is_generated` Boolean indicating if this file should be treated as
     generated.
 
 == Diffusion: Did Discover Commit ==

src/docs/user/userguide/external_editor.diviner

···
 
 == Configuring: TextMate on OS X ==
 
-TextMate installs a ##txmt://## handler by default, so it's easy to configure
+TextMate installs a `txmt://` handler by default, so it's easy to configure
 this feature if you use TextMate.
 
 First, create a local directory with symlinks for each repository callsign. For

src/docs/user/userguide/herald.diviner

···
 
 To create a new Herald rule, choose which type of event you want to act on
 (e.g., changes to Differential Revisions, or Commits), and then set a list of
-conditions. For example, you might add the condition ##Author is alincoln
-(Abraham Lincoln)## to keep track of everything alincoln does. Finally, set
+conditions. For example, you might add the condition `Author is alincoln
+(Abraham Lincoln)` to keep track of everything alincoln does. Finally, set
 a list of actions to take when the conditions match, like adding yourself to the
 CC list.
 
···
   filename of the changed file; the second will be used to match the content.
   For example, if you want to match revisions which add or remove calls to
   a "muffinize" function, //but only in JS files//, you can set the value
-  to ##["/\\.js$/", "/muffinize/"]## or similar.
+  to `["/\\.js$/", "/muffinize/"]` or similar.
   - **Another Herald rule**: you can create Herald rules which depend on other
   rules. This can be useful if you need to express a more complicated predicate
   than "all" vs "any" allows, or have a common set of conditions which you want

src/docs/user/userguide/libraries.diviner

···
 In general, you perform these one-time setup steps:
 
   - Create a new directory.
-  - Use ##arc liberate## to initialize and name the library.
+  - Use `arc liberate` to initialize and name the library.
   - Add a dependency on Phabricator if necessary.
-  - Add the library to your Phabricator config or ##.arcconfig## so it will be
+  - Add the library to your Phabricator config or `.arcconfig` so it will be
     loaded at runtime.
 
 Then, to add new code, you do this:
 
   - Write or update classes.
-  - Update the library metadata by running ##arc liberate## again.
+  - Update the library metadata by running `arc liberate` again.
 
 = Creating a New Library =
 
···
 
 This will write three files:
 
-  - ##src/.phutil_module_cache## This is a cache which makes "arc liberate"
+  - `src/.phutil_module_cache` This is a cache which makes "arc liberate"
     faster when you run it to update the library. You can safely remove it at
     any time. If you check your library into version control, you can add this
     file to ignore rules (like .gitignore).
-  - ##src/__phutil_library_init__.php## This records the name of the library and
+  - `src/__phutil_library_init__.php` This records the name of the library and
     tells libphutil that a library exists here.
-  - ##src/__phutil_library_map__.php## This is a map of all the symbols
+  - `src/__phutil_library_map__.php` This is a map of all the symbols
     (functions and classes) in the library, which allows them to be autoloaded
     at runtime and dependencies to be statically managed by "arc liberate".
 
···
 step.
 
 But, if you intend to use this library with Phabricator, you need to define its
-dependency on Phabricator by creating a ##.arcconfig## file which points at
+dependency on Phabricator by creating a `.arcconfig` file which points at
 Phabricator. For example, you might write this file to
 `libcustom/.arcconfig`:
 
···
     ]
   }
 
-For details on creating a ##.arcconfig##, see
+For details on creating a `.arcconfig`, see
 @{article:Arcanist User Guide: Configuring a New Project}. In general, this
-tells ##arc liberate## that it should look for symbols in Phabricator when
+tells `arc liberate` that it should look for symbols in Phabricator when
 performing static analysis.
 
 NOTE: If Phabricator isn't located next to your custom library, specify a
-path which actually points to the ##phabricator/## directory.
+path which actually points to the `phabricator/` directory.
 
-You do not need to declare dependencies on ##arcanist## or ##libphutil##,
-since ##arc liberate## automatically loads them.
+You do not need to declare dependencies on `arcanist` or `libphutil`,
+since `arc liberate` automatically loads them.
 
 Finally, edit your Phabricator config to tell it to load your library at
-runtime, by adding it to ##load-libraries##:
+runtime, by adding it to `load-libraries`:
 
   ...
   'load-libraries' => array(
···
   libcustom/ $ mkdir src/example/
   libcustom/ $ nano src/example/ExampleClass.php # Edit some code.
 
-Now, run ##arc liberate## to regenerate the static resource map:
+Now, run `arc liberate` to regenerate the static resource map:
 
   libcustom/ $ arc liberate src/
 
···
 = What You Can Extend And Invoke =
 
 libphutil, Arcanist and Phabricator are strict about extensibility of classes
-and visibility of methods and properties. Most classes are marked ##final##, and
+and visibility of methods and properties. Most classes are marked `final`, and
 methods have the minimum required visibility (protected or private). The goal of
 this strictness is to make it clear what you can safely extend, access, and
 invoke, so your code will keep working as the upstream changes.
···
 example: @{class@libphutil:AbstractDirectedGraph}). These classes are external
 interfaces intended for extension.
 
-If you want to extend a class but it is not marked ##@stable##, here are some
+If you want to extend a class but it is not marked `@stable`, here are some
 approaches you can take:
 
   - Good: If possible, use composition rather than extension to build your

src/docs/user/userguide/mail_rules.diviner

···
 Phabricator sends a variety of mail headers that can be useful in crafting rules
 to route and manage mail.
 
-Headers in plural contain lists. A list containing two items, ##1## and
+Headers in plural contain lists. A list containing two items, `1` and
 `15` will generally be formatted like this:
 
   X-Header: <1>, <15>
···
 
 The headers Phabricator adds to mail are:
 
-  - ##X-Phabricator-Sent-This-Message##: this is attached to all mail
+  - `X-Phabricator-Sent-This-Message`: this is attached to all mail
     Phabricator sends. You can use it to differentiate between email from
     Phabricator and replies/forwards of Phabricator mail from human beings.
-  - ##X-Phabricator-To##: this is attached to all mail Phabricator sends.
+  - `X-Phabricator-To`: this is attached to all mail Phabricator sends.
     It shows the PHIDs of the original "To" line, before any mutation
     by the mailer configuration.
-  - ##X-Phabricator-Cc##: this is attached to all mail Phabricator sends.
+  - `X-Phabricator-Cc`: this is attached to all mail Phabricator sends.
     It shows the PHIDs of the original "Cc" line, before any mutation by the
     mailer configuration.
-  - ##X-Differential-Author##: this is attached to Differential mail and shows
+  - `X-Differential-Author`: this is attached to Differential mail and shows
     the revision's author. You can use it to filter mail about your revisions
     (or other users' revisions).
-  - ##X-Differential-Reviewer##: this is attached to Differential mail and
+  - `X-Differential-Reviewer`: this is attached to Differential mail and
     shows the reviewers. You can use it to filter mail about revisions you
     are reviewing, versus revisions you are explicitly CC'd on or CC'd as
     a result of Herald rules.
-  - ##X-Differential-Reviewers##: list version of the previous.
-  - ##X-Differential-CC##: this is attached to Differential mail and shows
+  - `X-Differential-Reviewers`: list version of the previous.
+  - `X-Differential-CC`: this is attached to Differential mail and shows
     the CCs on the revision.
-  - ##X-Differential-CCs##: list version of the previous.
-  - ##X-Differential-Explicit-CC##: this is attached to Differential mail and
+  - `X-Differential-CCs`: list version of the previous.
+  - `X-Differential-Explicit-CC`: this is attached to Differential mail and
     shows the explicit CCs on the revision (those that were added by humans,
     not by Herald).
-  - ##X-Differential-Explicit-CCs##: list version of the previous.
-  - ##X-Phabricator-Mail-Tags##: this is attached to some mail and has
+  - `X-Differential-Explicit-CCs`: list version of the previous.
+  - `X-Phabricator-Mail-Tags`: this is attached to some mail and has
     a list of descriptors about the mail. (This is fairly new and subject
     to some change.)
-  - ##X-Herald-Rules##: this is attached to some mail and shows Herald rule
+  - `X-Herald-Rules`: this is attached to some mail and shows Herald rule
     IDs which have triggered for the object. You can use this to sort or
     categorize mail that has triggered specific rules.

src/docs/user/userguide/utf8.diviner

···
 
 If you have a prohibitively large number of UTF-8 issues in your source code,
 Phabricator doesn't include any default tools to help you process them in a
-systematic way. You could hack up ##utf8.php## as a starting point, or use other
+systematic way. You could hack up `utf8.php` as a starting point, or use other
 tools to batch-process your source files.
 
 = Support for Alternate Encodings =

webroot/rsrc/externals/javelin/docs/concepts/behaviors.diviner

···
 
 The function will be invoked once for each configuration dictionary passed to
 @{function:JX.initBehaviors}, and the dictionary will be passed as the
-##config## parameter. For example, to alert the user that they've won two hogs:
+`config` parameter. For example, to alert the user that they've won two hogs:
 
   lang=js
   JX.initBehaviors({
     "win-a-hog" : [{hogName : "Ethel"}, {hogName: "Beatrice"}]
   });
 
-This will invoke the function twice, once for each ##config## dictionary.
+This will invoke the function twice, once for each `config` dictionary.
 Usually, you invoke a behavior multiple times if you have several similar
 controls on a page, like multiple @{class:JX.Tokenizer}s.
 
-An initially empty object will be passed in the ##statics## parameter, but
+An initially empty object will be passed in the `statics` parameter, but
 changes to this object will persist across invocations of the behavior. For
 example:
 
···
 By 2010 (particularly with the introduction of XHP) the API had become more
 sophisticated, but this is basically how most of Facebook's glue code still
 works as of mid-2011. If you view the source of any page, you'll see a bunch
-of ##onloadRegister()## calls in the markup which are generated like this.
+of `onloadRegister()` calls in the markup which are generated like this.
 
 This mitigates many of the problems but is still fairly awkward. Escaping is
 easier, but still possible to get wrong. Stuff is a bit easier to grep for, but
···
   - The entire interface the server may invoke against can be readily inferred.
 
 Note that Javelin does provide @{function:JX.onload}, which behaves like
-##onloadRegister()##. However, its use is discouraged.
+`onloadRegister()`. However, its use is discouraged.
 
 The two major downsides to the behavior design appear to be:
 

webroot/rsrc/externals/javelin/docs/concepts/event_delegation.diviner

···
       // ...
     });
 
-This is similar to setting ##node.onclick## or ##node.addEventListener##, but
+This is similar to setting `node.onclick` or `node.addEventListener`, but
 uses the Javelin delegation core. You can also provide a sigil set, which works
 just like @{method:JX.Stratcom.listen} general events. This is useful if your
-node is a container, like a ##<div />##, with a lot of stuff in it.
+node is a container, like a `<div />`, with a lot of stuff in it.
 
 
 = DOM Event Flow =
···
 = Listening to Class Events =
 
 Beyond DOM events, you can also listen to class events. Every class installed
-by Javelin has static and instance methods called ##listen## (see
+by Javelin has static and instance methods called `listen` (see
 @{method:JX.Base.listen}). The static method allows you to listen for all events
 emitted by every instance of a class and its descendants:
 
···
 Javelin implements general delegation by building and comparing sigil sets. Some
 of these sigils are not DOM sigils, but derived from other things:
 
-  - ##id:*## ID sigils are generated when an examined node has an "id" property.
-  - ##obj:*## Object sigils are generated when an event affects a class
+  - `id:*` ID sigils are generated when an examined node has an "id" property.
+  - `obj:*` Object sigils are generated when an event affects a class
     instance.
-  - ##class:*## Class sigils are generated while walking an affected instance's
+  - `class:*` Class sigils are generated while walking an affected instance's
     class chain.
-  - ##tag:*## Tag sigils are generated by examining the tag names of DOM nodes.
+  - `tag:*` Tag sigils are generated by examining the tag names of DOM nodes.
 
-For instance, you can listen to all clicks on ##<a />## tags in a document like
+For instance, you can listen to all clicks on `<a />` tags in a document like
 this:
 
   lang=js

webroot/rsrc/externals/javelin/docs/concepts/sigils_metadata.diviner

···
 It is reasonable to think of sigils as being CSS class names in a different,
 semantic namespace.
 
-If you're emitting raw tags, you specify sigils by adding a ##data-sigil##
+If you're emitting raw tags, you specify sigils by adding a `data-sigil`
 attribute to a node:
 
   lang=html
···
 you need to be able to distinguish between the different links so you can know
 which story the user is trying to like. Javelin allows you to do this by
 attaching **metadata** to each node. Metadata is attached to a node by adding a
-##data-meta## attribute which has an index into data later provided to
+`data-meta` attribute which has an index into data later provided to
 @{method:JX.Stratcom.mergeData}:
 
   lang=html

webroot/rsrc/externals/javelin/docs/facebook.diviner

···
 Javelin now ships with the source to build several libfbjs-based binaries, which
 serve to completely sever its dependencies on trunk:
 
-  - ##javelinsymbols##: used for lint
-  - ##jsast##: used for documentation generation
-  - ##jsxmin##: used to crush packages
+  - `javelinsymbols`: used for lint
+  - `jsast`: used for documentation generation
+  - `jsxmin`: used to crush packages
 
 To build these, first build libfbjs:
 
···
 
   javelin/ $ ./scripts/sync-from-facebook.php ~/www
 
-...where ##~/www## is the root you want to pull Javelin files from. The script
-will copy files out of ##html/js/javelin## and build packages, and leave the
+...where `~/www` is the root you want to pull Javelin files from. The script
+will copy files out of `html/js/javelin` and build packages, and leave the
 results in your working copy. From there you can review changes and commit, and
 then push, diff, or send a pull request.
 
···
 
   javelin/ $ ./scripts/sync-to-facebook.php ~/www
 
-...where ##~/www## is the root you want to push Javelin files to. The script
-will copy files out of the working copy into your ##www## and leave you with a
-dirty ##www##. From there you can review changes.
+...where `~/www` is the root you want to push Javelin files to. The script
+will copy files out of the working copy into your `www` and leave you with a
+dirty `www`. From there you can review changes.
 
-Once Facebook moves to pure git for ##www## we can probably just submodule
+Once Facebook moves to pure git for `www` we can probably just submodule
 Javelin into it and get rid of all this nonsense, but the mixed SVN/git
 environment makes that difficult until then.
 
 = Building Documentation =
 
-Check out ##diviner## and ##libphutil## from Facebook github, and put them in a
-directory with ##javelin##:
+Check out `diviner` and `libphutil` from Facebook github, and put them in a
+directory with `javelin`:
 
   somewhere/ $ ls
   diviner/
···
   libphutil/
   somewhere/ $
 
-Now run ##diviner## on ##javelin##:
+Now run `diviner` on `javelin`:
 
   somewhere/ $ cd javelin
   somewhere/javelin/ $ ../diviner/bin/diviner .
···
   [JavelinDivinerEngine] Generating documentation for 74 files...
   somewhere/javelin/ $
 
-Documentation is now available in ##javelin/docs/##.
+Documentation is now available in `javelin/docs/`.
 
 = Editing javelinjs.com =
 
-The source for javelinjs.com lives in ##javelin/support/webroot/##. The site
+The source for javelinjs.com lives in `javelin/support/webroot/`. The site
 itself is served off the phabricator.com host. You need access to that host to
 push it.