docs: add more more code-tags

It's easier to read function-names, file-names and other
"machine"-related strings if they are formatted in a monospace font. So
let's mark these up with code-tags.

Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>

docs/application-issues.html

@@ -48,16 +48,16 @@ start-up because of an extension string buffer-overflow problem.
 
 <p>
 The problem is a modern OpenGL driver will return a very long string
-for the glGetString(GL_EXTENSIONS) query and if the application
+for the <code>glGetString(GL_EXTENSIONS)</code> query and if the application
 naively copies the string into a fixed-size buffer it can overflow the
 buffer and crash the application.
 </p>
 
 <p>
-The work-around is to set the MESA_EXTENSION_MAX_YEAR environment variable
-to the approximate release year of the game.
-This will cause the glGetString(GL_EXTENSIONS) query to only report extensions
-older than the given year.
+The work-around is to set the <code>MESA_EXTENSION_MAX_YEAR</code>
+environment variable to the approximate release year of the game.
+This will cause the <code>glGetString(GL_EXTENSIONS)</code> query to only report
+extensions older than the given year.
 </p>
 
 <p>

docs/codingstyle.html

@@ -120,10 +120,11 @@ the opening brace goes on the next line by itself (see above.)
    _mesa_foo_bar()  - an internal non-static Mesa function
 </pre>
 
-<li>Constants, macros and enum names are ALL_UPPERCASE, with _ between
-words.
-<li>Mesa usually uses camel case for local variables (Ex: "localVarname")
-while gallium typically uses underscores (Ex: "local_var_name").
+<li>Constants, macros and enum names are <code>ALL_UPPERCASE</code>, with _
+between words.
+<li>Mesa usually uses camel case for local variables (Ex:
+<code>localVarname</code>) while gallium typically uses underscores (Ex:
+<code>local_var_name</code>).
 <li>Global variables are almost never used because Mesa should be thread-safe.
 
 <li>Booleans.  Places that are not directly visible to the GL API
@@ -131,8 +132,9 @@ should prefer the use of <code>bool</code>, <code>true</code>, and
 <code>false</code> over <code>GLboolean</code>, <code>GL_TRUE</code>, and
 <code>GL_FALSE</code>.  In C code, this may mean that
 <code>#include &lt;stdbool.h&gt;</code> needs to be added.  The
-<code>try_emit_</code>* methods in src/mesa/program/ir_to_mesa.cpp and
-src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples.
+<code>try_emit_</code>* methods in <code>src/mesa/program/ir_to_mesa.cpp</code>
+and <code>src/mesa/state_tracker/st_glsl_to_tgsi.cpp</code> can serve as
+examples.
 
 </ul>
 

docs/debugging.html

@@ -20,9 +20,9 @@
    Normally Mesa (and OpenGL) records but does not notify the user of
    errors.  It is up to the application to call
    <code>glGetError</code> to check for errors.  Mesa supports an
-   environment variable, MESA_DEBUG, to help with debugging.  If
-   MESA_DEBUG is defined, a message will be printed to stdout whenever
-   an error occurs.
+   environment variable, <code>MESA_DEBUG</code>, to help with debugging.  If
+   <code>MESA_DEBUG</code> is defined, a message will be printed to stdout
+   whenever an error occurs.
 </p>
 
 <p>
@@ -30,12 +30,12 @@
    (<code>--buildtype debug</code> for meson, <code>build=debug</code> for scons).
 </p>
 <p>
-   In your debugger you can set a breakpoint in _mesa_error() to trap Mesa
-   errors.
+   In your debugger you can set a breakpoint in <code>_mesa_error()</code> to trap
+   Mesa errors.
 </p>
 <p>
    There is a display list printing/debugging facility.  See the end of
-   src/dlist.c for details.
+   <code>src/dlist.c</code> for details.
 </p>
 
 </div>

docs/devinfo.html

@@ -29,8 +29,8 @@ To add a new GL extension to Mesa you have to do at least the following.
 
 <ul>
 <li>
-   If glext.h doesn't define the extension, edit include/GL/gl.h and add
-   code like this:
+   If <code>glext.h</code> doesn't define the extension, edit
+   <code>include/GL/gl.h</code> and add code like this:
    <pre>
      #ifndef GL_EXT_the_extension_name
      #define GL_EXT_the_extension_name 1
@@ -41,18 +41,18 @@ To add a new GL extension to Mesa you have to do at least the following.
    </pre>
 </li>
 <li>
-   In the src/mapi/glapi/gen/ directory, add the new extension functions and
-   enums to the gl_API.xml file.
+   In the <code>src/mapi/glapi/gen/</code> directory, add the new extension
+   functions and enums to the <code>gl_API.xml</code> file.
    Then, a bunch of source files must be regenerated by executing the
    corresponding Python scripts.
 </li>
 <li>
-   Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
-   if the extension requires driver capabilities not already exposed by
-   another extension.
+   Add a new entry to the <code>gl_extensions</code> struct in
+   <code>mtypes.h</code> if the extension requires driver capabilities not
+   already exposed by another extension.
 </li>
 <li>
