Use :atom syntax to link erlang modules

Author: sabiwara

lib/elixir/lib/map_set.ex

@@ -43,8 +43,7 @@ defmodule MapSet do
   `MapSet`s can also be constructed starting from other collection-type data
   structures: for example, see `MapSet.new/1` or `Enum.into/2`.
 
-  `MapSet` is built on top of Erlang's
-  [`:sets`](https://www.erlang.org/doc/man/sets.html) (version 2). This means
+  `MapSet` is built on top of Erlang's [`:sets`](`:sets`) (version 2). This means
   that they share many properties, including logarithmic time complexity. Erlang
   `:sets` (version 2) are implemented on top of maps, so see the documentation
   for `Map` for more information on its execution time complexity.

lib/elixir/pages/anti-patterns/process-anti-patterns.md

@@ -227,7 +227,7 @@ This anti-pattern has many potential remedies:
 
   * If the only process that needs data is the one you are sending to, consider making the process fetch that data instead of passing it.
 
-  * Some abstractions, such as [`:persistent_term`](https://www.erlang.org/doc/man/persistent_term.html), allows you to share data between processes, as long as such data changes infrequently.
+  * Some abstractions, such as [`:persistent_term`](`:persistent_term`), allows you to share data between processes, as long as such data changes infrequently.
 
 In our case, limiting the input data is a reasonable strategy. If all we need *right now* is the IP address, then let's only work with that and make sure we're only passing the IP address into the closure, like so:
 

lib/elixir/pages/getting-started/debugging.md

@@ -175,11 +175,11 @@ Finally, remember you can also get a mini-overview of the runtime info by callin
 
 We have just scratched the surface of what the Erlang VM has to offer, for example:
 
-  * Alongside the observer application, Erlang also includes a [`:crashdump_viewer`](https://www.erlang.org/doc/man/crashdump_viewer.html) to view crash dumps
+  * Alongside the observer application, Erlang also includes a [`:crashdump_viewer`](`:crashdump_viewer`) to view crash dumps
 
   * Integration with OS level tracers, such as [Linux Trace Toolkit,](https://www.erlang.org/doc/apps/runtime_tools/lttng) [DTRACE,](https://www.erlang.org/doc/apps/runtime_tools/dtrace) and [SystemTap](https://www.erlang.org/doc/apps/runtime_tools/systemtap)
 
-  * [Microstate accounting](http://www.erlang.org/doc/man/msacc.html) measures how much time the runtime spends in several low-level tasks in a short time interval
+  * [Microstate accounting](`:msacc`) measures how much time the runtime spends in several low-level tasks in a short time interval
 
   * Mix ships with many tasks under the `profile` namespace, such as `mix profile.cprof` and `mix profile.fprof`
 

lib/elixir/pages/mix-and-otp/agents.md

@@ -9,7 +9,7 @@ If you have skipped the *Getting Started* guide or read it long ago, be sure to
 Elixir is an immutable language where nothing is shared by default. If we want to share information, which can be read and modified from multiple places, we have two main options in Elixir:
 
   * Using processes and message passing
-  * [ETS (Erlang Term Storage)](http://www.erlang.org/doc/man/ets.html)
+  * [ETS (Erlang Term Storage)](`:ets`)
 
 We covered processes in the *Getting Started* guide. ETS (Erlang Term Storage) is a new topic that we will explore in later chapters. When it comes to processes though, we rarely hand-roll our own, instead we use the abstractions available in Elixir and OTP:
 

lib/elixir/pages/mix-and-otp/distributed-tasks.md

@@ -86,7 +86,7 @@ From our quick exploration, we could conclude that we should use `Node.spawn_lin
 
 There are three better alternatives to `Node.spawn_link/2` that we could use in our implementation:
 
-1. We could use Erlang's [:erpc](http://www.erlang.org/doc/man/erpc.html) module to execute functions on a remote node. Inside the `bar@computer-name` shell above, you can call `:erpc.call(:"foo@computer-name", Hello, :world, [])` and it will print "hello world"
+1. We could use Erlang's [`:erpc`](`:erpc`) module to execute functions on a remote node. Inside the `bar@computer-name` shell above, you can call `:erpc.call(:"foo@computer-name", Hello, :world, [])` and it will print "hello world"
 
 2. We could have a server running on the other node and send requests to that node via the `GenServer` API. For example, you can call a server on a remote node by using `GenServer.call({name, node}, arg)` or passing the remote process PID as the first argument
 
@@ -347,8 +347,8 @@ Distributed key-value stores, used in real-life, need to consider the fact nodes
 These topics can be daunting at first but remember that most Elixir frameworks abstract those concerns for you. For example, when using [the Phoenix web framework](https://phoenixframework.org), its plug-and-play abstractions take care of sending messages and tracking how users join and leave a cluster. However, if you are interested in distributed systems after all, there is much to explore. Here are some additional references:
 
   * [The excellent Distribunomicon chapter from Learn You Some Erlang](http://learnyousomeerlang.com/distribunomicon)
-  * [Erlang's global module](https://www.erlang.org/doc/man/global.html), which can provide global names and global locks, allowing unique names and unique locks in a whole cluster of machines
-  * [Erlang's pg module](https://www.erlang.org/doc/man/pg.html), which allows process to join different groups shared across the whole cluster
+  * Erlang's [`:global` module](`:global`), which can provide global names and global locks, allowing unique names and unique locks in a whole cluster of machines
+  * Erlang's [`:pg` module](`:pg`), which allows process to join different groups shared across the whole cluster
   * [Phoenix PubSub project](https://github.com/phoenixframework/phoenix_pubsub), which provides a distributed messaging system and a distributed presence system for tracking users and processes in a cluster
 
 You will also find many libraries for building distributed systems within the overall Erlang ecosystem. For now, it is time to go back to our simple distributed key-value store and learn how to configure and package it for production.

lib/elixir/pages/mix-and-otp/erlang-term-storage.md

@@ -8,7 +8,7 @@ In this chapter, we will learn about ETS (Erlang Term Storage) and how to use it
 
 ## ETS as a cache
 
-ETS allows us to store any Elixir term in an in-memory table. Working with ETS tables is done via [Erlang's `:ets` module](http://www.erlang.org/doc/man/ets.html):
+ETS allows us to store any Elixir term in an in-memory table. Working with ETS tables is done via [Erlang's `:ets` module](`:ets`):
 
 ```elixir
 iex> table = :ets.new(:buckets_registry, [:set, :protected])

lib/elixir/pages/mix-and-otp/task-and-gen-tcp.md

@@ -1,6 +1,6 @@
 # Task and gen_tcp
 
-In this chapter, we are going to learn how to use [Erlang's `:gen_tcp` module](http://www.erlang.org/doc/man/gen_tcp.html) to serve requests. This provides a great opportunity to explore Elixir's `Task` module. In future chapters, we will expand our server so that it can actually serve the commands.
+In this chapter, we are going to learn how to use Erlang's [`:gen_tcp` module](`:gen_tcp`) to serve requests. This provides a great opportunity to explore Elixir's `Task` module. In future chapters, we will expand our server so that it can actually serve the commands.
 
 ## Echo server
 

lib/ex_unit/lib/ex_unit.ex

@@ -14,7 +14,7 @@ defmodule ExUnit do
       # 2) Create a new test module and use "ExUnit.Case".
       defmodule AssertionTest do
         # 3) Note that we pass "async: true", this runs the tests in the
-        #    test module concurrently with other test modules. The 
+        #    test module concurrently with other test modules. The
         #    individual tests within each test module are still run serially.
         use ExUnit.Case, async: true
 
@@ -311,7 +311,7 @@ defmodule ExUnit do
 
     * `:rand_algorithm` - algorithm to be used when generating the test seed.
       Available algorithms can be found in Erlang's
-      [`:rand`](https://www.erlang.org/doc/man/rand.html) documentation (see
+      [`:rand`](`:rand`) documentation (see
       [`:rand.builting_arg/0`](https://www.erlang.org/doc/apps/stdlib/rand.html#t:builtin_alg/0)).
       Available since v1.16.0. Before v1.16.0, the algorithm was hard-coded to
       `:exs1024`. On Elixir v1.16.0 and after, the default changed to `:exsss`;

lib/mix/lib/mix/tasks/profile.eprof.ex

@@ -82,7 +82,7 @@ defmodule Mix.Tasks.Profile.Eprof do
   ## Caveats
 
   You should be aware that the code being profiled is running in an anonymous
-  function which is invoked by [`:eprof` module](https://www.erlang.org/doc/man/eprof.html).
+  function which is invoked by [`:eprof` module](`:eprof`).
   Thus, you'll see some additional entries in your profile output. It is also
   important to note that the profiler is stopped as soon as the code has finished running,
   and this may need special attention, when: running asynchronous code as function calls which were

lib/mix/lib/mix/tasks/profile.fprof.ex

@@ -93,7 +93,7 @@ defmodule Mix.Tasks.Profile.Fprof do
   ## Caveats
 
   You should be aware that the code being profiled is running in an anonymous
-  function which is invoked by [`:fprof` module](https://www.erlang.org/doc/man/fprof.html).
+  function which is invoked by [`:fprof` module](`:fprof`).
   Thus, you'll see some additional entries in your profile output,
   such as `:fprof` calls, an anonymous
   function with high ACC time, or an `:undefined` function which represents