Fix some formatting

src/doc/new-doc/extensions/memory.txi

@@ -46,18 +46,18 @@ The customizable limits are listed in @ref{tab:mem-limits}, but they need a care
 
 @itemize
 @item
-    ext:heap-size limits the total amount of memory which is available for lisp objects. This is the memory used when you create conses, arrays, structures, etc.
+    @code{ext:heap-size} limits the total amount of memory which is available for lisp objects. This is the memory used when you create conses, arrays, structures, etc.
 @item
-    ext:c-stack controls the size of the stack for compiled code, including ECL's library itself. This limit is less stringent than the others. For instance, when code is compiled with low safety settings, checks for this stack limit are usually omitted, for performance reasons.
+    @code{ext:c-stack} controls the size of the stack for compiled code, including ECL's library itself. This limit is less stringent than the others. For instance, when code is compiled with low safety settings, checks for this stack limit are usually omitted, for performance reasons.
 @item
-    ext:binding-stack controls the number of nested bindings for special variables. The current value is usually safe enough, unless you have deep recursive functions that bind special variables, which is not really a good idea.
+    @code{ext:binding-stack} controls the number of nested bindings for special variables. The current value is usually safe enough, unless you have deep recursive functions that bind special variables, which is not really a good idea.
 @item
-    ext:frame-stack controls the number of nested blocks, tagbody and other control structures. It affects both interpreted and compiled code, but quite often compiled code optimizes away these stack frames, saving memory and not being affected by this limit.
+    @code{ext:frame-stack} controls the number of nested blocks, tagbody and other control structures. It affects both interpreted and compiled code, but quite often compiled code optimizes away these stack frames, saving memory and not being affected by this limit.
 @item
-    ext:lisp-stack controls the size of the interpreter stack. It only affects interpreted code.
+    @code{ext:lisp-stack} controls the size of the interpreter stack. It only affects interpreted code.
 @end itemize
 
-If you look at @ref{tab:mem-limits}, some of these limits may seem very stringent, but they exist to allow detecting and correcting both stack and memory overflow conditions. Larger values can be set systematically either in the ~/.eclrc initialization file, or using the command line options from the table.
+If you look at @ref{tab:mem-limits}, some of these limits may seem very stringent, but they exist to allow detecting and correcting both stack and memory overflow conditions. Larger values can be set systematically either in the @file{~/.eclrc} initialization file, or using the command line options from the table.
 
 @node Memory conditions
 @subsection Memory conditions
@@ -82,7 +82,7 @@ Top level.
 
 @node Finalization
 @subsection Finalization
-As we all know, Common-Lisp relies on garbage collection for deleting unreachable objects. However, it makes no provision for the equivalent of a C++ Destructor function that should be called when the object is eliminated by the garbage collector. The equivalent of such methods in a garbage collected environment is normally called a finalizer.
+As we all know, Common-Lisp relies on garbage collection for deleting unreachable objects. However, it makes no provision for the equivalent of a C++ Destructor function that should be called when the object is eliminated by the garbage collector. The equivalent of such methods in a garbage collected environment is normally called a @dfn{finalizer}.
 
 ECL includes a simple implementation of finalizers which makes the following promises.
 
@@ -90,7 +90,7 @@ ECL includes a simple implementation of finalizers which makes the following pro
 @item
 The finalizer can be any lisp function, let it be compiled or interpreter.
 @item
-Finalizers are not invoked during garbage collection. Instead, if an unreachable object is found to have an associated finalizer, it is pushed into a list and before the next garbage collection cycle, the finalizer will be invoked.
+Finalizers are not invoked during garbage collection. Instead, if an unreachable object is found to have an associated finalizer, it is pushed into a list and @emph{before the next garbage collection cycle}, the finalizer will be invoked.
 @item
 If the finalizer is invoked and it makes the object reachable, for instance, by assigning it to a variable, it will not be destroyed, but it will have no longer a finalizer associated to it.
 @item

src/doc/new-doc/extensions/memory_ref.txi

@@ -83,7 +83,7 @@ A function or closure that takes one argument or NIL.
 @end table
 
 @subsubheading Description
-If @var{function} is NIL no finalizer is associated to the object. Otherwise @var{function} must be a function or a closure of one argument, which will be invoked before the object is destroyed.
+If @var{function} is NIL, no finalizer is associated to the object. Otherwise @var{function} must be a function or a closure of one argument, which will be invoked before the object is destroyed.
 
 @subsubheading Example
 Close a file associated to an object.
@@ -119,7 +119,7 @@ A symbol.
 @item value
 A positive integer.
 @end table
-Changes the different memory and stack limits that condition ECL's behavior. The value to be changed is denoted by the symbol @var{concept}, while the @code{value} is the new maximum size. The valid symbols and units are listed in @ref{tab:mem-limits}.
+Changes the different memory and stack limits that condition ECL's behavior. The value to be changed is denoted by the symbol @var{concept}, while the @var{value} is the new maximum size. The valid symbols and units are listed in @ref{tab:mem-limits}.
 
 Note that the limit has to be positive, but it may be smaller than the previous value of the limit. However, if the supplied value is smaller than what ECL is using at the moment, the new value will be silently ignored.