Fix type formatting for several files.

(and some very minor textual cleanups)

Author: coke

doc/Programs/03-environment-variables.rakudoc

@@ -143,7 +143,7 @@ X<|Programs,RAKU_REPL_OUTPUT_METHOD>
 This specifies the name of the method that should be called on the result
 value of a statement in the L<REPL|/language/REPL> if the statement did B<not> cause any
 output of its own.  If absent, C<gist> will be assumed.  One can use
-C<raku> to force a more literal, parsable representation.  Or C<Str> to force a
+C<raku> to force a more literal, parsable representation.  Or L<C<Str>|/type/Str> to force a
 complete string representation.  Available as of the 2020.06 release of
 the Rakudo compiler.
 
@@ -195,7 +195,7 @@ X<|Programs,RAKUDO_MAX_THREADS>
 =item C<RAKUDO_MAX_THREADS> (I<UInt>; B<src/core.c/ThreadPoolScheduler.rakumod>)
 
 Indicates the maximum number of threads used by default when creating a
-C<ThreadPoolScheduler>. Defaults to 64 unless there appear to be more than
+L<C<ThreadPoolScheduler>|/type/ThreadPoolScheduler>. Defaults to 64 unless there appear to be more than
 8 CPU cores available: in which case it defaults to 8 * number of cores.
 
 As of release 2022.06 of the Rakudo compiler, it is also possible to
@@ -209,15 +209,15 @@ The C<IO::Spec::Unix.tmpdir> method will return C<$TMPDIR> if it points to a
 directory with full access permissions for the current user, with a fallback
 default of C<'/tmp'>.
 
-C<IO::Spec::Cygwin> and C<IO::Spec::Win32> use more Windows-appropriate lists
+L<C<IO::Spec::Cygwin>|/type/IO::Spec::Cygwin> and L<C<IO::Spec::Win32>|/type/IO::Spec::Win32> use more Windows-appropriate lists
 which also include the C<%TEMP%> and C<%TMP%> environment variables.
 
 X<|Programs,PATH>
 =item C<PATH>, C<Path> (I<Str>; B<src/core.c/IO/Spec/>)
 
 The C<IO::Spec::Unix.path> method splits C<$PATH> as a
-shell would; i.e. as a colon-separated list. C<IO::Spec::Cygwin> inherits this
-from C<IO::Spec::Unix>. C<IO::Spec::Win32.path> will read the first defined of
+shell would; i.e. as a colon-separated list. L<C<IO::Spec::Cygwin>|/type/IO::Spec::Cygwin> inherits this
+from L<C<IO::Spec::Unix>|/type/IO::Spec::Unix>. C<IO::Spec::Win32.path> will read the first defined of
 either C<%PATH%> or C<%Path%> as a semicolon-delimited list.
 
 X<|Programs,RAKUDO_SNAPPER>

doc/Type/Lock.rakudoc

@@ -45,19 +45,19 @@ so a thread that is waiting to acquire a lock is, from the point of view
 of the operating system, blocked.
 
 Code using high-level Raku concurrency constructs should avoid using
-C<Lock>. Waiting to acquire a C<Lock> blocks a real C<Thread>, meaning
+C<Lock>. Waiting to acquire a C<Lock> blocks a real L<C<Thread>|/type/Thread>, meaning
 that the thread pool (used by numerous higher-level Raku concurrency
 mechanisms) cannot use that thread in the meantime for anything else.
 
 Any C<await> performed while a C<Lock> is held will behave in a blocking
 manner; the standard non-blocking behavior of C<await> relies on the
-code following the `await` resuming on a different C<Thread> from the
+code following the `await` resuming on a different L<C<Thread>|/type/Thread> from the
 pool, which is incompatible with the requirement that a C<Lock> be
 unlocked by the same thread that locked it. See
-L<C<Lock::Async>|/type/Lock/Async>
+L<C<Lock::Async>|/type/Lock::Async>
 for an alternative mechanism that does not have this shortcoming. Other than
 that, the main difference is that C<Lock> mainly maps to operating system
-mechanisms, while C<Lock::Async> uses Raku primitives to achieve similar
+mechanisms, while L<C<Lock::Async>|/type/Lock::Async> uses Raku primitives to achieve similar
 effects. If you're doing low-level stuff (native bindings) and/or actually
 want to block real OS threads, use C<Lock>. However, if you want a
 non-blocking mutual exclusion and don't need recursion and are running code
@@ -67,7 +67,7 @@ By their nature, C<Lock>s are not composable, and it is possible to
 end up with hangs should circular dependencies on locks occur. Prefer
 to structure concurrent programs such that they communicate results
 rather than modify shared data structures, using mechanisms like
-L<Promise|/type/Promise>, L<Channel|/type/Channel> and L<Supply|/type/Supply>.
+L<C<Promise>|/type/Promise>, L<C<Channel>|/type/Channel> and L<C<Supply>|/type/Supply>.
 
 
 =head1 Methods
@@ -80,12 +80,12 @@ Obtains the lock, runs C<&code>, and releases the lock afterwards. Care
 is taken to make sure the lock is released even if the code is left through
 an exception.
 
-Note that the L<Lock|/type/Lock> itself needs to be created outside the portion
+Note that the C<Lock> itself needs to be created outside the portion
 of the code that gets threaded and it needs to protect. In the first
-example below, L<Lock|/type/Lock> is first created and assigned to C<$lock>,
-which is then used I<inside> the L<Promises|/type/Promise> to protect
+example below, C<Lock> is first created and assigned to C<$lock>,
+which is then used I<inside> the L<C<Promise>|/type/Promise>s to protect
 the sensitive code. In the second example, a mistake is made: the
-C<Lock> is created right inside the L<Promise|/type/Promise>, so the code ends up
+C<Lock> is created right inside the L<C<Promise>|/type/Promise>, so the code ends up
 with a bunch of separate locks, created in a bunch of threads, and
 thus they don't actually protect the code we want to protect.
 
@@ -156,7 +156,7 @@ calling C<lock> and C<unlock>. Failing that, use a C<LEAVE> phaser.
 
     method condition(Lock:D: )
 
-Returns a L<condition variable as a C<Lock::ConditionVariable> object|/type/Lock/ConditionVariable>.
+Returns a condition variable as a L<C<Lock::ConditionVariable>|/type/Lock::ConditionVariable> object.
 Check
 L<this article|https://web.stanford.edu/~ouster/cgi-bin/cs140-spring14/lecture.php?topic=locks> or
 L<the Wikipedia|https://en.wikipedia.org/wiki/Monitor_%28synchronization%29>

doc/Type/Lock/ConditionVariable.rakudoc

@@ -6,10 +6,10 @@
 
     class Lock::ConditionVariable {}
 
-Condition variables are used in L<C<Lock>s|/type/Lock> to wait for a
+Condition variables are used in L<C<Lock>|/type/Lock>s to wait for a
 particular condition to become true. You will normally not create one from
 scratch, but call L<C<Lock.condition>|/type/Lock#method_condition> to acquire
-one on a particular C<Lock>.
+one on a particular L<C<Lock>|/type/Lock>.
 
 =head1 Methods