about summary refs log tree commit diff stats
diff options
context:
space:
mode:
authorDarren Bane <darren.bane@gmail.com>2020-10-22 18:51:01 +0100
committerDarren Bane <darren.bane@gmail.com>2020-10-22 18:51:01 +0100
commit290b6a9de3f2877dca7f6e623fae435b373d24ef (patch)
tree0e072a4333dd3c89e172659171b78b5cb85f7acc
parent8648f2b83bb63108c5db2e2d6bc73bc1018f5304 (diff)
downloadlsp-290b6a9de3f2877dca7f6e623fae435b373d24ef.tar.gz
More hyperlinks
-rw-r--r--doc/Makefile2
-rw-r--r--doc/breaking_rules.md10
2 files changed, 6 insertions, 6 deletions
diff --git a/doc/Makefile b/doc/Makefile
index 7e21ba4..d481321 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -27,7 +27,7 @@ lkbib.txt: macros.ms lkbib.ms refs.i
 	groff -Tutf8 -R -ms -k -Kutf8 macros.ms lkbib.ms > $@
 
 %.gmi: %.md
-	md2gemini $^ > $@
+	md2gemini -m $^ > $@
 
 refs.i: refs
 	indxbib $^
diff --git a/doc/breaking_rules.md b/doc/breaking_rules.md
index 9b69e38..29c8267 100644
--- a/doc/breaking_rules.md
+++ b/doc/breaking_rules.md
@@ -62,7 +62,7 @@ Reasons for choosing Common Lisp include:
 * Contrary to a lot of other languages, it is fairly paradigm-agnostic.
 
 At the same time, I want a clean subset of CL,
-so cleave as close to ISLisp as practical[5].
+so cleave as [close to ISLisp](bane.20.cdr15.md) as practical[5].
 
 It was decided to use the imperative/object-oriented paradigm,
 partly for familiarity in industry and
@@ -88,8 +88,8 @@ Even though this is a prototype, attention should be paid to basic craftsmanship
 * Use `declare`
   to check the types of parameters in public interfaces.
 * Indent all the source code using Emacs.
-* Some minimal documentation, at least an overview README file[6]
-and man (actually, mdoc) pages[7].
+* Some minimal documentation, at least an overview [README](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html) file[6]
+  and man (actually, [mdoc](https://manpages.bsd.lv/toc.html)) pages[7].
 * Certain parts of a system justify greater detail for a *complete* specification.
   These are (newly-designed) network protocols and complex persistent data models.
   If there is no standard protocol, I recommend using JSON-RPC as a base and following the documentation style of LSP.
@@ -180,7 +180,7 @@ However, some of this documentation is better in the source code:
 
 * The summary of functions should be taken care of by having the public functions and classes commented.
 * The formal requirement for function behaviour can be done with
-  tables with Basic English[8].
+  tables with [Basic English](https://en.wikipedia.org/wiki/Basic_English)[8].
 * Although full design-by-contract may be out of reach
   a poor-man's version can be used with public functions following a pattern.
   This can also do some of the formal requirements.
@@ -246,6 +246,6 @@ It is hoped that this is more effective than most of what is currently-used.
 [3]Kent Pitman, Accelerating Hindsight: Lisp as a Vehicle for Rapid Prototyping (1994).  
 [4]Darren Bane, Design and Documentation of the Kernel of a Set of Tools for Working With Tabular Mathematical Expressions, University of Limerick, Ireland (19 Jul 2008).  
 [5]Darren Bane, An ISLisp-like subset of ANSI Common Lisp, Ireland (21 Aug 2020).  
-[6]Tom Preston-Werner, Readme Driven Development, San Francisco, CA, USA (23 Aug 2010). available: https://tom.preston-werner.com/2010/08/23/readme- driven-development.html [accessed 27 May 2020].  
+[6]Tom Preston-Werner, Readme Driven Development, San Francisco, CA, USA (23 Aug 2010). available: https://tom.preston-werner.com/2010/08/23/readme-driven-development.html [accessed 27 May 2020].  
 [7]Kristaps Dzonsons, Practical UNIX Manuals. available: https://manpages.bsd.lv/toc.html [accessed 9 Oct 2020].  
 [8]"Basic English" in Wikipedia. available: https://en.wikipedia.org/wiki/Basic_English [accessed 28 May 2020].