--- a/doc/interpreter/contrib.txi
+++ b/doc/interpreter/contrib.txi
@@ -136,54 +136,50 @@
 ## see <http://www.gnu.org/licenses/>.
 @end example
 
-Always include commit messages in changesets. After making your source
+Always include commit messages in changesets.  After making your source
 changes, record and briefly describe the changes in your commit message.
 You should have previously configured your @file{.hgrc} (or
 @file{Mercurial.ini} on Windows) with your name and email, which will
-get automatically added to your commit message. Your commit message
-should have a brief one-line explanation of what the commit does. If you
+get automatically added to your commit message.  Your commit message
+should have a brief one-line explanation of what the commit does.  If you
 are patching a bug, this one-line explanation should mention the bug
-number at the end. If your change is small and only touches one file,
-this is typically sufficient. If you are modifying several files or
+number at the end.  If your change is small and only touches one file,
+this is typically sufficient.  If you are modifying several files or
 several parts of one file, you should enumerate your changes roughly
 following the GNU coding standards on changelogs, like the following
 example:
 
 @example
 @group
-    look for methods before constructors
-
-    * symtab.cc (symbol_table::fcn_info::fcn_info_rep::find):
-    Look for class methods before constructors, contrary to Matlab
-    documentation.
+look for methods before constructors
 
-    * test/ctor-vs-method: New directory of test classes.
-    * test/test_ctor_vs_method.m: New file.
-    * test/Makefile.am: Include ctor-vs-method/module.mk.
-    (FCN_FILES): Include test_ctor_vs_method.m in the list.
+* symtab.cc (symbol_table::fcn_info::fcn_info_rep::find):
+Look for class methods before constructors, contrary to Matlab
+documentation.
 
-    * DLD-FUNCTIONS/regexp.cc (octregexp_list): Handle repeated matches
-    in the list of matches returned by pcre.
+* test/ctor-vs-method: New directory of test classes.
+* test/test_ctor_vs_method.m: New file.
+* test/Makefile.am: Include ctor-vs-method/module.mk.
+(FCN_FILES): Include test_ctor_vs_method.m in the list.
 @end group
 @end example
 
 @noindent
 In this example, the names of files is mentioned, and in parentheses the
-name of the function in that file that was modified. There is no need to
-mention the function for m-files that only contain one function. The
-commit message should describe what is changed, not why. Any explanation
+name of the function in that file that was modified.  There is no need to
+mention the function for m-files that only contain one function.  The
+commit message should describe what is changed, not why.  Any explanation
 of why a change is needed should appear as comments in the code,
 particularly if there is something that might not be obvious to someone
 reading it later.
 
 When submitting code which addresses a known bug on the Octave bug
 tracker (@url{http://bugs.octave.org}), please add '(bug #XXXXX)' to the
-commit messages. Example:
+first line of the commit messages.  For example:
 
 @example
 @group
-  * ols.m: Fix erroneous degrees of freedom when computing the
-    covariance estimator (bug #32892).
+Fix bug for complex input for gradient (bug #34292).
 @end group
 @end example
 
@@ -281,7 +277,7 @@
 for both function definitions and function calls.
 
 Recommended indent is 2 spaces.  When indenting, indent the statement
-after control structures (like @code{if}, @code{while}, etc.). If there
+after control structures (like @code{if}, @code{while}, etc.).  If there
 is a compound statement, indent @emph{both} the curly braces and the
 body of the statement (so that the body gets indented by @emph{two}
 indents).  Example: