Fossil SCM

Several doc adjustments to make things work better with the new skin. Although this isn't strictly part of the new skin, and it does admit of a type of regression, I'm committing it here anyway because these are cases where markup was used to work around problems in the old skin. Nearly all of these are misuses of the "blockquote" tag to mean "indented paragraph". Now that we have true indented paragraph styles, switched the markup over to use them.

wyoung 2024-01-26 17:28 inskinerator-modern-backport

Commit ee6ca48c8f620238bcae639d96431b63d1a19fc43e8cf119e025e2f6f3cbe96e

Parent 538ddbffbe25b67…

7 files changed +2 -3 +8 -8 +5 -5 +10 -10 +59 -59 +14 -14 +47 -57

~ test/release-checklist.wiki ~ www/adding_code.wiki ~ www/backoffice.md ~ www/build.wiki ~ www/customskin.md ~ www/makefile.wiki ~ www/sync.wiki

M test/release-checklist.wiki

+2 -3

		--- test/release-checklist.wiki
		+++ test/release-checklist.wiki
		@@ -47,13 +47,12 @@
47	47	Shift-click on each of the links in [./fileage-test-1.wiki] and verify
48	48	correct operation of the file-age computation.
49	49
50	50	<li><p>
51	51	Verify correct name-change tracking behavior (no net changes) for:
52		-<blockquote><b>
53		-fossil test-name-changes --debug b120bc8b262ac 374920b20944b
54		-</b></blockquote>
	52	+<pre><b>fossil test-name-changes --debug b120bc8b262ac 374920b20944b
	53	+</b></pre>
55	54
56	55	<li><p>
57	56	Compile for all of the following platforms:
58	57	<ol type="a">
59	58	<li> Linux x86
60	59

	--- test/release-checklist.wiki
	+++ test/release-checklist.wiki
	@@ -47,13 +47,12 @@
47	Shift-click on each of the links in [./fileage-test-1.wiki] and verify
48	correct operation of the file-age computation.
49
50	<li><p>
51	Verify correct name-change tracking behavior (no net changes) for:
52	<blockquote><b>
53	fossil test-name-changes --debug b120bc8b262ac 374920b20944b
54	</b></blockquote>
55
56	<li><p>
57	Compile for all of the following platforms:
58	<ol type="a">
59	<li> Linux x86
60

	--- test/release-checklist.wiki
	+++ test/release-checklist.wiki
	@@ -47,13 +47,12 @@
47	Shift-click on each of the links in [./fileage-test-1.wiki] and verify
48	correct operation of the file-age computation.
49
50	<li><p>
51	Verify correct name-change tracking behavior (no net changes) for:
52	<pre><b>fossil test-name-changes --debug b120bc8b262ac 374920b20944b
53	</b></pre>

54
55	<li><p>
56	Compile for all of the following platforms:
57	<ol type="a">
58	<li> Linux x86
59

M www/adding_code.wiki

+8 -8

		--- www/adding_code.wiki
		+++ www/adding_code.wiki
		@@ -62,11 +62,11 @@
62	62	ActiveState.
63	63
64	64	After the makefiles have been updated, create the xyzzy.c source file
65	65	from the following template:
66	66
67		-<blockquote><verbatim>
	67	+<verbatim>
68	68	/*
69	69	** Copyright boilerplate goes here.
70	70	*****************************************************
71	71	** High-level description of what this module goes
72	72	** here.
		@@ -78,11 +78,11 @@
78	78	/* Exported object (structure) definitions or #defines
79	79	** go here */
80	80	#endif /* INTERFACE */
81	81
82	82	/* New code goes here */
83		-</verbatim></blockquote>
	83	+</verbatim>
