databaselayout.md: added code blocks

diff --git a/citadel/docs/databaselayout.md b/citadel/docs/databaselayout.md
index 205fb829c4a6ed4c66a9757739e8ecdbfc62bcd9..1ef28174b25f49b82f9c297e5492303661a5a299 100644 (file)
--- a/citadel/docs/databaselayout.md
+++ b/citadel/docs/databaselayout.md
@@ -21,6 +21,7 @@ This table contains all user records.  It's indexed by
 user name (translated to lower case for indexing purposes).  The records in
 this file look something like this:
 
+```
     struct ctdluser {                   // User record
         int version;                    // Citadel version. which created this record
         uid_t uid;                      // Associate with a unix account?
@@ -32,6 +33,7 @@ this file look something like this:
         int USuserpurge;                // Purge time (in days) for user
         char fullname[64];              // Name for Citadel messages & mail
     };
+```
  
  Most fields here should be fairly self-explanatory.  The ones that might
 deserve some attention are:
@@ -53,6 +55,7 @@ These are room records.  There is a room record for every room on the
 system, public or private or mailbox.  It's indexed by room name (also in
 lower case for easy indexing) and it contains records which look like this:
 
+```
     struct ctdlroom {
         char QRname[ROOMNAMELEN];       /* Name of room                     */
         char QRpasswd[10];              /* Only valid if it's a private rm  */
@@ -70,6 +73,7 @@ lower case for easy indexing) and it contains records which look like this:
         unsigned QRflags2;              /* Additional flags                 */
         int QRdefaultview;              /* How to display the contents      */
     };
+```
 
 Again, mostly self-explanatory.  Here are the interesting ones:
  
@@ -120,6 +124,7 @@ contiguous; contrast with older Citadel implementations which simply kept a
 
 Here's what the records look like:
  
+```
     struct visit {
         long v_roomnum;
         long v_roomgen;
@@ -133,6 +138,7 @@ Here's what the records look like:
     #define V_FORGET        1       /* User has zapped this room        */
     #define V_LOCKOUT       2       /* User is locked out of this room  */
     #define V_ACCESS        4       /* Access is granted to this room   */
+```
  
 This table is indexed by a concatenation of the first three fields.  Whenever
 we want to learn the relationship between a user and a room, we feed that
@@ -294,16 +300,20 @@ EXAMPLE
 Let `<FF>` be a `0xFF` byte, and `<0>` be a null `(0x00)` byte.  Then a message
 which prints as...
 
+```
     Apr 12, 1988 23:16 From Test User In Network Test> @lifesys (Life Central)
     Have a nice day!
+```
 
 might be stored as...
 
+```
     <FF><40><0>I12345<0>Pneighbor!lifesys!test_user<0>T576918988<0>    (continued)
     -----------|Mesg ID#|--Message Path---------------|--Date------
     
     AThe Test User<0>ONetwork Test<0>Nlifesys<0>HLife Central<0>MHave a nice day!<0>
     |-----Author-----|-Room name-----|-nodename-|Human Name-|--Message text-----
+```
 
 Weird things can happen if fields are missing, especially if you use the
 networker.  But basically, the date, author, room, and nodename may be in any