-   Add a new entry to the src/mesa/main/extensions_table.h file.
+   Add a new entry to the <code>src/mesa/main/extensions_table.h</code> file.
 </li>
 <li>
    From this point, the best way to proceed is to find another extension,
@@ -65,13 +65,13 @@ To add a new GL extension to Mesa you have to do at least the following.
 </li>
 <li>
    To determine if the new extension is active in the current context,
-   use the auto-generated _mesa_has_##name_str() function defined in
-   src/mesa/main/extensions.h.
+   use the auto-generated <code>_mesa_has_##name_str()</code> function
+   defined in <code>src/mesa/main/extensions.h</code>.
 </li>
 <li>
-   The dispatch tests check_table.cpp and dispatch_sanity.cpp
+   The dispatch tests check_table.cpp and <code>dispatch_sanity.cpp</code>
    should be updated with details about the new extensions functions. These
-   tests are run using 'meson test'
+   tests are run using <code>meson test</code>.
 </li>
 </ul>
 

docs/faq.html

@@ -291,34 +291,34 @@ If you need a deeper you can modify the parameters to
 
 <h3>3.3 Why Isn't depth buffering working at all?</h3>
 <p>
-Be sure you're requesting a depth buffered-visual.  If you set the MESA_DEBUG
-environment variable it will warn you about trying to enable depth testing
-when you don't have a depth buffer.
+Be sure you're requesting a depth buffered-visual.  If you set the
+<code>MESA_DEBUG</code> environment variable it will warn you about trying
+to enable depth testing when you don't have a depth buffer.
 </p>
 <p>Specifically, make sure <code>glutInitDisplayMode</code> is being called
 with <code>GLUT_DEPTH</code> or <code>glXChooseVisual</code> is being
-called with a non-zero value for GLX_DEPTH_SIZE.
+called with a non-zero value for <code>GLX_DEPTH_SIZE</code>.
 </p>
 <p>This discussion applies to stencil buffers, accumulation buffers and
 alpha channels too.
 </p>
 
 
-<h3>3.4 Why does glGetString() always return NULL?</h3>
+<h3>3.4 Why does <code>glGetString()</code> always return <code>NULL</code>?</h3>
 <p>
 Be sure you have an active/current OpenGL rendering context before
-calling glGetString.
+calling <code>glGetString</code>.
 </p>
 
 
-<h3>3.5 GL_POINTS and GL_LINES don't touch the right pixels</h3>
+<h3>3.5 <code>GL_POINTS</code> and <code>GL_LINES</code> don't touch the
+right pixels</h3>
 <p>
-If you're trying to draw a filled region by using GL_POINTS or GL_LINES
-and seeing holes or gaps it's because of a float-to-int rounding problem.
-But this is not a bug.
-See Appendix H of the OpenGL Programming Guide - "OpenGL Correctness Tips".
-Basically, applying a translation of (0.375, 0.375, 0.0) to your coordinates
-will fix the problem.
+If you're trying to draw a filled region by using <code>GL_POINTS</code> or
+<code>GL_LINES</code> and seeing holes or gaps it's because of a float-to-int
+rounding problem. But this is not a bug. See Appendix H of the OpenGL
+Programming Guide - "OpenGL Correctness Tips". Basically, applying a
+translation of (0.375, 0.375, 0.0) to your coordinates will fix the problem.
 </p>
 
 <br>
@@ -365,7 +365,8 @@ the archives) is a good way to get information.
 </p>
 
 
-<h3>4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa?</h3>
+<h3>4.3 Why isn't <code>GL_EXT_texture_compression_s3tc</code> implemented in
+Mesa?</h3>
 <p>
 Oh but it is! Prior to 2nd October 2017, the Mesa project did not include s3tc
 support due to intellectual property (IP) and/or patent issues around the s3tc

docs/helpwanted.html

@@ -48,7 +48,8 @@ You can find some further To-do lists here:
 </p>
 <ul>
   <li><a href="https://gitlab.freedesktop.org/mesa/mesa/blob/master/docs/features.txt">
-    <b>features.txt</b></a> - Status of OpenGL 3.x / 4.x features in Mesa.</li>
+    <code>features.txt</code></a> - Status of OpenGL 3.x / 4.x features in
+    Mesa.</li>
 </ul>
 
 <p>
@@ -56,9 +57,9 @@ You can find some further To-do lists here:
 </p>
 <ul>
   <li><a href="https://dri.freedesktop.org/wiki/R600ToDo">
-    <b>r600g</b></a> - Driver for ATI/AMD R600 - Northern Island.</li>
+    <code>r600g</code></a> - Driver for ATI/AMD R600 - Northern Island.</li>
   <li><a href="https://dri.freedesktop.org/wiki/R300ToDo">
-    <b>r300g</b></a> - Driver for ATI R300 - R500.</li>
+    <code>r300g</code></a> - Driver for ATI R300 - R500.</li>
 </ul>
 
 <p>