84	84
85	85	Note in particular the <b>#include "xyzzy.h"</b> line near the top.
86	86	The "xyzzy.h" file is automatically generated by makeheaders. Every
87	87	normal Fossil source file must have a #include at the top that imports
88	88	its private header file. (Some source files, such as "sqlite3.c" are
		@@ -114,30 +114,30 @@
114	114	The "command" is "diff". Commands may optionally be followed by
115	115	arguments and/or options. To create new commands in Fossil, add code
116	116	(either to an existing source file, or to a new source file created as
117	117	described above) according to the following template:
118	118
119		-<blockquote><verbatim>
	119	+<verbatim>
120	120	/*
121	121	** COMMAND: xyzzy
122	122	**
123	123	** Help text goes here. Backslashes must be escaped.
124	124	*/
125	125	void xyzzy_cmd(void){
126	126	/* Implement the command here */
127	127	fossil_print("Hello, World!\n");
128	128	}
129		-</verbatim></blockquote>
	129	+</verbatim>
130	130
131	131	The example above creates a new command named "xyzzy" that prints the
132	132	message "Hello, World!" on the console. This command is a normal command
133	133	that will show up in the list of command from [/help/help\|fossil help].
134	134	If you add an asterisk to the end of the command name, like this:
135	135
136		-<blockquote><verbatim>
	136	+<verbatim>
137	137	** COMMAND: xyzzy*
138		-</verbatim></blockquote>
	138	+</verbatim>
139	139
140	140	Then the command will only show up if you add the "--all" option to
141	141	[/help/help\|fossil help]. Or, if the command name starts with
142	142	"test" then the command will be considered experimental and will only
143	143	show up when the --test option is used with [/help/help\|fossil help].
		@@ -173,20 +173,20 @@
173	173
174	174	As with commands, new webpages can be added simply by inserting a function
175	175	that generates the webpage together with a special header comment. A
176	176	template follows:
177	177
178		-<blockquote><verbatim>
	178	+<verbatim>
179	179	/*
180	180	** WEBPAGE: helloworld
181	181	*/
182	182	void helloworld_page(void){
183	183	style_header("Hello World!");
184	184	@ <p>Hello, World!</p>
185	185	style_footer();
186	186	}
187		-</verbatim></blockquote>
	187	+</verbatim>
188	188
189	189	Add the code above to a new or existing Fossil source code file, then
190	190	recompile fossil and run [/help/ui\|fossil ui] then enter
191	191	"http://localhost:8080/helloworld" in your web browser and the routine
192	192	above will generate a web page that says "Hello World."
193	193

	--- www/adding_code.wiki
	+++ www/adding_code.wiki
	@@ -62,11 +62,11 @@
62	ActiveState.
63
64	After the makefiles have been updated, create the xyzzy.c source file
65	from the following template:
66
67	<blockquote><verbatim>
68	/*
69	** Copyright boilerplate goes here.
70	*****************************************************
71	** High-level description of what this module goes
72	** here.
	@@ -78,11 +78,11 @@
78	/* Exported object (structure) definitions or #defines
79	** go here */
80	#endif /* INTERFACE */
81
82	/* New code goes here */
83	</verbatim></blockquote>
84
85	Note in particular the <b>#include "xyzzy.h"</b> line near the top.
86	The "xyzzy.h" file is automatically generated by makeheaders. Every
87	normal Fossil source file must have a #include at the top that imports
88	its private header file. (Some source files, such as "sqlite3.c" are
	@@ -114,30 +114,30 @@
114	The "command" is "diff". Commands may optionally be followed by
115	arguments and/or options. To create new commands in Fossil, add code
116	(either to an existing source file, or to a new source file created as
117	described above) according to the following template:
118
119	<blockquote><verbatim>
120	/*
121	** COMMAND: xyzzy
122	**
123	** Help text goes here. Backslashes must be escaped.
124	*/
125	void xyzzy_cmd(void){
126	/* Implement the command here */
127	fossil_print("Hello, World!\n");
128	}
129	</verbatim></blockquote>
130
131	The example above creates a new command named "xyzzy" that prints the
132	message "Hello, World!" on the console. This command is a normal command
133	that will show up in the list of command from [/help/help\|fossil help].
134	If you add an asterisk to the end of the command name, like this:
135
136	<blockquote><verbatim>
137	** COMMAND: xyzzy*
138	</verbatim></blockquote>
139
140	Then the command will only show up if you add the "--all" option to
141	[/help/help\|fossil help]. Or, if the command name starts with
142	"test" then the command will be considered experimental and will only
143	show up when the --test option is used with [/help/help\|fossil help].
	@@ -173,20 +173,20 @@
173
174	As with commands, new webpages can be added simply by inserting a function
175	that generates the webpage together with a special header comment. A
176	template follows:
177
178	<blockquote><verbatim>
179	/*
180	** WEBPAGE: helloworld
181	*/
182	void helloworld_page(void){
183	style_header("Hello World!");
184	@ <p>Hello, World!</p>
185	style_footer();
186	}
187	</verbatim></blockquote>
188
189	Add the code above to a new or existing Fossil source code file, then
190	recompile fossil and run [/help/ui\|fossil ui] then enter
191	"http://localhost:8080/helloworld" in your web browser and the routine
192	above will generate a web page that says "Hello World."
193

	--- www/adding_code.wiki
	+++ www/adding_code.wiki
	@@ -62,11 +62,11 @@
62	ActiveState.
63
64	After the makefiles have been updated, create the xyzzy.c source file
65	from the following template:
66
67	<verbatim>
68	/*
69	** Copyright boilerplate goes here.
70	*****************************************************
71	** High-level description of what this module goes
72	** here.
	@@ -78,11 +78,11 @@
78	/* Exported object (structure) definitions or #defines
79	** go here */
80	#endif /* INTERFACE */
81
82	/* New code goes here */
83	</verbatim>
84
85	Note in particular the <b>#include "xyzzy.h"</b> line near the top.
86	The "xyzzy.h" file is automatically generated by makeheaders. Every
87	normal Fossil source file must have a #include at the top that imports
88	its private header file. (Some source files, such as "sqlite3.c" are
	@@ -114,30 +114,30 @@
114	The "command" is "diff". Commands may optionally be followed by
115	arguments and/or options. To create new commands in Fossil, add code
116	(either to an existing source file, or to a new source file created as
117	described above) according to the following template:
118
119	<verbatim>
120	/*
121	** COMMAND: xyzzy
122	**
123	** Help text goes here. Backslashes must be escaped.
124	*/
125	void xyzzy_cmd(void){
126	/* Implement the command here */
127	fossil_print("Hello, World!\n");
128	}
129	</verbatim>
130
131	The example above creates a new command named "xyzzy" that prints the
132	message "Hello, World!" on the console. This command is a normal command
133	that will show up in the list of command from [/help/help\|fossil help].
134	If you add an asterisk to the end of the command name, like this:
135
136	<verbatim>
137	** COMMAND: xyzzy*
138	</verbatim>
139
140	Then the command will only show up if you add the "--all" option to
141	[/help/help\|fossil help]. Or, if the command name starts with
142	"test" then the command will be considered experimental and will only
143	show up when the --test option is used with [/help/help\|fossil help].
	@@ -173,20 +173,20 @@
173
174	As with commands, new webpages can be added simply by inserting a function
175	that generates the webpage together with a special header comment. A
176	template follows:
177
178	<verbatim>
179	/*
180	** WEBPAGE: helloworld
181	*/
182	void helloworld_page(void){
183	style_header("Hello World!");
184	@ <p>Hello, World!</p>
185	style_footer();
186	}
187	</verbatim>
188
189	Add the code above to a new or existing Fossil source code file, then
190	recompile fossil and run [/help/ui\|fossil ui] then enter
191	"http://localhost:8080/helloworld" in your web browser and the routine
192	above will generate a web page that says "Hello World."
193

M www/backoffice.md

+5 -5

		--- www/backoffice.md
		+++ www/backoffice.md
		@@ -79,11 +79,11 @@
79	79	being accessed, then the automatic backoffice will never run, and the
80	80	daily digest might not go out until somebody does visit a webpage.
81	81	If this is a problem, an administrator can set up a cron job to
82	82	periodically run:
83	83
84		-> fossil backoffice _REPOSITORY_
	84	+ fossil backoffice _REPOSITORY_
85	85
86	86	That command will cause backoffice processing to occur immediately.
87	87	Note that this is almost never necessary for an internet-facing
88	88	Fossil repository, since most repositories will get multiple accesses
89	89	per day from random robots, which will be sufficient to kick off the
		@@ -102,16 +102,16 @@
102	102	on OpenBSD systems.
103	103
104	104	To set up fully-manual backoffice, first disable the automatic backoffice
105	105	using the "[backoffice-disable](/help?cmd=backoffice-disable)" setting.
106	106
107		-> fossil setting backoffice-disable on
	107	+ fossil setting backoffice-disable on
108	108
109	109	Then arrange to invoke the backoffice separately using a command
110	110	like this:
111	111
112		-> fossil backoffice --poll 30 _REPOSITORY-LIST_
	112	+ fossil backoffice --poll 30 _REPOSITORY-LIST_
113	113
114	114	Multiple repositories can be named. This one command will handle
115	115	launching the backoffice for all of them. There are additional useful
116	116	command-line options. See the "[fossil backoffice](/help?cmd=backoffice)"
117	117	documentation for details.
		@@ -147,11 +147,11 @@
147	147	not a process still exists.
148	148
149	149	You can print out a decoded copy of the current backoffice lease using
150	150	this command:
151	151
152		-> fossil test-backoffice-lease -R _REPOSITORY_
	152	+ fossil test-backoffice-lease -R _REPOSITORY_
153	153
154	154	If a system has been idle for a long time, then there will be no
155	155	backoffice processes. (Either the process id entries in the lease
156	156	will be zero, or there will exist no process associated with the
157	157	process id.) When a new web request comes in, the system
		@@ -197,11 +197,11 @@
197	197	there are some debugging aids.
198	198
199	199	We have already mentioned the command that shows the backoffice lease
200	200	for a repository:
201	201
202		-> fossil test-backoffice-lease -R _REPOSITORY_
	202	+ fossil test-backoffice-lease -R _REPOSITORY_
203	203
204	204	Running that command every few seconds should show what is going on with
205	205	backoffice processing in a particular repository.
206	206
207	207	There are also settings that control backoffice behavior. The
208	208

	--- www/backoffice.md
	+++ www/backoffice.md
	@@ -79,11 +79,11 @@
79	being accessed, then the automatic backoffice will never run, and the
80	daily digest might not go out until somebody does visit a webpage.
81	If this is a problem, an administrator can set up a cron job to
82	periodically run:
83
84	> fossil backoffice _REPOSITORY_
85
86	That command will cause backoffice processing to occur immediately.
87	Note that this is almost never necessary for an internet-facing
88	Fossil repository, since most repositories will get multiple accesses
89	per day from random robots, which will be sufficient to kick off the
	@@ -102,16 +102,16 @@
102	on OpenBSD systems.
103
104	To set up fully-manual backoffice, first disable the automatic backoffice
105	using the "[backoffice-disable](/help?cmd=backoffice-disable)" setting.
106
107	> fossil setting backoffice-disable on
108
109	Then arrange to invoke the backoffice separately using a command
110	like this:
111
112	> fossil backoffice --poll 30 _REPOSITORY-LIST_
113
114	Multiple repositories can be named. This one command will handle
115	launching the backoffice for all of them. There are additional useful
116	command-line options. See the "[fossil backoffice](/help?cmd=backoffice)"
117	documentation for details.
	@@ -147,11 +147,11 @@
147	not a process still exists.
148
149	You can print out a decoded copy of the current backoffice lease using
150	this command:
151
152	> fossil test-backoffice-lease -R _REPOSITORY_
153
154	If a system has been idle for a long time, then there will be no
155	backoffice processes. (Either the process id entries in the lease
156	will be zero, or there will exist no process associated with the
157	process id.) When a new web request comes in, the system
	@@ -197,11 +197,11 @@
197	there are some debugging aids.
198
199	We have already mentioned the command that shows the backoffice lease
200	for a repository:
201
202	> fossil test-backoffice-lease -R _REPOSITORY_
203
204	Running that command every few seconds should show what is going on with
205	backoffice processing in a particular repository.
206
207	There are also settings that control backoffice behavior. The
208

	--- www/backoffice.md
	+++ www/backoffice.md
	@@ -79,11 +79,11 @@
79	being accessed, then the automatic backoffice will never run, and the
80	daily digest might not go out until somebody does visit a webpage.
81	If this is a problem, an administrator can set up a cron job to
82	periodically run:
83
84	fossil backoffice _REPOSITORY_
85
86	That command will cause backoffice processing to occur immediately.
87	Note that this is almost never necessary for an internet-facing
88	Fossil repository, since most repositories will get multiple accesses
89	per day from random robots, which will be sufficient to kick off the
	@@ -102,16 +102,16 @@
102	on OpenBSD systems.
103
104	To set up fully-manual backoffice, first disable the automatic backoffice
105	using the "[backoffice-disable](/help?cmd=backoffice-disable)" setting.
106
107	fossil setting backoffice-disable on
108
109	Then arrange to invoke the backoffice separately using a command
110	like this:
111
112	fossil backoffice --poll 30 _REPOSITORY-LIST_
113
114	Multiple repositories can be named. This one command will handle
115	launching the backoffice for all of them. There are additional useful
116	command-line options. See the "[fossil backoffice](/help?cmd=backoffice)"
117	documentation for details.
	@@ -147,11 +147,11 @@
147	not a process still exists.
148
149	You can print out a decoded copy of the current backoffice lease using
150	this command:
151
152	fossil test-backoffice-lease -R _REPOSITORY_
153
154	If a system has been idle for a long time, then there will be no
155	backoffice processes. (Either the process id entries in the lease
156	will be zero, or there will exist no process associated with the
157	process id.) When a new web request comes in, the system
	@@ -197,11 +197,11 @@
197	there are some debugging aids.
198
199	We have already mentioned the command that shows the backoffice lease
200	for a repository:
201
202	fossil test-backoffice-lease -R _REPOSITORY_
203
204	Running that command every few seconds should show what is going on with
205	backoffice processing in a particular repository.
206
207	There are also settings that control backoffice behavior. The
208

M www/build.wiki

+10 -10

		--- www/build.wiki
		+++ www/build.wiki
		@@ -190,25 +190,25 @@
190	190	source code for OpenSSL</a> and extract it to an appropriately named
191	191	"<b>openssl</b>" subdirectory within the local
192	192	[/tree?ci=trunk&name=compat \| compat] directory then make sure that some recent
193	193	<a href="http://www.perl.org/">Perl</a> binaries are installed locally,
194	194	and finally run one of the following commands:
195		-<blockquote><pre>
	195	+<pre>
196	196	nmake /f Makefile.msc FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin
197		-</pre></blockquote>
198		-<blockquote><pre>
	197	+</pre>
	198	+<pre>
199	199	buildmsvc.bat FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin
200		-</pre></blockquote>
	200	+</pre>
201	201	To enable the optional native [./th1.md#tclEval \| Tcl integration feature],
202	202	run one of the following commands or add the "FOSSIL_ENABLE_TCL=1"
203	203	argument to one of the other NMAKE command lines:
204		-<blockquote><pre>
	204	+<pre>
205	205	nmake /f Makefile.msc FOSSIL_ENABLE_TCL=1
206		-</pre></blockquote>
207		-<blockquote><pre>
	206	+</pre>
	207	+<pre>
208	208	buildmsvc.bat FOSSIL_ENABLE_TCL=1
209		-</pre></blockquote>
	209	+</pre>
210	210
211	211	<li><i>Cygwin</i> → The same as other Unix-like systems. It is
212	212	recommended to configure using: "<b>configure --disable-internal-sqlite</b>",
213	213	making sure you have the "libsqlite3-devel" , "zlib-devel" and
214	214	"openssl-devel" packages installed first.</li>
		@@ -251,17 +251,17 @@
251	251	</li>
252	252
253	253	<li>
254	254	To build on older Macs (circa 2002, MacOS 10.2) edit the Makefile
255	255	generated by configure to add the following lines:
256		- <blockquote><pre>
	256	+ <pre>
257	257	TCC += -DSQLITE_WITHOUT_ZONEMALLOC
258	258	TCC += -D_BSD_SOURCE
259	259	TCC += -DWITHOUT_ICONV
260	260	TCC += -Dsocketlen_t=int
261	261	TCC += -DSQLITE_MAX_MMAP_SIZE=0
262		- </pre></blockquote>
	262	+ </pre>
263	263	</li>
264	264	</ul>
265	265
266	266
267	267	<h2 id="docker" name="oci">5.0 Building a Docker Container</h2>
268	268

	--- www/build.wiki
	+++ www/build.wiki
	@@ -190,25 +190,25 @@
190	source code for OpenSSL</a> and extract it to an appropriately named
191	"<b>openssl</b>" subdirectory within the local
192	[/tree?ci=trunk&name=compat \| compat] directory then make sure that some recent
193	<a href="http://www.perl.org/">Perl</a> binaries are installed locally,
194	and finally run one of the following commands:
195	<blockquote><pre>
196	nmake /f Makefile.msc FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin
197	</pre></blockquote>
198	<blockquote><pre>
199	buildmsvc.bat FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin
200	</pre></blockquote>
201	To enable the optional native [./th1.md#tclEval \| Tcl integration feature],
202	run one of the following commands or add the "FOSSIL_ENABLE_TCL=1"
203	argument to one of the other NMAKE command lines:
204	<blockquote><pre>
205	nmake /f Makefile.msc FOSSIL_ENABLE_TCL=1
206	</pre></blockquote>
207	<blockquote><pre>
208	buildmsvc.bat FOSSIL_ENABLE_TCL=1
209	</pre></blockquote>
210
211	<li><i>Cygwin</i> → The same as other Unix-like systems. It is
212	recommended to configure using: "<b>configure --disable-internal-sqlite</b>",
213	making sure you have the "libsqlite3-devel" , "zlib-devel" and
214	"openssl-devel" packages installed first.</li>
	@@ -251,17 +251,17 @@
251	</li>
252
253	<li>
254	To build on older Macs (circa 2002, MacOS 10.2) edit the Makefile
255	generated by configure to add the following lines:
256	<blockquote><pre>
257	TCC += -DSQLITE_WITHOUT_ZONEMALLOC
258	TCC += -D_BSD_SOURCE
259	TCC += -DWITHOUT_ICONV
260	TCC += -Dsocketlen_t=int
261	TCC += -DSQLITE_MAX_MMAP_SIZE=0
262	</pre></blockquote>
263	</li>
264	</ul>
265
266
267	<h2 id="docker" name="oci">5.0 Building a Docker Container</h2>
268

	--- www/build.wiki
	+++ www/build.wiki
	@@ -190,25 +190,25 @@
190	source code for OpenSSL</a> and extract it to an appropriately named
191	"<b>openssl</b>" subdirectory within the local
192	[/tree?ci=trunk&name=compat \| compat] directory then make sure that some recent
193	<a href="http://www.perl.org/">Perl</a> binaries are installed locally,
194	and finally run one of the following commands:
195	<pre>
196	nmake /f Makefile.msc FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin
197	</pre>
198	<pre>
199	buildmsvc.bat FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin
200	</pre>
201	To enable the optional native [./th1.md#tclEval \| Tcl integration feature],
202	run one of the following commands or add the "FOSSIL_ENABLE_TCL=1"
203	argument to one of the other NMAKE command lines:
204	<pre>
205	nmake /f Makefile.msc FOSSIL_ENABLE_TCL=1
206	</pre>
207	<pre>
208	buildmsvc.bat FOSSIL_ENABLE_TCL=1
209	</pre>
210
211	<li><i>Cygwin</i> → The same as other Unix-like systems. It is
212	recommended to configure using: "<b>configure --disable-internal-sqlite</b>",
213	making sure you have the "libsqlite3-devel" , "zlib-devel" and
214	"openssl-devel" packages installed first.</li>
	@@ -251,17 +251,17 @@
251	</li>
252
253	<li>
254	To build on older Macs (circa 2002, MacOS 10.2) edit the Makefile
255	generated by configure to add the following lines:
256	<pre>
257	TCC += -DSQLITE_WITHOUT_ZONEMALLOC
258	TCC += -D_BSD_SOURCE
259	TCC += -DWITHOUT_ICONV
260	TCC += -Dsocketlen_t=int
261	TCC += -DSQLITE_MAX_MMAP_SIZE=0
262	</pre>
263	</li>
264	</ul>
265
266
267	<h2 id="docker" name="oci">5.0 Building a Docker Container</h2>
268

M www/customskin.md

+59 -59

		--- www/customskin.md
		+++ www/customskin.md
		@@ -71,68 +71,68 @@
71	71
72	72	Fossil usually (but not always - [see below](#override))
73	73	generates the initial HTML Header section of a page. The
74	74	generated HTML Header will look something like this:
75	75
76		- <html>
77		- <head>
78		- <base href="...">
79		- <meta http-equiv="Content-Security-Policy" content="....">
80		- <meta name="viewport" content="width=device-width, initial-scale=1.0">
81		- <title>....</title>
82		- <link rel="stylesheet" href="..." type="text/css">
83		- </head>
84		- <body class="FEATURE">
	76	+ <html>
	77	+ <head>
	78	+ <base href="...">
	79	+ <meta http-equiv="Content-Security-Policy" content="....">
	80	+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
	81	+ <title>....</title>
	82	+ <link rel="stylesheet" href="..." type="text/css">
	83	+ </head>
	84	+ <body class="FEATURE">
85	85
86	86	…where `FEATURE` is either the top-level URL element (e.g. `doc`) or a
87	87	feature class that groups multiple URLs under a single name such as
88	88	`forum` to contain `/forummain`, `/forumpost`, `/forume2`, etc. This
89	89	allows per-feature CSS such as
90	90
91		- body.forum div.markdown blockquote {
92		- margin-left: 10px;
93		- }
	91	+ body.forum div.markdown blockquote {
	92	+ margin-left: 10px;
	93	+ }
94	94
95	95	That is, affect HTML `<blockquote>` tags specially only for forum posts
96	96	written in Markdown, leaving all other block quotes alone.
97	97
98	98	In most cases, it is best to leave the Fossil-generated HTML Header
99	99	alone. (One exception is when the administrator needs to include links
100	100	to additional CSS files.) The configurable part of the skin begins
101	101	with the Content Header section which should follow this template:
102	102
103		- <div class="header">
104		- ... top banner and menu bar ...
105		- </div>
	103	+ <div class="header">
	104	+ ... top banner and menu bar ...
	105	+ </div>
106	106
107	107	Note that `<div class="header">` and `</div>` tags must be included in
108	108	the Content Header text of the skin. In other words, you, the
109	109	administrator, need to supply that text as part of your skin
110	110	customization.
111	111
112	112	The Fossil-generated Content section immediately follows the Content Header.
113	113	The Content section will looks like this:
114	114
115		- <div class="content">
116		- ... Fossil-generated content here ...
117		- </div>
	115	+ <div class="content">
	116	+ ... Fossil-generated content here ...
	117	+ </div>
118	118
119	119	After the Content is the custom Content Footer section which should
120	120	follow this template:
121	121
122		- <div class="footer">
123		- ... skin-specific stuff here ...
124		- </div>
	122	+ <div class="footer">
	123	+ ... skin-specific stuff here ...
	124	+ </div>
125	125
126	126	As with the Content Header, the template elements of the Content Footer
127	127	should appear exactly as they are shown.
128	128
129	129	Finally, Fossil always adds its own footer (unless overridden)
130	130	to close out the generated HTML:
131	131
132		- </body>
133		- </html>
	132	+ </body>
	133	+ </html>
134	134
135	135	## <a id="mainmenu"></a>Changing the Main Menu Contents
136	136
137	137	As of Fossil 2.15, the actual text content of the skin’s main menu is no
138	138	longer part of the skin proper if you’re using one of the stock skins.
		@@ -174,11 +174,11 @@
174	174	make incremental modifications, testing after each step, to obtain the
175	175	desired result.
176	176
177	177	The skin is controlled by five files:
178	178
179		-<blockquote><dl>
	179	+<dl>
180	180	<dt><b>css.txt</b></dt>
181	181
182	182	<dd>The css.txt file is the text of the CSS for Fossil.
183	183	Fossil might add additional CSS elements after
184	184	the css.txt file, if it sees that the css.txt omits some
		@@ -189,20 +189,20 @@
189	189
190	190	<dd>The details.txt file is short list of settings that control
191	191	the look and feel, mostly of the timeline. The default
192	192	details.txt file looks like this:
193	193
194		-<blockquote><pre>
	194	+<pre>
195	195	pikchr-background: ""
196	196	pikchr-fontscale: ""
197	197	pikchr-foreground: ""
198	198	pikchr-scale: ""
199	199	timeline-arrowheads: 1
200	200	timeline-circle-nodes: 1
201	201	timeline-color-graph-lines: 1
202	202	white-foreground: 0
203		-</pre></blockquote>
	203	+</pre>
204	204
205	205	The three "timeline-" settings in details.txt control the appearance
206	206	of certain aspects of the timeline graph. The number on the
207	207	right is a boolean - "1" to activate the feature and "0" to
208	208	disable it. The "white-foreground:" setting should be set to
		@@ -237,26 +237,26 @@
237	237	<dd>The js.txt file is optional. It is intended to be javascript.
238	238	The complete text of this javascript might be inserted into
239	239	the Content Footer, after being processed using TH1, using
240	240	code like the following in the "footer.txt" file:
241	241
242		-<blockquote><pre>
	242	+<pre>
243	243	<script nonce="$nonce">
244	244	<th1>styleScript</th1>
245	245	</script>
246		-</pre></blockquote>
	246	+</pre>
247	247
248	248	The js.txt file was originally used to insert javascript
249	249	that controls the hamburger menu in the default skin. More
250	250	recently, the javascript for the hamburger menu was moved into
251	251	a separate built-in file. Skins that use the hamburger menu
252	252	typically cause the javascript to be loaded by including the
253	253	following TH1 code in the "header.txt" file:
254	254
255		-<blockquote><pre>
	255	+<pre>
256	256	<th1>builtin_request_js hbmenu.js</th1>
257		-</pre></blockquote>
	257	+</pre>
258	258
259	259	The difference between styleScript and builtin_request_js
260	260	is that the styleScript command interprets the file
261	261	using TH1 and injects the content directly into the output
262	262	stream, whereas the builtin_request_js command inserts the
		@@ -269,11 +269,11 @@
269	269
270	270	Note that the "js.txt" file is not automatically inserted into
271	271	the generate HTML for a page. You, the skin designer, must
272	272	cause the javascript to be inserted by issuing appropriate
273	273	TH1 commands in the "header.txt" or "footer.txt" files.</dd>
274		-</dl></blockquote>
	274	+</dl>
275	275
276	276	Developing a new skin is simply a matter of creating appropriate
277	277	versions of these five control files.
278	278
279	279	### Skin Development Using The Web Interface
		@@ -329,17 +329,17 @@
329	329	the value of the TH1 variable NAME.
330	330
331	331	For example, first few lines of a typical Content Header will look
332	332	like this:
333	333
334		- <div class="header">
335		- <div class="title"><h1>$<project_name></h1>$<title>/div>
	334	+ <div class="header">
	335	+ <div class="title"><h1>$<project_name></h1>$<title>/div>
336	336
337	337	After variables are substituted by TH1, that will look more like this:
338	338
339		- <div class="header">
340		- <div class="title"><h1>Project Name</h1>Page Title</div>
	339	+ <div class="header">
	340	+ <div class="title"><h1>Project Name</h1>Page Title</div>
341	341
342	342	As you can see, two TH1 variable substitutions were done.
343	343
344	344	The same TH1 interpreter is used for both the header and the footer
345	345	and for all scripts contained within them both. Hence, any global
		@@ -355,12 +355,12 @@
355	355	that are part of Fossil.
356	356
357	357	The ≡ button for the hamburger menu is added to the menu bar by the following
358	358	TH1 commands in the `header.txt` file, right before the menu bar links:
359	359
360		- html "<a id='hbbtn' href='$home/sitemap'>☰</a>"
361		- builtin_request_js hbmenu.js
	360	+ html "<a id='hbbtn' href='$home/sitemap'>☰</a>"
	361	+ builtin_request_js hbmenu.js
362	362
363	363	The hamburger button can be repositioned between the other menu links (but the
364	364	drop-down menu is always left-aligned with the menu bar), or it can be removed
365	365	by deleting the above statements. The "html" statement inserts the appropriate
366	366	`<a>` for the hamburger menu button (some skins require something slightly
		@@ -370,40 +370,40 @@
370	370
371	371	The hbmenu.js script requires
372	372	the following `<div>` element somewhere in your header, in which to build
373	373	the hamburger menu.
374	374
375		- <div id='hbdrop'></div>
	375	+ <div id='hbdrop'></div>
376	376
377	377	Out of the box, the contents of the panel is populated with the [Site
378	378	Map](/sitemap), but only if the panel does not already contain any HTML
379	379	elements (that is, not just comments, plain text or non-presentational white
380	380	space). So the hamburger menu can be customized by replacing the empty `<div
381	381	id='hbdrop'></div>` element with a menu structure knitted according to the
382	382	following template:
383	383
384		- <div id="hbdrop" data-anim-ms="400">
385		- <ul class="columns" style="column-width: 20em; column-count: auto">
386		- <!-- NEW GROUP WITH HEADING LINK -->
387		- <li>
388		- <a href="$home$index_page">Link: Home</a>
389		- <ul>
390		- <li><a href="$home/timeline">Link: Timeline</a></li>
391		- <li><a href="$home/dir?ci=tip">Link: File List</a></li>
392		- </ul>
393		- </li>
394		- <!-- NEW GROUP WITH HEADING TEXT -->
395		- <li>
396		- Heading Text
397		- <ul>
398		- <li><a href="$home/doc/trunk/www/customskin.md">Link: Theming</a></li>
399		- <li><a href="$home/doc/trunk/www/th1.md">Link: TH1 Scripts</a></li>
400		- </ul>
401		- </li>
402		- <!-- NEXT GROUP GOES HERE -->
403		- </ul>
404		- </div>
	384	+ <div id="hbdrop" data-anim-ms="400">
	385	+ <ul class="columns" style="column-width: 20em; column-count: auto">
	386	+ <!-- NEW GROUP WITH HEADING LINK -->
	387	+ <li>
	388	+ <a href="$home$index_page">Link: Home</a>
	389	+ <ul>
	390	+ <li><a href="$home/timeline">Link: Timeline</a></li>
	391	+ <li><a href="$home/dir?ci=tip">Link: File List</a></li>
	392	+ </ul>
	393	+ </li>
	394	+ <!-- NEW GROUP WITH HEADING TEXT -->
	395	+ <li>
	396	+ Heading Text
	397	+ <ul>
	398	+ <li><a href="$home/doc/trunk/www/customskin.md">Link: Theming</a></li>
	399	+ <li><a href="$home/doc/trunk/www/th1.md">Link: TH1 Scripts</a></li>
	400	+ </ul>
	401	+ </li>
	402	+ <!-- NEXT GROUP GOES HERE -->
	403	+ </ul>
	404	+ </div>
405	405
406	406	The custom `data-anim-ms` attribute can be added to the panel element to direct
407	407	the Javascript logic to override the default menu animation duration of 400 ms.
408	408	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
409	409	animation is disabled by setting the attribute to `"0"`.
410	410

	--- www/customskin.md
	+++ www/customskin.md
	@@ -71,68 +71,68 @@
71
72	Fossil usually (but not always - [see below](#override))
73	generates the initial HTML Header section of a page. The
74	generated HTML Header will look something like this:
75
76	<html>
77	<head>
78	<base href="...">
79	<meta http-equiv="Content-Security-Policy" content="....">
80	<meta name="viewport" content="width=device-width, initial-scale=1.0">
81	<title>....</title>
82	<link rel="stylesheet" href="..." type="text/css">
83	</head>
84	<body class="FEATURE">
85
86	…where `FEATURE` is either the top-level URL element (e.g. `doc`) or a
87	feature class that groups multiple URLs under a single name such as
88	`forum` to contain `/forummain`, `/forumpost`, `/forume2`, etc. This
89	allows per-feature CSS such as
90
91	body.forum div.markdown blockquote {
92	margin-left: 10px;
93	}
94
95	That is, affect HTML `<blockquote>` tags specially only for forum posts
96	written in Markdown, leaving all other block quotes alone.
97
98	In most cases, it is best to leave the Fossil-generated HTML Header
99	alone. (One exception is when the administrator needs to include links
100	to additional CSS files.) The configurable part of the skin begins
101	with the Content Header section which should follow this template:
102
103	<div class="header">
104	... top banner and menu bar ...
105	</div>
106
107	Note that `<div class="header">` and `</div>` tags must be included in
108	the Content Header text of the skin. In other words, you, the
109	administrator, need to supply that text as part of your skin
110	customization.
111
112	The Fossil-generated Content section immediately follows the Content Header.
113	The Content section will looks like this:
114
115	<div class="content">
116	... Fossil-generated content here ...
117	</div>
118
119	After the Content is the custom Content Footer section which should
120	follow this template:
121
122	<div class="footer">
123	... skin-specific stuff here ...
124	</div>
125
126	As with the Content Header, the template elements of the Content Footer
127	should appear exactly as they are shown.
128
129	Finally, Fossil always adds its own footer (unless overridden)
130	to close out the generated HTML:
131
132	</body>
133	</html>
134
135	## <a id="mainmenu"></a>Changing the Main Menu Contents
136
137	As of Fossil 2.15, the actual text content of the skin’s main menu is no
138	longer part of the skin proper if you’re using one of the stock skins.
	@@ -174,11 +174,11 @@
174	make incremental modifications, testing after each step, to obtain the
175	desired result.
176
177	The skin is controlled by five files:
178
179	<blockquote><dl>
180	<dt><b>css.txt</b></dt>
181
182	<dd>The css.txt file is the text of the CSS for Fossil.
183	Fossil might add additional CSS elements after
184	the css.txt file, if it sees that the css.txt omits some
	@@ -189,20 +189,20 @@
189
190	<dd>The details.txt file is short list of settings that control
191	the look and feel, mostly of the timeline. The default
192	details.txt file looks like this:
193
194	<blockquote><pre>
195	pikchr-background: ""
196	pikchr-fontscale: ""
197	pikchr-foreground: ""
198	pikchr-scale: ""
199	timeline-arrowheads: 1
200	timeline-circle-nodes: 1
201	timeline-color-graph-lines: 1
202	white-foreground: 0
203	</pre></blockquote>
204
205	The three "timeline-" settings in details.txt control the appearance
206	of certain aspects of the timeline graph. The number on the
207	right is a boolean - "1" to activate the feature and "0" to
208	disable it. The "white-foreground:" setting should be set to
	@@ -237,26 +237,26 @@
237	<dd>The js.txt file is optional. It is intended to be javascript.
238	The complete text of this javascript might be inserted into
239	the Content Footer, after being processed using TH1, using
240	code like the following in the "footer.txt" file:
241
242	<blockquote><pre>
243	<script nonce="$nonce">
244	<th1>styleScript</th1>
245	</script>
246	</pre></blockquote>
247
248	The js.txt file was originally used to insert javascript
249	that controls the hamburger menu in the default skin. More
250	recently, the javascript for the hamburger menu was moved into
251	a separate built-in file. Skins that use the hamburger menu
252	typically cause the javascript to be loaded by including the
253	following TH1 code in the "header.txt" file:
254
255	<blockquote><pre>
256	<th1>builtin_request_js hbmenu.js</th1>
257	</pre></blockquote>
258
259	The difference between styleScript and builtin_request_js
260	is that the styleScript command interprets the file
261	using TH1 and injects the content directly into the output
262	stream, whereas the builtin_request_js command inserts the
	@@ -269,11 +269,11 @@
269
270	Note that the "js.txt" file is not automatically inserted into
271	the generate HTML for a page. You, the skin designer, must
272	cause the javascript to be inserted by issuing appropriate
273	TH1 commands in the "header.txt" or "footer.txt" files.</dd>
274	</dl></blockquote>
275
276	Developing a new skin is simply a matter of creating appropriate
277	versions of these five control files.
278
279	### Skin Development Using The Web Interface
	@@ -329,17 +329,17 @@
329	the value of the TH1 variable NAME.
330
331	For example, first few lines of a typical Content Header will look
332	like this:
333
334	<div class="header">
335	<div class="title"><h1>$<project_name></h1>$<title>/div>
336
337	After variables are substituted by TH1, that will look more like this:
338
339	<div class="header">
340	<div class="title"><h1>Project Name</h1>Page Title</div>
341
342	As you can see, two TH1 variable substitutions were done.
343
344	The same TH1 interpreter is used for both the header and the footer
345	and for all scripts contained within them both. Hence, any global
	@@ -355,12 +355,12 @@
355	that are part of Fossil.
356
357	The ≡ button for the hamburger menu is added to the menu bar by the following
358	TH1 commands in the `header.txt` file, right before the menu bar links:
359
360	html "<a id='hbbtn' href='$home/sitemap'>☰</a>"
361	builtin_request_js hbmenu.js
362
363	The hamburger button can be repositioned between the other menu links (but the
364	drop-down menu is always left-aligned with the menu bar), or it can be removed
365	by deleting the above statements. The "html" statement inserts the appropriate
366	`<a>` for the hamburger menu button (some skins require something slightly
	@@ -370,40 +370,40 @@
370
371	The hbmenu.js script requires
372	the following `<div>` element somewhere in your header, in which to build
373	the hamburger menu.
374
375	<div id='hbdrop'></div>
376
377	Out of the box, the contents of the panel is populated with the [Site
378	Map](/sitemap), but only if the panel does not already contain any HTML
379	elements (that is, not just comments, plain text or non-presentational white
380	space). So the hamburger menu can be customized by replacing the empty `<div
381	id='hbdrop'></div>` element with a menu structure knitted according to the
382	following template:
383
384	<div id="hbdrop" data-anim-ms="400">
385	<ul class="columns" style="column-width: 20em; column-count: auto">
386	<!-- NEW GROUP WITH HEADING LINK -->
387	<li>
388	<a href="$home$index_page">Link: Home</a>
389	<ul>
390	<li><a href="$home/timeline">Link: Timeline</a></li>
391	<li><a href="$home/dir?ci=tip">Link: File List</a></li>
392	</ul>
393	</li>
394	<!-- NEW GROUP WITH HEADING TEXT -->
395	<li>
396	Heading Text
397	<ul>
398	<li><a href="$home/doc/trunk/www/customskin.md">Link: Theming</a></li>
399	<li><a href="$home/doc/trunk/www/th1.md">Link: TH1 Scripts</a></li>
400	</ul>
401	</li>
402	<!-- NEXT GROUP GOES HERE -->
403	</ul>
404	</div>
405
406	The custom `data-anim-ms` attribute can be added to the panel element to direct
407	the Javascript logic to override the default menu animation duration of 400 ms.
408	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
409	animation is disabled by setting the attribute to `"0"`.
410

	--- www/customskin.md
	+++ www/customskin.md
	@@ -71,68 +71,68 @@
71
72	Fossil usually (but not always - [see below](#override))
73	generates the initial HTML Header section of a page. The
74	generated HTML Header will look something like this:
75
76	<html>
77	<head>
78	<base href="...">
79	<meta http-equiv="Content-Security-Policy" content="....">
80	<meta name="viewport" content="width=device-width, initial-scale=1.0">
81	<title>....</title>
82	<link rel="stylesheet" href="..." type="text/css">
83	</head>
84	<body class="FEATURE">
85
86	…where `FEATURE` is either the top-level URL element (e.g. `doc`) or a
87	feature class that groups multiple URLs under a single name such as
88	`forum` to contain `/forummain`, `/forumpost`, `/forume2`, etc. This
89	allows per-feature CSS such as
90
91	body.forum div.markdown blockquote {
92	margin-left: 10px;
93	}
94
95	That is, affect HTML `<blockquote>` tags specially only for forum posts
96	written in Markdown, leaving all other block quotes alone.
97
98	In most cases, it is best to leave the Fossil-generated HTML Header
99	alone. (One exception is when the administrator needs to include links
100	to additional CSS files.) The configurable part of the skin begins
101	with the Content Header section which should follow this template:
102
103	<div class="header">
104	... top banner and menu bar ...
105	</div>
106
107	Note that `<div class="header">` and `</div>` tags must be included in
108	the Content Header text of the skin. In other words, you, the
109	administrator, need to supply that text as part of your skin
110	customization.
111
112	The Fossil-generated Content section immediately follows the Content Header.
113	The Content section will looks like this:
114
115	<div class="content">
116	... Fossil-generated content here ...
117	</div>
118
119	After the Content is the custom Content Footer section which should
120	follow this template:
121
122	<div class="footer">
123	... skin-specific stuff here ...
124	</div>
125
126	As with the Content Header, the template elements of the Content Footer
127	should appear exactly as they are shown.
128
129	Finally, Fossil always adds its own footer (unless overridden)
130	to close out the generated HTML:
131
132	</body>
133	</html>
134
135	## <a id="mainmenu"></a>Changing the Main Menu Contents
136
137	As of Fossil 2.15, the actual text content of the skin’s main menu is no
138	longer part of the skin proper if you’re using one of the stock skins.
	@@ -174,11 +174,11 @@
174	make incremental modifications, testing after each step, to obtain the
175	desired result.
176
177	The skin is controlled by five files:
178
179	<dl>
180	<dt><b>css.txt</b></dt>
181
182	<dd>The css.txt file is the text of the CSS for Fossil.
183	Fossil might add additional CSS elements after
184	the css.txt file, if it sees that the css.txt omits some
	@@ -189,20 +189,20 @@
189
190	<dd>The details.txt file is short list of settings that control
191	the look and feel, mostly of the timeline. The default
192	details.txt file looks like this:
193
194	<pre>
195	pikchr-background: ""
196	pikchr-fontscale: ""
197	pikchr-foreground: ""
198	pikchr-scale: ""
199	timeline-arrowheads: 1
200	timeline-circle-nodes: 1
201	timeline-color-graph-lines: 1
202	white-foreground: 0
203	</pre>
204
205	The three "timeline-" settings in details.txt control the appearance
206	of certain aspects of the timeline graph. The number on the
207	right is a boolean - "1" to activate the feature and "0" to
208	disable it. The "white-foreground:" setting should be set to
	@@ -237,26 +237,26 @@
237	<dd>The js.txt file is optional. It is intended to be javascript.
238	The complete text of this javascript might be inserted into
239	the Content Footer, after being processed using TH1, using
240	code like the following in the "footer.txt" file:
241
242	<pre>
243	<script nonce="$nonce">
244	<th1>styleScript</th1>
245	</script>
246	</pre>
247
248	The js.txt file was originally used to insert javascript
249	that controls the hamburger menu in the default skin. More
250	recently, the javascript for the hamburger menu was moved into
251	a separate built-in file. Skins that use the hamburger menu
252	typically cause the javascript to be loaded by including the
253	following TH1 code in the "header.txt" file:
254
255	<pre>
256	<th1>builtin_request_js hbmenu.js</th1>
257	</pre>
258
259	The difference between styleScript and builtin_request_js
260	is that the styleScript command interprets the file
261	using TH1 and injects the content directly into the output
262	stream, whereas the builtin_request_js command inserts the
	@@ -269,11 +269,11 @@
269
270	Note that the "js.txt" file is not automatically inserted into
271	the generate HTML for a page. You, the skin designer, must
272	cause the javascript to be inserted by issuing appropriate
273	TH1 commands in the "header.txt" or "footer.txt" files.</dd>
274	</dl>
275
276	Developing a new skin is simply a matter of creating appropriate
277	versions of these five control files.
278
279	### Skin Development Using The Web Interface
	@@ -329,17 +329,17 @@
329	the value of the TH1 variable NAME.
330
331	For example, first few lines of a typical Content Header will look
332	like this:
333
334	<div class="header">
335	<div class="title"><h1>$<project_name></h1>$<title>/div>
336
337	After variables are substituted by TH1, that will look more like this:
338
339	<div class="header">
340	<div class="title"><h1>Project Name</h1>Page Title</div>
341
342	As you can see, two TH1 variable substitutions were done.
343
344	The same TH1 interpreter is used for both the header and the footer
345	and for all scripts contained within them both. Hence, any global
	@@ -355,12 +355,12 @@
355	that are part of Fossil.
356
357	The ≡ button for the hamburger menu is added to the menu bar by the following
358	TH1 commands in the `header.txt` file, right before the menu bar links:
359
360	html "<a id='hbbtn' href='$home/sitemap'>☰</a>"
361	builtin_request_js hbmenu.js
362
363	The hamburger button can be repositioned between the other menu links (but the
364	drop-down menu is always left-aligned with the menu bar), or it can be removed
365	by deleting the above statements. The "html" statement inserts the appropriate
366	`<a>` for the hamburger menu button (some skins require something slightly
	@@ -370,40 +370,40 @@
370
371	The hbmenu.js script requires
372	the following `<div>` element somewhere in your header, in which to build
373	the hamburger menu.
374
375	<div id='hbdrop'></div>
376
377	Out of the box, the contents of the panel is populated with the [Site
378	Map](/sitemap), but only if the panel does not already contain any HTML
379	elements (that is, not just comments, plain text or non-presentational white
380	space). So the hamburger menu can be customized by replacing the empty `<div
381	id='hbdrop'></div>` element with a menu structure knitted according to the
382	following template:
383
384	<div id="hbdrop" data-anim-ms="400">
385	<ul class="columns" style="column-width: 20em; column-count: auto">
386	<!-- NEW GROUP WITH HEADING LINK -->
387	<li>
388	<a href="$home$index_page">Link: Home</a>
389	<ul>
390	<li><a href="$home/timeline">Link: Timeline</a></li>
391	<li><a href="$home/dir?ci=tip">Link: File List</a></li>
392	</ul>
393	</li>
394	<!-- NEW GROUP WITH HEADING TEXT -->
395	<li>
396	Heading Text
397	<ul>
398	<li><a href="$home/doc/trunk/www/customskin.md">Link: Theming</a></li>
399	<li><a href="$home/doc/trunk/www/th1.md">Link: TH1 Scripts</a></li>
400	</ul>
401	</li>
402	<!-- NEXT GROUP GOES HERE -->
403	</ul>
404	</div>
405
406	The custom `data-anim-ms` attribute can be added to the panel element to direct
407	the Javascript logic to override the default menu animation duration of 400 ms.
408	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
409	animation is disabled by setting the attribute to `"0"`.
410

M www/makefile.wiki

+14 -14

		--- www/makefile.wiki
		+++ www/makefile.wiki
		@@ -146,13 +146,13 @@
146	146	a C program: tools/mkversion.c.
147	147	To run the VERSION.h generator, first compile the tools/mkversion.c
148	148	source file into a command-line program (named "mkversion.exe")
149	149	then run:
150	150
151		-<blockquote><pre>
	151	+<pre>
152	152	mkversion.exe manifest.uuid manifest VERSION >VERSION.h
153		-</pre></blockquote>
	153	+</pre>
154	154
155	155	The pathnames in the above command might need to be adjusted to get the
156	156	directories right. The point is that the manifest.uuid, manifest, and
157	157	VERSION files
158	158	in the root of the source tree are the three arguments and
		@@ -161,13 +161,13 @@
161	161	The builtin_data.h header file is generated by a C program: tools/mkbuiltin.c.
162	162	The builtin_data.h file contains C-language byte-array definitions for
163	163	the content of resource files used by Fossil. To generate the
164	164	builtin_data.h file, first compile the mkbuiltin.c program, then run:
165	165
166		-<blockquote><pre>
	166	+<pre>
167	167	mkbuiltin.exe diff.tcl <i>OtherFiles...</i> >builtin_data.h
168		-</pre></blockquote>
	168	+</pre>
169	169
170	170	At the time of this writing, the "diff.tcl" script (a Tcl/Tk script used
171	171	to generate implement --tk option on the diff command) is the only resource
172	172	file processed using mkbuiltin.exe. However, new resources will likely be
173	173	added using this facility in future versions of Fossil.
		@@ -185,13 +185,13 @@
185	185	web interface methods, and help text comments. The mkindex program
186	186	generates some C code that Fossil uses in order to dispatch commands and
187	187	HTTP requests and to show on-line help. Compile the mkindex program
188	188	from the mkindex.c source file. Then run:
189	189
190		-<blockquote><pre>
	190	+<pre>
191	191	./mkindex src.c >page_index.h
192		-</pre></blockquote>
	192	+</pre>
193	193
194	194	Note that "src.c" in the above is a stand-in for the (79) regular source
195	195	files of Fossil - all source files except for the exceptions described in
196	196	section 2.0 above.
197	197
		@@ -205,13 +205,13 @@
205	205	context) into special "printf" operations for generating the output of
206	206	an HTTP request. The translate preprocessor is a simple C program whose
207	207	sources are in the translate.c source file. The translate preprocess
208	208	is run on each of the other ordinary source files separately, like this:
209	209
210		-<blockquote><pre>
	210	+<pre>
211	211	./translate src.c >src_.c
212		-</pre></blockquote>
	212	+</pre>
213	213
214	214	In this case, the "src.c" file represents any single source file from the
215	215	set of ordinary source files as described in section 2.0 above. Note that
216	216	each source file is translated separately. By convention, the names of
217	217	the translated source files are the names of the input sources with a
		@@ -235,13 +235,13 @@
235	235	source files are not scanned by makeheaders. Makeheaders only runs over
236	236	"ordinary" source files, not the exceptional source files. However,
237	237	makeheaders also uses some extra header files as input. The general format
238	238	is like this:
239	239
240		-<blockquote><pre>
	240	+<pre>
241	241	makeheaders src_.c:src.h sqlite3.h th.h VERSION.h
242		-</pre></blockquote>
	242	+</pre>
243	243
244	244	In the example above the "src_.c" and "src.h" names represent all of the
245	245	(79) ordinary C source files, each as a separate argument.
246	246
247	247	<h1>5.0 Compilation</h1>
		@@ -304,18 +304,18 @@
304	304	Debug flags are consistently applied across the whole build process. For
305	305	example, use these Debug flags in addition to other flags passed to the
306	306	configure scripts:
307	307
308	308	On Linux, *NIX and similar platforms:
309		-<blockquote><pre>
	309	+<pre>
310	310	./configure --fossil-debug
311		-</pre></blockquote>
	311	+</pre>
312	312
313	313	On Windows:
314		-<blockquote><pre>
	314	+<pre>
315	315	win\buildmsvc.bat FOSSIL_DEBUG=1
316		-</pre></blockquote>
	316	+</pre>
317	317
318	318	The resulting fossil binary could then be loaded into a platform-specific
319	319	debugger. Source files displayed in the debugger correspond to the ones
320	320	generated from the translation stage of the build process, that is what was
321	321	actually compiled into the object files.
322	322

	--- www/makefile.wiki
	+++ www/makefile.wiki
	@@ -146,13 +146,13 @@
146	a C program: tools/mkversion.c.
147	To run the VERSION.h generator, first compile the tools/mkversion.c
148	source file into a command-line program (named "mkversion.exe")
149	then run:
150
151	<blockquote><pre>
152	mkversion.exe manifest.uuid manifest VERSION >VERSION.h
153	</pre></blockquote>
154
155	The pathnames in the above command might need to be adjusted to get the
156	directories right. The point is that the manifest.uuid, manifest, and
157	VERSION files
158	in the root of the source tree are the three arguments and
	@@ -161,13 +161,13 @@
161	The builtin_data.h header file is generated by a C program: tools/mkbuiltin.c.
162	The builtin_data.h file contains C-language byte-array definitions for
163	the content of resource files used by Fossil. To generate the
164	builtin_data.h file, first compile the mkbuiltin.c program, then run:
165
166	<blockquote><pre>
167	mkbuiltin.exe diff.tcl <i>OtherFiles...</i> >builtin_data.h
168	</pre></blockquote>
169
170	At the time of this writing, the "diff.tcl" script (a Tcl/Tk script used
171	to generate implement --tk option on the diff command) is the only resource
172	file processed using mkbuiltin.exe. However, new resources will likely be
173	added using this facility in future versions of Fossil.
	@@ -185,13 +185,13 @@
185	web interface methods, and help text comments. The mkindex program
186	generates some C code that Fossil uses in order to dispatch commands and
187	HTTP requests and to show on-line help. Compile the mkindex program
188	from the mkindex.c source file. Then run:
189
190	<blockquote><pre>
191	./mkindex src.c >page_index.h
192	</pre></blockquote>
193
194	Note that "src.c" in the above is a stand-in for the (79) regular source
195	files of Fossil - all source files except for the exceptions described in
196	section 2.0 above.
197
	@@ -205,13 +205,13 @@
205	context) into special "printf" operations for generating the output of
206	an HTTP request. The translate preprocessor is a simple C program whose
207	sources are in the translate.c source file. The translate preprocess
208	is run on each of the other ordinary source files separately, like this:
209
210	<blockquote><pre>
211	./translate src.c >src_.c
212	</pre></blockquote>
213
214	In this case, the "src.c" file represents any single source file from the
215	set of ordinary source files as described in section 2.0 above. Note that
216	each source file is translated separately. By convention, the names of
217	the translated source files are the names of the input sources with a
	@@ -235,13 +235,13 @@
235	source files are not scanned by makeheaders. Makeheaders only runs over
236	"ordinary" source files, not the exceptional source files. However,
237	makeheaders also uses some extra header files as input. The general format
238	is like this:
239
240	<blockquote><pre>
241	makeheaders src_.c:src.h sqlite3.h th.h VERSION.h
242	</pre></blockquote>
243
244	In the example above the "src_.c" and "src.h" names represent all of the
245	(79) ordinary C source files, each as a separate argument.
246
247	<h1>5.0 Compilation</h1>
	@@ -304,18 +304,18 @@
304	Debug flags are consistently applied across the whole build process. For
305	example, use these Debug flags in addition to other flags passed to the
306	configure scripts:
307
308	On Linux, *NIX and similar platforms:
309	<blockquote><pre>
310	./configure --fossil-debug
311	</pre></blockquote>
312
313	On Windows:
314	<blockquote><pre>
315	win\buildmsvc.bat FOSSIL_DEBUG=1
316	</pre></blockquote>
317
318	The resulting fossil binary could then be loaded into a platform-specific
319	debugger. Source files displayed in the debugger correspond to the ones
320	generated from the translation stage of the build process, that is what was
321	actually compiled into the object files.
322

	--- www/makefile.wiki
	+++ www/makefile.wiki
	@@ -146,13 +146,13 @@
146	a C program: tools/mkversion.c.
147	To run the VERSION.h generator, first compile the tools/mkversion.c
148	source file into a command-line program (named "mkversion.exe")
149	then run:
150
151	<pre>
152	mkversion.exe manifest.uuid manifest VERSION >VERSION.h
153	</pre>
154
155	The pathnames in the above command might need to be adjusted to get the
156	directories right. The point is that the manifest.uuid, manifest, and
157	VERSION files
158	in the root of the source tree are the three arguments and
	@@ -161,13 +161,13 @@
161	The builtin_data.h header file is generated by a C program: tools/mkbuiltin.c.
162	The builtin_data.h file contains C-language byte-array definitions for
163	the content of resource files used by Fossil. To generate the
164	builtin_data.h file, first compile the mkbuiltin.c program, then run:
165
166	<pre>
167	mkbuiltin.exe diff.tcl <i>OtherFiles...</i> >builtin_data.h
168	</pre>
169
170	At the time of this writing, the "diff.tcl" script (a Tcl/Tk script used
171	to generate implement --tk option on the diff command) is the only resource
172	file processed using mkbuiltin.exe. However, new resources will likely be
173	added using this facility in future versions of Fossil.
	@@ -185,13 +185,13 @@
185	web interface methods, and help text comments. The mkindex program
186	generates some C code that Fossil uses in order to dispatch commands and
187	HTTP requests and to show on-line help. Compile the mkindex program
188	from the mkindex.c source file. Then run:
189
190	<pre>
191	./mkindex src.c >page_index.h
192	</pre>
193
194	Note that "src.c" in the above is a stand-in for the (79) regular source
195	files of Fossil - all source files except for the exceptions described in
196	section 2.0 above.
197
	@@ -205,13 +205,13 @@
205	context) into special "printf" operations for generating the output of
206	an HTTP request. The translate preprocessor is a simple C program whose
207	sources are in the translate.c source file. The translate preprocess
208	is run on each of the other ordinary source files separately, like this:
209
210	<pre>
211	./translate src.c >src_.c
212	</pre>
213
214	In this case, the "src.c" file represents any single source file from the
215	set of ordinary source files as described in section 2.0 above. Note that
216	each source file is translated separately. By convention, the names of
217	the translated source files are the names of the input sources with a
	@@ -235,13 +235,13 @@
235	source files are not scanned by makeheaders. Makeheaders only runs over
236	"ordinary" source files, not the exceptional source files. However,
237	makeheaders also uses some extra header files as input. The general format
238	is like this:
239
240	<pre>
241	makeheaders src_.c:src.h sqlite3.h th.h VERSION.h
242	</pre>
243
244	In the example above the "src_.c" and "src.h" names represent all of the
245	(79) ordinary C source files, each as a separate argument.
246
247	<h1>5.0 Compilation</h1>
	@@ -304,18 +304,18 @@
304	Debug flags are consistently applied across the whole build process. For
305	example, use these Debug flags in addition to other flags passed to the
306	configure scripts:
307
308	On Linux, *NIX and similar platforms:
309	<pre>
310	./configure --fossil-debug
311	</pre>
312
313	On Windows:
314	<pre>
315	win\buildmsvc.bat FOSSIL_DEBUG=1
316	</pre>
317
318	The resulting fossil binary could then be loaded into a platform-specific
319	debugger. Source files displayed in the debugger correspond to the ones
320	generated from the translation stage of the build process, that is what was
321	actually compiled into the object files.
322

M www/sync.wiki

+47 -57

		--- www/sync.wiki
		+++ www/sync.wiki
		@@ -130,34 +130,30 @@
130	130
131	131	The client modifies the URL by appending the method name "<b>/xfer</b>"
132	132	to the end. For example, if the URL specified on the client command
133	133	line is
134	134
135		-<blockquote>
136		-https://fossil-scm.org/fossil
137		-</blockquote>
	135	+<pre>https://fossil-scm.org/fossil</pre>
138	136
139	137	Then the URL that is really used to do the synchronization will
140	138	be:
141	139
142		-<blockquote>
143		-https://fossil-scm.org/fossil/xfer
144		-</blockquote>
	140	+<pre>https://fossil-scm.org/fossil/xfer</pre>
145	141
146	142	<h3>2.2 HTTP Request Format</h3>
147	143
148	144	The client always sends a POST request to the server. The
149	145	general format of the POST request is as follows:
150	146
151		-<blockquote><pre>
	147	+<pre>
152	148	POST /fossil/xfer HTTP/1.0
153	149	Host: fossil-scm.hwaci.com:80
154	150	Content-Type: application/x-fossil
155	151	Content-Length: 4216
	152	+</pre>
156	153
157		-<i>content...</i>
158		-</pre></blockquote>
	154	+<i><pre>content...</pre></i>
159	155
160	156	In the example above, the pathname given after the POST keyword
161	157	on the first line is a copy of the URL pathname. The Host: parameter
162	158	is also taken from the URL. The content type is always either
163	159	"application/x-fossil" or "application/x-fossil-debug". The "x-fossil"
		@@ -165,20 +161,20 @@
165	161	content is compressed using zlib whereas "x-fossil-debug" is sent
166	162	uncompressed.
167	163
168	164	A typical reply from the server might look something like this:
169	165
170		-<blockquote><pre>
	166	+<pre>
171	167	HTTP/1.0 200 OK
172	168	Date: Mon, 10 Sep 2007 12:21:01 GMT
173	169	Connection: close
174	170	Cache-control: private
175	171	Content-Type: application/x-fossil; charset=US-ASCII
176	172	Content-Length: 265
	173	+</pre>
177	174
178		-<i>content...</i>
179		-</pre></blockquote>
	175	+<i><pre>content...</pre></i>
180	176
181	177	The content type of the reply is always the same as the content type
182	178	of the request.
183	179
184	180	<h2>3.0 Fossil Synchronization Content</h2>
		@@ -202,13 +198,11 @@
202	198	<h3>3.2 Login Cards</h3>
203	199
204	200	Every message from client to server begins with one or more login
205	201	cards. Each login card has the following format:
206	202
207		-<blockquote>
208		-<b>login</b> <i>userid nonce signature</i>
209		-</blockquote>
	203	+<pre><b>login</b> <i>userid nonce signature</i></pre>
210	204
211	205	The userid is the name of the user that is requesting service
212	206	from the server. The nonce is the SHA1 hash of the remainder of
213	207	the message - all text that follows the newline character that
214	208	terminates the login card. The signature is the SHA1 hash of
		@@ -241,14 +235,14 @@
241	235	cards. File cards come in two different formats depending
242	236	on whether the artifact is sent directly or as a
243	237	[./delta_format.wiki\|delta] from some
244	238	other artifact.
245	239
246		-<blockquote>
247		-<b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i><br>
	240	+<pre>
	241	+<b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i>
248	242	<b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
249		-</blockquote>
	243	+</pre>
250	244
251	245	File cards are followed by in-line "payload" data.
252	246	The content of the artifact
253	247	or the artifact delta is the first <i>size</i> bytes of the
254	248	x-fossil content that immediately follow the newline that
		@@ -282,14 +276,14 @@
282	276	in-line "payload" data characteristics and also the same treatment of
283	277	direct content or delta content. Cfile cards come in two different formats
284	278	depending on whether the artifact is sent directly or as a delta from
285	279	some other artifact.
286	280
287		-<blockquote>
288		-<b>cfile</b> <i>artifact-id usize csize</i> <b>\n</b> <i>content</i><br>
289		-<b>cfile</b> <i>artifact-id delta-artifact-id usize csize</i> <b>\n</b> <i>content</i><br>
290		-</blockquote>
	281	+<pre>
	282	+<b>cfile</b> <i>artifact-id usize csize</i> <b>\n</b> <i>content</i>
	283	+<b>cfile</b> <i>artifact-id delta-artifact-id usize csize</i> <b>\n</b> <i>content</i>
	284	+</pre>
291	285
292	286	The first argument of the cfile card is the ID of the artifact that
293	287	is being transferred. The artifact ID is the lower-case hexadecimal
294	288	representation of the name hash for the artifact. The second argument of
295	289	the cfile card is the original size in bytes of the artifact. The last
		@@ -311,25 +305,21 @@
311	305	the [/help?cmd=sync\|fossil sync] command includes the "--private" option.
312	306
313	307
314	308	Private content is marked by a "private" card:
315	309
316		-<blockquote>
317		-<b>private</b>
318		-</blockquote>
	310	+<pre><b>private</b></pre>
319	311
320	312	The private card has no arguments and must directly precede a
321	313	file card that contains the private content.
322	314
323	315	<h4>3.3.4 Unversioned File Cards</h4>
324	316
325	317	Unversioned content is sent in both directions (client to server and
326	318	server to client) using "uvfile" cards in the following format:
327	319
328		-<blockquote>
329		-<b>uvfile</b> <i>name mtime hash size flags</i> <b>\n</b> <i>content</i>
330		-</blockquote>
	320	+<pre><b>uvfile</b> <i>name mtime hash size flags</i> <b>\n</b> <i>content</i></pre>
331	321
332	322	The <i>name</i> field is the name of the unversioned file. The
333	323	<i>mtime</i> is the last modification time of the file in seconds
334	324	since 1970. The <i>hash</i> field is the hash of the content
335	325	for the unversioned file, or "<b>-</b>" for deleted content.
		@@ -360,14 +350,14 @@
360	350	the push and pull cards. The push card tells the server that
361	351	the client is pushing content. The pull card tells the server
362	352	that the client wants to pull content. In the event of a sync,
363	353	both cards are sent. The format is as follows:
364	354
365		-<blockquote>
366		-<b>push</b> <i>servercode projectcode</i><br>
	355	+<pre>
	356	+<b>push</b> <i>servercode projectcode</i>
367	357	<b>pull</b> <i>servercode projectcode</i>
368		-</blockquote>
	358	+</pre>
369	359
370	360	The <i>servercode</i> argument is the repository ID for the
371	361	client. The <i>projectcode</i> is the identifier
372	362	of the software project that the client repository contains.
373	363	The projectcode for the client and server must match in order
		@@ -385,14 +375,14 @@
385	375	client to server in order to tell the server that the client
386	376	wants to pull content. The clone card comes in two formats. Older
387	377	clients use the no-argument format and newer clients use the
388	378	two-argument format.
389	379
390		-<blockquote>
391		-<b>clone</b><br>
	380	+<pre>
	381	+<b>clone</b>
392	382	<b>clone</b> <i>protocol-version sequence-number</i>
393		-</blockquote>
	383	+</pre>
394	384
395	385	<h4>3.5.1 Protocol 3</h4>
396	386
397	387	The latest clients send a two-argument clone message with a
398	388	protocol version of "3". (Future versions of Fossil might use larger
		@@ -409,13 +399,13 @@
409	399	cards for some number of artifacts up to the maximum message size.
410	400
411	401	The server will also send a single "clone_seqno" card to the client
412	402	so that the client can know where the server left off.
413	403
414		-<blockquote>
	404	+<pre>
415	405	<b>clone_seqno</b> <i>sequence-number</i>
416		-</blockquote>
	406	+</pre>
417	407
418	408	The clone message in subsequent HTTP requests for the same clone
419	409	operation will use the sequence-number from the
420	410	clone_seqno of the previous reply.
421	411
		@@ -440,13 +430,13 @@
440	430
441	431	An igot card can be sent from either client to server or from
442	432	server to client in order to indicate that the sender holds a copy
443	433	of a particular artifact. The format is:
444	434
445		-<blockquote>
	435	+<pre>
446	436	<b>igot</b> <i>artifact-id</i> ?<i>flag</i>?
447		-</blockquote>
	437	+</pre>
448	438
449	439	The first argument of the igot card is the ID of the artifact that
450	440	the sender possesses.
451	441	The receiver of an igot card will typically check to see if
452	442	it also holds the same artifact and if not it will request the artifact
		@@ -463,13 +453,13 @@
463	453
464	454	Zero or more "uvigot" cards are sent from server to client when
465	455	synchronizing unversioned content. The format of a uvigot card is
466	456	as follows:
467	457
468		-<blockquote>
	458	+<pre>
469	459	<b>uvigot</b> <i>name mtime hash size</i>
470		-</blockquote>
	460	+</pre>
471	461
472	462	The <i>name</i> argument is the name of an unversioned file.
473	463	The <i>mtime</i> is the last modification time of the unversioned file
474	464	in seconds since 1970.
475	465	The <i>hash</i> is the SHA1 or SHA3-256 hash of the unversioned file
		@@ -495,13 +485,13 @@
495	485
496	486	A gimme card is sent from either client to server or from server
497	487	to client. The gimme card asks the receiver to send a particular
498	488	artifact back to the sender. The format of a gimme card is this:
499	489
500		-<blockquote>
	490	+<pre>
501	491	<b>gimme</b> <i>artifact-id</i>
502		-</blockquote>
	492	+</pre>
503	493
504	494	The argument to the gimme card is the ID of the artifact that
505	495	the sender wants. The receiver will typically respond to a
506	496	gimme card by sending a file card in its reply or in the next
507	497	message.
		@@ -515,13 +505,13 @@
515	505	Sync synchronizing unversioned content, the client may send "uvgimme"
516	506	cards to the server. A uvgimme card requests that the server send
517	507	unversioned content to the client. The format of a uvgimme card is
518	508	as follows:
519	509
520		-<blockquote>
	510	+<pre>
521	511	<b>uvgimme</b> <i>name</i>
522		-</blockquote>
	512	+</pre>
523	513
524	514	The <i>name</i> is the name of the unversioned file found on the
525	515	server that the client would like to have. When a server sees a
526	516	uvgimme card, it normally responses with a uvfile card, though it might
527	517	also send another uvigot card if the HTTP reply is already oversized.
		@@ -532,13 +522,13 @@
532	522	of state information on a client. The server sends a cookie to the
533	523	client. The client sends the same cookie back to the server on
534	524	its next request. The cookie card has a single argument which
535	525	is its payload.
536	526
537		-<blockquote>
	527	+<pre>
538	528	<b>cookie</b> <i>payload</i>
539		-</blockquote>
	529	+</pre>
540	530
541	531	The client is not required to return the cookie to the server on
542	532	its next request. Or the client might send a cookie from a different
543	533	server on the next request. So the server must not depend on the
544	534	cookie and the server must structure the cookie payload in such
		@@ -558,13 +548,13 @@
558	548	data elements.
559	549
560	550	The reqconfig card is normally sent in response to the
561	551	"fossil configuration pull" command. The format is as follows:
562	552
563		-<blockquote>
	553	+<pre>
564	554	<b>reqconfig</b> <i>configuration-name</i>
565		-</blockquote>
	555	+</pre>
566	556
567	557	As of 2018-06-04, the configuration-name must be one of the
568	558	following values:
569	559
570	560	<table border=0 align="center">
		@@ -603,11 +593,11 @@
603	593	<li> crlf-glob
604	594	<ul></td><td valign="top"><ul>
605	595	<li> crnl-glob
606	596	<li> encoding-glob
607	597	<li> empty-dirs
608		-<li> <s>allow-symlinks</s> (removed 2020-08, version 2.12.1)
	598	+<li> <s title="removed 2020-08, version 2.12.1">allow-symlinks</s>
609	599	<li> dotfiles
610	600	<li> parent-project-code
611	601	<li> parent-projet-name
612	602	<li> hash-policy
613	603	<li> mv-rm-files
		@@ -660,13 +650,13 @@
660	650	A "config" card is used to send configuration information from client
661	651	to server (in response to a "fossil configuration push" command) or
662	652	from server to client (in response to a "fossil configuration pull" or
663	653	"fossil clone" command). The format is as follows:
664	654
665		-<blockquote>
	655	+<pre>
666	656	<b>config</b> <i>configuration-name size</i> <b>\n</b> <i>content</i>
667		-</blockquote>
	657	+</pre>
668	658
669	659	The server will only accept a config card if the user has
670	660	"Admin" privilege. A client will only accept a config card if
671	661	it had sent a corresponding reqconfig card in its request.
672	662
		@@ -676,13 +666,13 @@
676	666	<h3>3.11 Pragma Cards</h3>
677	667
678	668	The client may try to influence the behavior of the server by
679	669	issuing a pragma card:
680	670
681		-<blockquote>
	671	+<pre>
682	672	<b>pragma</i> <i>name value...</i>
683		-</blockquote>
	673	+</pre>
684	674
685	675	The "pragma" card has at least one argument which is the pragma name.
686	676	The pragma name defines what the pragma does.
687	677	A pragma might have zero or more "value" arguments
688	678	depending on the pragma name.
		@@ -775,13 +765,13 @@
775	765	If the server discovers anything wrong with a request, it generates
776	766	an error card in its reply. When the client sees the error card,
777	767	it displays an error message to the user and aborts the sync
778	768	operation. An error card looks like this:
779	769
780		-<blockquote>
	770	+<pre>
781	771	<b>error</b> <i>error-message</i>
782		-</blockquote>
	772	+</pre>
783	773
784	774	The error message is English text that is encoded in order to
785	775	be a single token.
786	776	A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
787	777	newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
		@@ -791,13 +781,13 @@
791	781	the error message.
792	782
793	783	The server can also send a message card that also prints a
794	784	message on the client console, but which is not an error:
795	785
796		-<blockquote>
	786	+<pre>
797	787	<b>message</b> <i>message-text</i>
798		-</blockquote>
	788	+</pre>
799	789
800	790	The message-text uses the same format as an error message.
801	791
802	792	<h3>3.14 Unknown Cards</h3>
803	793
804	794

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -130,34 +130,30 @@
130
131	The client modifies the URL by appending the method name "<b>/xfer</b>"
132	to the end. For example, if the URL specified on the client command
133	line is
134
135	<blockquote>
136	https://fossil-scm.org/fossil
137	</blockquote>
138
139	Then the URL that is really used to do the synchronization will
140	be:
141
142	<blockquote>
143	https://fossil-scm.org/fossil/xfer
144	</blockquote>
145
146	<h3>2.2 HTTP Request Format</h3>
147
148	The client always sends a POST request to the server. The
149	general format of the POST request is as follows:
150
151	<blockquote><pre>
152	POST /fossil/xfer HTTP/1.0
153	Host: fossil-scm.hwaci.com:80
154	Content-Type: application/x-fossil
155	Content-Length: 4216

156
157	<i>content...</i>
158	</pre></blockquote>
159
160	In the example above, the pathname given after the POST keyword
161	on the first line is a copy of the URL pathname. The Host: parameter
162	is also taken from the URL. The content type is always either
163	"application/x-fossil" or "application/x-fossil-debug". The "x-fossil"
	@@ -165,20 +161,20 @@
165	content is compressed using zlib whereas "x-fossil-debug" is sent
166	uncompressed.
167
168	A typical reply from the server might look something like this:
169
170	<blockquote><pre>
171	HTTP/1.0 200 OK
172	Date: Mon, 10 Sep 2007 12:21:01 GMT
173	Connection: close
174	Cache-control: private
175	Content-Type: application/x-fossil; charset=US-ASCII
176	Content-Length: 265

177
178	<i>content...</i>
179	</pre></blockquote>
180
181	The content type of the reply is always the same as the content type
182	of the request.
183
184	<h2>3.0 Fossil Synchronization Content</h2>
	@@ -202,13 +198,11 @@
202	<h3>3.2 Login Cards</h3>
203
204	Every message from client to server begins with one or more login
205	cards. Each login card has the following format:
206
207	<blockquote>
208	<b>login</b> <i>userid nonce signature</i>
209	</blockquote>
210
211	The userid is the name of the user that is requesting service
212	from the server. The nonce is the SHA1 hash of the remainder of
213	the message - all text that follows the newline character that
214	terminates the login card. The signature is the SHA1 hash of
	@@ -241,14 +235,14 @@
241	cards. File cards come in two different formats depending
242	on whether the artifact is sent directly or as a
243	[./delta_format.wiki\|delta] from some
244	other artifact.
245
246	<blockquote>
247	<b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i><br>
248	<b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
249	</blockquote>
250
251	File cards are followed by in-line "payload" data.
252	The content of the artifact
253	or the artifact delta is the first <i>size</i> bytes of the
254	x-fossil content that immediately follow the newline that
	@@ -282,14 +276,14 @@
282	in-line "payload" data characteristics and also the same treatment of
283	direct content or delta content. Cfile cards come in two different formats
284	depending on whether the artifact is sent directly or as a delta from
285	some other artifact.
286
287	<blockquote>
288	<b>cfile</b> <i>artifact-id usize csize</i> <b>\n</b> <i>content</i><br>
289	<b>cfile</b> <i>artifact-id delta-artifact-id usize csize</i> <b>\n</b> <i>content</i><br>
290	</blockquote>
291
292	The first argument of the cfile card is the ID of the artifact that
293	is being transferred. The artifact ID is the lower-case hexadecimal
294	representation of the name hash for the artifact. The second argument of
295	the cfile card is the original size in bytes of the artifact. The last
	@@ -311,25 +305,21 @@
311	the [/help?cmd=sync\|fossil sync] command includes the "--private" option.
312
313
314	Private content is marked by a "private" card:
315
316	<blockquote>
317	<b>private</b>
318	</blockquote>
319
320	The private card has no arguments and must directly precede a
321	file card that contains the private content.
322
323	<h4>3.3.4 Unversioned File Cards</h4>
324
325	Unversioned content is sent in both directions (client to server and
326	server to client) using "uvfile" cards in the following format:
327
328	<blockquote>
329	<b>uvfile</b> <i>name mtime hash size flags</i> <b>\n</b> <i>content</i>
330	</blockquote>
331
332	The <i>name</i> field is the name of the unversioned file. The
333	<i>mtime</i> is the last modification time of the file in seconds
334	since 1970. The <i>hash</i> field is the hash of the content
335	for the unversioned file, or "<b>-</b>" for deleted content.
	@@ -360,14 +350,14 @@
360	the push and pull cards. The push card tells the server that
361	the client is pushing content. The pull card tells the server
362	that the client wants to pull content. In the event of a sync,
363	both cards are sent. The format is as follows:
364
365	<blockquote>
366	<b>push</b> <i>servercode projectcode</i><br>
367	<b>pull</b> <i>servercode projectcode</i>
368	</blockquote>
369
370	The <i>servercode</i> argument is the repository ID for the
371	client. The <i>projectcode</i> is the identifier
372	of the software project that the client repository contains.
373	The projectcode for the client and server must match in order
	@@ -385,14 +375,14 @@
385	client to server in order to tell the server that the client
386	wants to pull content. The clone card comes in two formats. Older
387	clients use the no-argument format and newer clients use the
388	two-argument format.
389
390	<blockquote>
391	<b>clone</b><br>
392	<b>clone</b> <i>protocol-version sequence-number</i>
393	</blockquote>
394
395	<h4>3.5.1 Protocol 3</h4>
396
397	The latest clients send a two-argument clone message with a
398	protocol version of "3". (Future versions of Fossil might use larger
	@@ -409,13 +399,13 @@
409	cards for some number of artifacts up to the maximum message size.
410
411	The server will also send a single "clone_seqno" card to the client
412	so that the client can know where the server left off.
413
414	<blockquote>
415	<b>clone_seqno</b> <i>sequence-number</i>
416	</blockquote>
417
418	The clone message in subsequent HTTP requests for the same clone
419	operation will use the sequence-number from the
420	clone_seqno of the previous reply.
421
	@@ -440,13 +430,13 @@
440
441	An igot card can be sent from either client to server or from
442	server to client in order to indicate that the sender holds a copy
443	of a particular artifact. The format is:
444
445	<blockquote>
446	<b>igot</b> <i>artifact-id</i> ?<i>flag</i>?
447	</blockquote>
448
449	The first argument of the igot card is the ID of the artifact that
450	the sender possesses.
451	The receiver of an igot card will typically check to see if
452	it also holds the same artifact and if not it will request the artifact
	@@ -463,13 +453,13 @@
463
464	Zero or more "uvigot" cards are sent from server to client when
465	synchronizing unversioned content. The format of a uvigot card is
466	as follows:
467
468	<blockquote>
469	<b>uvigot</b> <i>name mtime hash size</i>
470	</blockquote>
471
472	The <i>name</i> argument is the name of an unversioned file.
473	The <i>mtime</i> is the last modification time of the unversioned file
474	in seconds since 1970.
475	The <i>hash</i> is the SHA1 or SHA3-256 hash of the unversioned file
	@@ -495,13 +485,13 @@
495
496	A gimme card is sent from either client to server or from server
497	to client. The gimme card asks the receiver to send a particular
498	artifact back to the sender. The format of a gimme card is this:
499
500	<blockquote>
501	<b>gimme</b> <i>artifact-id</i>
502	</blockquote>
503
504	The argument to the gimme card is the ID of the artifact that
505	the sender wants. The receiver will typically respond to a
506	gimme card by sending a file card in its reply or in the next
507	message.
	@@ -515,13 +505,13 @@
515	Sync synchronizing unversioned content, the client may send "uvgimme"
516	cards to the server. A uvgimme card requests that the server send
517	unversioned content to the client. The format of a uvgimme card is
518	as follows:
519
520	<blockquote>
521	<b>uvgimme</b> <i>name</i>
522	</blockquote>
523
524	The <i>name</i> is the name of the unversioned file found on the
525	server that the client would like to have. When a server sees a
526	uvgimme card, it normally responses with a uvfile card, though it might
527	also send another uvigot card if the HTTP reply is already oversized.
	@@ -532,13 +522,13 @@
532	of state information on a client. The server sends a cookie to the
533	client. The client sends the same cookie back to the server on
534	its next request. The cookie card has a single argument which
535	is its payload.
536
537	<blockquote>
538	<b>cookie</b> <i>payload</i>
539	</blockquote>
540
541	The client is not required to return the cookie to the server on
542	its next request. Or the client might send a cookie from a different
543	server on the next request. So the server must not depend on the
544	cookie and the server must structure the cookie payload in such
	@@ -558,13 +548,13 @@
558	data elements.
559
560	The reqconfig card is normally sent in response to the
561	"fossil configuration pull" command. The format is as follows:
562
563	<blockquote>
564	<b>reqconfig</b> <i>configuration-name</i>
565	</blockquote>
566
567	As of 2018-06-04, the configuration-name must be one of the
568	following values:
569
570	<table border=0 align="center">
	@@ -603,11 +593,11 @@
603	<li> crlf-glob
604	<ul></td><td valign="top"><ul>
605	<li> crnl-glob
606	<li> encoding-glob
607	<li> empty-dirs
608	<li> <s>allow-symlinks</s> (removed 2020-08, version 2.12.1)
609	<li> dotfiles
610	<li> parent-project-code
611	<li> parent-projet-name
612	<li> hash-policy
613	<li> mv-rm-files
	@@ -660,13 +650,13 @@
660	A "config" card is used to send configuration information from client
661	to server (in response to a "fossil configuration push" command) or
662	from server to client (in response to a "fossil configuration pull" or
663	"fossil clone" command). The format is as follows:
664
665	<blockquote>
666	<b>config</b> <i>configuration-name size</i> <b>\n</b> <i>content</i>
667	</blockquote>
668
669	The server will only accept a config card if the user has
670	"Admin" privilege. A client will only accept a config card if
671	it had sent a corresponding reqconfig card in its request.
672
	@@ -676,13 +666,13 @@
676	<h3>3.11 Pragma Cards</h3>
677
678	The client may try to influence the behavior of the server by
679	issuing a pragma card:
680
681	<blockquote>
682	<b>pragma</i> <i>name value...</i>
683	</blockquote>
684
685	The "pragma" card has at least one argument which is the pragma name.
686	The pragma name defines what the pragma does.
687	A pragma might have zero or more "value" arguments
688	depending on the pragma name.
	@@ -775,13 +765,13 @@
775	If the server discovers anything wrong with a request, it generates
776	an error card in its reply. When the client sees the error card,
777	it displays an error message to the user and aborts the sync
778	operation. An error card looks like this:
779
780	<blockquote>
781	<b>error</b> <i>error-message</i>
782	</blockquote>
783
784	The error message is English text that is encoded in order to
785	be a single token.
786	A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
787	newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
	@@ -791,13 +781,13 @@
791	the error message.
792
793	The server can also send a message card that also prints a
794	message on the client console, but which is not an error:
795
796	<blockquote>
797	<b>message</b> <i>message-text</i>
798	</blockquote>
799
800	The message-text uses the same format as an error message.
801
802	<h3>3.14 Unknown Cards</h3>
803
804

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -130,34 +130,30 @@
130
131	The client modifies the URL by appending the method name "<b>/xfer</b>"
132	to the end. For example, if the URL specified on the client command
133	line is
134
135	<pre>https://fossil-scm.org/fossil</pre>


136
137	Then the URL that is really used to do the synchronization will
138	be:
139
140	<pre>https://fossil-scm.org/fossil/xfer</pre>


141
142	<h3>2.2 HTTP Request Format</h3>
143
144	The client always sends a POST request to the server. The
145	general format of the POST request is as follows:
146
147	<pre>
148	POST /fossil/xfer HTTP/1.0
149	Host: fossil-scm.hwaci.com:80
150	Content-Type: application/x-fossil
151	Content-Length: 4216
152	</pre>
153
154	<i><pre>content...</pre></i>

155
156	In the example above, the pathname given after the POST keyword
157	on the first line is a copy of the URL pathname. The Host: parameter
158	is also taken from the URL. The content type is always either
159	"application/x-fossil" or "application/x-fossil-debug". The "x-fossil"
	@@ -165,20 +161,20 @@
161	content is compressed using zlib whereas "x-fossil-debug" is sent
162	uncompressed.
163
164	A typical reply from the server might look something like this:
165
166	<pre>
167	HTTP/1.0 200 OK
168	Date: Mon, 10 Sep 2007 12:21:01 GMT
169	Connection: close
170	Cache-control: private
171	Content-Type: application/x-fossil; charset=US-ASCII
172	Content-Length: 265
173	</pre>
174
175	<i><pre>content...</pre></i>

176
177	The content type of the reply is always the same as the content type
178	of the request.
179
180	<h2>3.0 Fossil Synchronization Content</h2>
	@@ -202,13 +198,11 @@
198	<h3>3.2 Login Cards</h3>
199
200	Every message from client to server begins with one or more login
201	cards. Each login card has the following format:
202
203	<pre><b>login</b> <i>userid nonce signature</i></pre>


204
205	The userid is the name of the user that is requesting service
206	from the server. The nonce is the SHA1 hash of the remainder of
207	the message - all text that follows the newline character that
208	terminates the login card. The signature is the SHA1 hash of
	@@ -241,14 +235,14 @@
235	cards. File cards come in two different formats depending
236	on whether the artifact is sent directly or as a
237	[./delta_format.wiki\|delta] from some
238	other artifact.
239
240	<pre>
241	<b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i>
242	<b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
243	</pre>
244
245	File cards are followed by in-line "payload" data.
246	The content of the artifact
247	or the artifact delta is the first <i>size</i> bytes of the
248	x-fossil content that immediately follow the newline that
	@@ -282,14 +276,14 @@
276	in-line "payload" data characteristics and also the same treatment of
277	direct content or delta content. Cfile cards come in two different formats
278	depending on whether the artifact is sent directly or as a delta from
279	some other artifact.
280
281	<pre>
282	<b>cfile</b> <i>artifact-id usize csize</i> <b>\n</b> <i>content</i>
283	<b>cfile</b> <i>artifact-id delta-artifact-id usize csize</i> <b>\n</b> <i>content</i>
284	</pre>
285
286	The first argument of the cfile card is the ID of the artifact that
287	is being transferred. The artifact ID is the lower-case hexadecimal
288	representation of the name hash for the artifact. The second argument of
289	the cfile card is the original size in bytes of the artifact. The last
	@@ -311,25 +305,21 @@
305	the [/help?cmd=sync\|fossil sync] command includes the "--private" option.
306
307
308	Private content is marked by a "private" card:
309
310	<pre><b>private</b></pre>


311
312	The private card has no arguments and must directly precede a
313	file card that contains the private content.
314
315	<h4>3.3.4 Unversioned File Cards</h4>
316
317	Unversioned content is sent in both directions (client to server and
318	server to client) using "uvfile" cards in the following format:
319
320	<pre><b>uvfile</b> <i>name mtime hash size flags</i> <b>\n</b> <i>content</i></pre>


321
322	The <i>name</i> field is the name of the unversioned file. The
323	<i>mtime</i> is the last modification time of the file in seconds
324	since 1970. The <i>hash</i> field is the hash of the content
325	for the unversioned file, or "<b>-</b>" for deleted content.
	@@ -360,14 +350,14 @@
350	the push and pull cards. The push card tells the server that
351	the client is pushing content. The pull card tells the server
352	that the client wants to pull content. In the event of a sync,
353	both cards are sent. The format is as follows:
354
355	<pre>
356	<b>push</b> <i>servercode projectcode</i>
357	<b>pull</b> <i>servercode projectcode</i>
358	</pre>
359
360	The <i>servercode</i> argument is the repository ID for the
361	client. The <i>projectcode</i> is the identifier
362	of the software project that the client repository contains.
363	The projectcode for the client and server must match in order
	@@ -385,14 +375,14 @@
375	client to server in order to tell the server that the client
376	wants to pull content. The clone card comes in two formats. Older
377	clients use the no-argument format and newer clients use the
378	two-argument format.
379
380	<pre>
381	<b>clone</b>
382	<b>clone</b> <i>protocol-version sequence-number</i>
383	</pre>
384
385	<h4>3.5.1 Protocol 3</h4>
386
387	The latest clients send a two-argument clone message with a
388	protocol version of "3". (Future versions of Fossil might use larger
	@@ -409,13 +399,13 @@
399	cards for some number of artifacts up to the maximum message size.
400
401	The server will also send a single "clone_seqno" card to the client
402	so that the client can know where the server left off.
403
404	<pre>
405	<b>clone_seqno</b> <i>sequence-number</i>
406	</pre>
407
408	The clone message in subsequent HTTP requests for the same clone
409	operation will use the sequence-number from the
410	clone_seqno of the previous reply.
411
	@@ -440,13 +430,13 @@
430
431	An igot card can be sent from either client to server or from
432	server to client in order to indicate that the sender holds a copy
433	of a particular artifact. The format is:
434
435	<pre>
436	<b>igot</b> <i>artifact-id</i> ?<i>flag</i>?
437	</pre>
438
439	The first argument of the igot card is the ID of the artifact that
440	the sender possesses.
441	The receiver of an igot card will typically check to see if
442	it also holds the same artifact and if not it will request the artifact
	@@ -463,13 +453,13 @@
453
454	Zero or more "uvigot" cards are sent from server to client when
455	synchronizing unversioned content. The format of a uvigot card is
456	as follows:
457
458	<pre>
459	<b>uvigot</b> <i>name mtime hash size</i>
460	</pre>
461
462	The <i>name</i> argument is the name of an unversioned file.
463	The <i>mtime</i> is the last modification time of the unversioned file
464	in seconds since 1970.
465	The <i>hash</i> is the SHA1 or SHA3-256 hash of the unversioned file
	@@ -495,13 +485,13 @@
485
486	A gimme card is sent from either client to server or from server
487	to client. The gimme card asks the receiver to send a particular
488	artifact back to the sender. The format of a gimme card is this:
489
490	<pre>
491	<b>gimme</b> <i>artifact-id</i>
492	</pre>
493
494	The argument to the gimme card is the ID of the artifact that
495	the sender wants. The receiver will typically respond to a
496	gimme card by sending a file card in its reply or in the next
497	message.
	@@ -515,13 +505,13 @@
505	Sync synchronizing unversioned content, the client may send "uvgimme"
506	cards to the server. A uvgimme card requests that the server send
507	unversioned content to the client. The format of a uvgimme card is
508	as follows:
509
510	<pre>
511	<b>uvgimme</b> <i>name</i>
512	</pre>
513
514	The <i>name</i> is the name of the unversioned file found on the
515	server that the client would like to have. When a server sees a
516	uvgimme card, it normally responses with a uvfile card, though it might
517	also send another uvigot card if the HTTP reply is already oversized.
	@@ -532,13 +522,13 @@
522	of state information on a client. The server sends a cookie to the
523	client. The client sends the same cookie back to the server on
524	its next request. The cookie card has a single argument which
525	is its payload.
526
527	<pre>
528	<b>cookie</b> <i>payload</i>
529	</pre>
530
531	The client is not required to return the cookie to the server on
532	its next request. Or the client might send a cookie from a different
533	server on the next request. So the server must not depend on the
534	cookie and the server must structure the cookie payload in such
	@@ -558,13 +548,13 @@
548	data elements.
549
550	The reqconfig card is normally sent in response to the
551	"fossil configuration pull" command. The format is as follows:
552
553	<pre>
554	<b>reqconfig</b> <i>configuration-name</i>
555	</pre>
556
557	As of 2018-06-04, the configuration-name must be one of the
558	following values:
559
560	<table border=0 align="center">
	@@ -603,11 +593,11 @@
593	<li> crlf-glob
594	<ul></td><td valign="top"><ul>
595	<li> crnl-glob
596	<li> encoding-glob
597	<li> empty-dirs
598	<li> <s title="removed 2020-08, version 2.12.1">allow-symlinks</s>
599	<li> dotfiles
600	<li> parent-project-code
601	<li> parent-projet-name
602	<li> hash-policy
603	<li> mv-rm-files
	@@ -660,13 +650,13 @@
650	A "config" card is used to send configuration information from client
651	to server (in response to a "fossil configuration push" command) or
652	from server to client (in response to a "fossil configuration pull" or
653	"fossil clone" command). The format is as follows:
654
655	<pre>
656	<b>config</b> <i>configuration-name size</i> <b>\n</b> <i>content</i>
657	</pre>
658
659	The server will only accept a config card if the user has
660	"Admin" privilege. A client will only accept a config card if
661	it had sent a corresponding reqconfig card in its request.
662
	@@ -676,13 +666,13 @@
666	<h3>3.11 Pragma Cards</h3>
667
668	The client may try to influence the behavior of the server by
669	issuing a pragma card:
670
671	<pre>
672	<b>pragma</i> <i>name value...</i>
673	</pre>
674
675	The "pragma" card has at least one argument which is the pragma name.
676	The pragma name defines what the pragma does.
677	A pragma might have zero or more "value" arguments
678	depending on the pragma name.
	@@ -775,13 +765,13 @@
765	If the server discovers anything wrong with a request, it generates
766	an error card in its reply. When the client sees the error card,
767	it displays an error message to the user and aborts the sync
768	operation. An error card looks like this:
769
770	<pre>
771	<b>error</b> <i>error-message</i>
772	</pre>
773
774	The error message is English text that is encoded in order to
775	be a single token.
776	A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
777	newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
	@@ -791,13 +781,13 @@
781	the error message.
782
783	The server can also send a message card that also prints a
784	message on the client console, but which is not an error:
785
786	<pre>
787	<b>message</b> <i>message-text</i>
788	</pre>
789
790	The message-text uses the same format as an error message.
791
792	<h3>3.14 Unknown Cards</h3>
793
794

Fossil SCM

Keyboard Shortcuts