cortav  Check-in [3b2fea2df1]

Overview
Comment:tidy up repo, add freedesktop file format stuff and viewer handler script
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 3b2fea2df1e5f43645d4cb8990d9bd891fa80ce4c8c869d02b6b21a990735016
User & Date: lexi on 2021-12-21 01:22:16
Other Links: manifest | tags
Context
2021-12-21
03:15
make names consistent, make view script customizable check-in: 13a73d4eb8 user: lexi tags: trunk
01:22
tidy up repo, add freedesktop file format stuff and viewer handler script check-in: 3b2fea2df1 user: lexi tags: trunk
2021-12-20
14:10
add weak modes that can be overridden by pragma check-in: c15ffd5fef user: lexi tags: trunk
Changes

Modified cortav.ct from [b7a7fbb952] to [e9d2ad32df].

9
10
11
12
13
14
15






























16
17
18
19
20
21
22
..
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114




115
116
117
118
119
120
121
...
352
353
354
355
356
357
358






## cortav vs. markdown
the most important difference between cortav and markdown is that cortav is strictly line-oriented. this choice was made to ensure that cortav was relatively easy to parse. so while a simple [$.ct] file may look a bit like a [$.md] file, in reality it's a lot closer to gemtext than any flavor of markdown.

## encoding
a cortav document is made up of a sequence of codepoints. UTF-8 must be supported, but other encodings (such as UTF-32 or C6B) may be supported as well. lines will be derived by splitting the codepoints at the linefeed character or equivalent. note that unearthly encodings like C6B or EBCDIC will need to select their own control sequences.































## structure
cortav is based on an HTML-like block model, where a document consists of sections, which are made up of blocks, which may contain a sequence of spans. flows of text are automatically conjoined into spans, and blocks are separated by one or more newlines. this means that, unlike in markdown, a single logical paragraph [*cannot] span multiple ASCII lines. the primary purpose of this was to ensure ease of parsing, but also, both markdown and cortav are supposed to be readable from within a plain text editor. this is the 21st century. every reasonable text editor supports soft word wrap, and if yours doesn't, that's entirely your own damn fault.

the first character(s) of every line (the "control sequence") indicates the role of that line. if no control sequence is recognized, the sequence [$.] is implied instead. the standard line classes and their associated control sequences are listed below. some control sequences have alternate forms, in order to support modern, readable unicode characters as well as plain ascii text.

* paragraphs (. ¶ ❡): a paragraph is a simple block of text. the period control sequence is only necessary if the paragraph text begins with something that would otherwise be interpreted as a control sequence.
* newlines (\\): inserts a line break into previous paragraph and attaches the following text. mostly useful for poetry or lyrics.
................................................................................
	d: [$%[*[##1]]]
* {d author} encodes document authorship
* {d cols} specifies the number of columns the next object should be rendered with
* {d include} transcludes another file
* {d quote} transcludes another file, without expanding the text except for paragraphs 
* {d embed}, where possible, embeds another file as an object within the current one. in HTML this could be accomplished with e.g. an iframe.
* {d expand} causes the next object (usually a code block) to be fully expanded when it would otherwise not be
* {d pragma} supplies semantic data about author intent, the kind of information document contains and hints about how it should be displayed to the user. think of them like offhand remarks to the renderer -- there's no guarantee that it'll pay any attention, but if it does, your document will look better. pragmas have no scope; they affect the entire document. the pragma function exists primarily as a means to allow parameters that would normally need to be specified on e.g. the command line to be encoded in the document instead in a way that multiple implementations can understand. a few standard pragmas are defined
** {d pragma layout} gives a hint on how the document should be layed out. the first hint that is understood will be applied; all others will be discarded. standard hints include:
*** essay
*** narrative
*** screenplay: uses asides to denote actions, quotes for dialogue
*** stageplay: uses asides to denote actions, quotes for dialogue
*** manual
*** glossary
*** news
** {d pragma accent} specifies an accent hue (in degrees around the color wheel) for renderers which support colorized output
** {d pragma accent-spread} is a factor that controls the "spread" of hues used in the document. if 0, only the accent color will be used; if larger, other hues will be used in addition to the primary accent color.
** {d pragma dark-on-light on|off} controls whether the color scheme used should be light-on-dark or dark-on-light
** {d pragma page-width} indicates how wide the pages should be





##ex examples

~~~ blockquotes #bq [cortav] ~~~
the following excerpts of text were recovered from a partially erased hard drive found in the Hawthorne manor in the weeks after the Incident. context is unknown.

#>
................................................................................
right now, the use of color in the HTML renderer is very unsatisfactory. the accent mechanism operates on the basis of the CSS HSL function, which is not perceptually uniform; different hues will present different mixes of brightness and some (yellows?) may be ugly or unreadable.

the ideal solution would be to simply switch to using LCH based colors. unfortunately, only Safari actually supports the LCH color function right now, and it's unlikely (unless Lea Verou and her husband manage to work a miracle) that Colors Level 4 is going to be implemented very widely any time soon.

this leaves us in an awkward position. we can of course do the math ourselves, working in LCH to implement the internal [$@tone] macro, and then "converting" these colors to HSL. unfortunately, you can't actually convert from LCH to HSL; it's like converting from pounds to kilograms. LCH can represent any color the human visual system can perceive; sRGB can't, and CSS HSL is implemented in sRGB. however, we could at least approximate something that would allow for perceptually uniform brightness, which would be an improvement, and this is probably the direction to go in, unless a miracle occurs and [$lch()] or [$color()] pop up in Blink.

it may be possible to do a more reasonable job of handling colors in the postscript and TeX outputs. unsure about SVG but i assume it suffers the same problems HTML/CSS do. does groff even support color??












>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







|












>
>
>
>







 







>
>
>
>
>
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
...
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
...
386
387
388
389
390
391
392
393
394
395
396
397

## cortav vs. markdown
the most important difference between cortav and markdown is that cortav is strictly line-oriented. this choice was made to ensure that cortav was relatively easy to parse. so while a simple [$.ct] file may look a bit like a [$.md] file, in reality it's a lot closer to gemtext than any flavor of markdown.

## encoding
a cortav document is made up of a sequence of codepoints. UTF-8 must be supported, but other encodings (such as UTF-32 or C6B) may be supported as well. lines will be derived by splitting the codepoints at the linefeed character or equivalent. note that unearthly encodings like C6B or EBCDIC will need to select their own control sequences.

## file type
a cortav source file is identified using a file extension, file type, and/or magic byte sequence.

three file extensions are defined as identifying a cortav source file. where relevant, all must be recognized as indicating a cortav source file.
* [$ct] is the shorthand extension
* [$cortav] is the canonical disambiguation extension, for use in circumstances where [$*.ct] is already defined to mean a different file format.
* [$] is the canonical Corran extension, a byte sequence comprising the unicode codepoints [$U+E3CE U+E3BD]. where the filesystem in question does not specify a filename encoding, the bytes should be expressed in UTF-8.

three more extensions are reserved for identifying a cortav intent file.
* [$ctc] is the shorthand extension
* [$cortavcun] is the canonical disambiguation extension
* [$] is the canonical Corran extension, a byte sequence comprising the unicode codepoints [$U+E3CE U+E3BD U+E3CE]. where the filesystem in question does not specify a filename encoding, the bytes should be expressed in UTF-8.

on systems which use metadata to encode filetype, two values are defined to identify cortav source files
* [$text/x-cortav] should be used when strings or arbitrary byte sequences are supported
* [$CTAV] (that is, the byte sequence [$0x43 0x54 0x41 0x56]) should be used on systems that support only 32-bit file types/4-character type codes like Classic Mac OS.

two more values are defined to identify cortav intent files.
* [$text/x-cortav-intent] 
* [$CTVC] (the byte sequence [$0x43 0x54 0x56 0x43])

on systems which do not define a canonical way of encoding the filetype but support extended attributes of some kind, such as linux, an attribute named [$mime] may be created and given the value [$text/x-cortav] or [$text/x-cortav-intent]; alternatively, extensions may be used.

it is also possible to indicate the nature of a cortav file without using filesystem metadata. this is done by prefixing the file with a magic byte sequence. the sequence used depends on the encoding.
* for UTF-8 and ASCII, [$%ct[!\\n]] (that is, the byte sequence [$0x25 0x63 0x74 0x0A]) should be used
* for C6B, the file should begin with the word [$] (that is, the byte sequence [$0x03 0x07 0x3E 0x2D]).
consequently, this sequence should be ignored by a cortav parser at the start of a file (except as an indication of file format).

for FreeDesktop-based systems, the [$velartrill-cortav.xml] file included in the repository supplies mappings for the extensions and magic byte sequences. a script is also included which can be registered with xdg-open so that double-clicking on a cortav file will render it out and open it in your default web browser.

## structure
cortav is based on an HTML-like block model, where a document consists of sections, which are made up of blocks, which may contain a sequence of spans. flows of text are automatically conjoined into spans, and blocks are separated by one or more newlines. this means that, unlike in markdown, a single logical paragraph [*cannot] span multiple ASCII lines. the primary purpose of this was to ensure ease of parsing, but also, both markdown and cortav are supposed to be readable from within a plain text editor. this is the 21st century. every reasonable text editor supports soft word wrap, and if yours doesn't, that's entirely your own damn fault.

the first character(s) of every line (the "control sequence") indicates the role of that line. if no control sequence is recognized, the sequence [$.] is implied instead. the standard line classes and their associated control sequences are listed below. some control sequences have alternate forms, in order to support modern, readable unicode characters as well as plain ascii text.

* paragraphs (. ¶ ❡): a paragraph is a simple block of text. the period control sequence is only necessary if the paragraph text begins with something that would otherwise be interpreted as a control sequence.
* newlines (\\): inserts a line break into previous paragraph and attaches the following text. mostly useful for poetry or lyrics.
................................................................................
	d: [$%[*[##1]]]
* {d author} encodes document authorship
* {d cols} specifies the number of columns the next object should be rendered with
* {d include} transcludes another file
* {d quote} transcludes another file, without expanding the text except for paragraphs 
* {d embed}, where possible, embeds another file as an object within the current one. in HTML this could be accomplished with e.g. an iframe.
* {d expand} causes the next object (usually a code block) to be fully expanded when it would otherwise not be
* {d pragma} supplies semantic data about author intent, the kind of information document contains and hints about how it should be displayed to the user. think of them like offhand remarks to the renderer -- there's no guarantee that it'll pay any attention, but if it does, your document will look better. pragmas have no scope; they affect the entire document. the pragma function exists primarily as a means to allow parameters that would normally need to be specified on e.g. the command line to be encoded in the document instead in a way that multiple implementations can understand. a few standard pragmas are defined.
** {d pragma layout} gives a hint on how the document should be layed out. the first hint that is understood will be applied; all others will be discarded. standard hints include:
*** essay
*** narrative
*** screenplay: uses asides to denote actions, quotes for dialogue
*** stageplay: uses asides to denote actions, quotes for dialogue
*** manual
*** glossary
*** news
** {d pragma accent} specifies an accent hue (in degrees around the color wheel) for renderers which support colorized output
** {d pragma accent-spread} is a factor that controls the "spread" of hues used in the document. if 0, only the accent color will be used; if larger, other hues will be used in addition to the primary accent color.
** {d pragma dark-on-light on|off} controls whether the color scheme used should be light-on-dark or dark-on-light
** {d pragma page-width} indicates how wide the pages should be

! note on pragmas: particularly when working with collections of documents, you should not keep formatting metadata in the documents themselves! the best thing to do is to have a makefile for compiling the documents using whatever tools you want to support, and encoding the rendering options in this file (for the reference implementation this currently means as command line arguments, but eventually it will support intent files as well) so they can all be changed in one place; pragmas should instead be used for per-document [*overrides] of default settings.
! a workaround for the lack of intent files in the reference implementation is to have a single pseudo-stylesheet that contains only {d pragma} statements, and then import this file from each individual source file using the {d include} directive. this is suboptimal and recommended only when you need to ensure compatibility between different implementations.
! when creating HTML files, an even better alternative may be to turn off style generation entirely and link in an external, hand-written CSS stylesheet. this is generally the way you should compile sources for existing websites if you aren't going to write your own extension.

##ex examples

~~~ blockquotes #bq [cortav] ~~~
the following excerpts of text were recovered from a partially erased hard drive found in the Hawthorne manor in the weeks after the Incident. context is unknown.

#>
................................................................................
right now, the use of color in the HTML renderer is very unsatisfactory. the accent mechanism operates on the basis of the CSS HSL function, which is not perceptually uniform; different hues will present different mixes of brightness and some (yellows?) may be ugly or unreadable.

the ideal solution would be to simply switch to using LCH based colors. unfortunately, only Safari actually supports the LCH color function right now, and it's unlikely (unless Lea Verou and her husband manage to work a miracle) that Colors Level 4 is going to be implemented very widely any time soon.

this leaves us in an awkward position. we can of course do the math ourselves, working in LCH to implement the internal [$@tone] macro, and then "converting" these colors to HSL. unfortunately, you can't actually convert from LCH to HSL; it's like converting from pounds to kilograms. LCH can represent any color the human visual system can perceive; sRGB can't, and CSS HSL is implemented in sRGB. however, we could at least approximate something that would allow for perceptually uniform brightness, which would be an improvement, and this is probably the direction to go in, unless a miracle occurs and [$lch()] or [$color()] pop up in Blink.

it may be possible to do a more reasonable job of handling colors in the postscript and TeX outputs. unsure about SVG but i assume it suffers the same problems HTML/CSS do. does groff even support color??

### intent files
there's currently no standard way to describe the intent and desired formatting of a document besides placing pragmas in the source file itself. this is extremely suboptimal, as when generating collections of documents, it's ideal to be able to keep all formatting information in one place. users should also be able to specify their own styling overrides that describe the way they prefer to read [$cortav] files, especially for uses like gemini or gopher integration.

at some point soon [$cortav] needs to address this by adding intent files that can be activated from outside the source file, such as with a command line flag or a configuration file setting. these will probably consist of lines that are interpreted as pragmata. in addition to the standard intent format however, individual implementations should feel free to provide their own ways to provide intent metadata; e.g. the reference implementation, which has a lua interpreter available, should be able to take a lua script that runs after the parse stage and generates . this will be particularly useful for the end-user who wishes to specify a particular format she likes reading her files in without forcing that format on everyone she sends the compiled document to, as it will be able to interrogate the document and make intelligent decisions about what pragmata to apply.

Modified cortav.lua from [cf364bf145] to [70cf5fbd0d].

362
363
364
365
366
367
368
























369
370
371
372
373
374
375
...
467
468
469
470
471
472
473
474




475
476
477
478
479
480
481
...
757
758
759
760
761
762
763

764
765
766
767
768
769
770
			section > figure.listing > hr {
				border: none;
				margin: 0;
				height: 0.7em;
				counter-increment: line-number;
			}
		]];
























	}

	local stylesNeeded = {}

	local function getSpanRenderers(tag,elt)
		local htmlDoc = function(title, head, body)
			return [[<!doctype html>]] .. tag('html',nil,
................................................................................
			htmlDoc = htmlDoc;
		}
	end


	local function getBlockRenderers(tag,elt,sr,catenate)
		local function insert_toc(b,s)
			local lst = {tag = 'ol', attrs={}, nodes={}}




			local stack = {lst}
			local top = function() return stack[#stack] end
			local all = s.origin.doc.secorder
			for i, sec in ipairs(all) do
				if sec.heading_node then
					local ent = tag('li',nil,
						 catenate{tag('a', {href='#'..getSafeID(sec)},
................................................................................
					l,sep,sat = param:match('^%('..string.rep('([^%s]*)%s*',i)..'%)$')
					if l then break end
				end
				l = ss.math.lerp(tonumber(l), tbg, tfg)
				return tone(l, tonumber(sat), tonumber(sep), tonumber(alpha))
			end
		end

		css = css:gsub('@(%w+)/([0-9.]+)(%b())', replace)
		css = css:gsub('@(%w+)(%b())', function(a,b) return replace(a,nil,b) end)
		css = css:gsub('@(%w+)/([0-9.]+)', replace)
		css = css:gsub('@(%w+)', function(a,b) return replace(a,nil,b) end)
		return (css:gsub('%s+',' '))
	end








>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







|
>
>
>
>







 







>







362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
...
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
...
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
			section > figure.listing > hr {
				border: none;
				margin: 0;
				height: 0.7em;
				counter-increment: line-number;
			}
		]];
		toc = [[

		]];
		tocFixed = [[
			@media (min-width: calc(@[width]:[100vw] + 20em)) {
				ol.toc {
					position: fixed;
					padding-top: 1em; padding-bottom: 1em;
					padding-right: 1em;
					margin-top: 0; margin-bottom: 0;
					right: 0; top: 0; bottom: 0;
					max-width: calc(50vw - ((@[width]:[0]) / 2) - 3.5em);
					overflow-y: auto;
				}
				@media (max-width: calc(@[width]:[100vw] + 30em)) {
					ol.toc {
						max-width: calc(100vw - ((@[width]:[0])) - 9.5em);
					}
					body {
						margin-left: 5em;
					}
				}
			}
		]];
	}

	local stylesNeeded = {}

	local function getSpanRenderers(tag,elt)
		local htmlDoc = function(title, head, body)
			return [[<!doctype html>]] .. tag('html',nil,
................................................................................
			htmlDoc = htmlDoc;
		}
	end


	local function getBlockRenderers(tag,elt,sr,catenate)
		local function insert_toc(b,s)
			local lst = {tag = 'ol', attrs={class='toc'}, nodes={}}
			stylesNeeded.toc = true
			if opts['width'] then
				stylesNeeded.tocFixed = true
			end
			local stack = {lst}
			local top = function() return stack[#stack] end
			local all = s.origin.doc.secorder
			for i, sec in ipairs(all) do
				if sec.heading_node then
					local ent = tag('li',nil,
						 catenate{tag('a', {href='#'..getSafeID(sec)},
................................................................................
					l,sep,sat = param:match('^%('..string.rep('([^%s]*)%s*',i)..'%)$')
					if l then break end
				end
				l = ss.math.lerp(tonumber(l), tbg, tfg)
				return tone(l, tonumber(sat), tonumber(sep), tonumber(alpha))
			end
		end
		css = css:gsub('@(%b[]):(%b[])', function(v,d) return opts[v:sub(2,-2)] or v:sub(2,-2) end)
		css = css:gsub('@(%w+)/([0-9.]+)(%b())', replace)
		css = css:gsub('@(%w+)(%b())', function(a,b) return replace(a,nil,b) end)
		css = css:gsub('@(%w+)/([0-9.]+)', replace)
		css = css:gsub('@(%w+)', function(a,b) return replace(a,nil,b) end)
		return (css:gsub('%s+',' '))
	end

Added desk/cortav-view.desktop.tpl version [23a7388a52].















>
>
>
>
>
>
>
1
2
3
4
5
6
7
[Desktop Entry]
Encoding=UTF-8
Type=Application
Icon=accessories-text-editor

Name=CortavView
Name[x-ranuir]=CortavLocmos

Added desk/cortav-view.sh version [a29a5961ee].







































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# note that this file lacks a shebang. there is no compatible way
# to write a shebang that works across distros, so we're generating
# the shebang and inserting it into the script at build time.
# we also do something similar with the path to cortav, in case the
# executable isn't in $PATH

out=$(mktemp --suffix=.html)

"$cortav_exec" "$1" -o "$out" -m html:width 35em

if test "$BROWSER" != ""; then
	"$BROWSER" "file://$out"
else
	xdg-open "$out"
fi

# clean up when the browser closes
sleep 1 # in case of tricksiness
rm "$out"

Name change from cortav.xml to desk/cortav.xml.

whitespace changes only

Added desk/velartrill-cortav.xml version [356c2a8842].





















































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<?xml version="1.0"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
	<mime-type type="text/x-cortav">
		<comment xml:lang="en">Cortav rich text markup source file</comment>
		<comment xml:lang="de">Textauszeichnungsformat-Cortav-Datei</comment>
		<comment xml:lang="de-Latf">𝔗𝔢𝔵𝔱𝔞𝔲𝔰𝔷𝔢𝔦𝔠𝔥𝔫𝔲𝔫𝔤𝔰𝔣𝔬𝔯𝔪𝔞𝔱-ℭ𝔬𝔯𝔱𝔞𝔳-𝔇𝔞𝔱𝔢𝔦</comment>
		<comment xml:lang="x-ranuir-Latn">hurnim cordaii dalve Cortav</comment>
		<comment xml:lang="x-ranuir-CR8">   </comment>

		<acronym xml:lang="x-ranuir-CR8"></acronym>
		<expanded-acronym xml:lang="x-ranuir-CR8"></expanded-acronym>

		<expanded-acronym xml:lang="de-Latf">ℭ𝔬𝔯𝔱𝔞𝔳</expanded-acronym>
		<acronym xml:lang="de-Latf">ℭ𝔗</acronym>

		<acronym>CT</acronym>
		<expanded-acronym>Cortav</expanded-acronym>

		<generic-icon>x-office-document</generic-icon>
		<glob pattern="*.ct"/> <glob pattern="*."/>
		<glob pattern="*.cortav"/>
		<magic>
			<match value="%ct\n" offset="0" type="string"/>
			<match value="\x03\x07\x3E\x2D" offset="0" type="string"/>
		</magic>
	</mime-type>
	<mime-type type="text/x-cortav-intent">
		<comment xml:lang="en">Cortav rendering intent file</comment>
		<comment xml:lang="x-ranuir-Latn">tav cunloci Cortavi</comment>
		<comment xml:lang="x-ranuir-CR8">  </comment>

		<acronym xml:lang="x-ranuir-CR8"></acronym>
		<expanded-acronym xml:lang="x-ranuir-CR8"></expanded-acronym>

		<acronym>CTC</acronym>
		<expanded-acronym>Cortavcun</expanded-acronym>

		<generic-icon>text-x-script</generic-icon>
		<glob pattern="*.ctc"/> <glob pattern="*."/>
		<glob pattern="*.cortavcun"/>
	</mime-type>
</mime-info>

Modified makefile from [5a68812ac4] to [be343fd9b7].

1
2

3
4
5


6




7
8
9
10
11
12
13
14
15
16
17
18
19



































lua != which lua
luac != which luac


extens = $(wildcard ext/*.lua)
extens_names ?= $(basename $(notdir $(extens)))







cortav: sirsem.lua cortav.lua $(extens) cli.lua
	@echo ' » building with extensions $(extens_names)'
	echo '#!$(lua)' > $@
	luac -o - $^ >> $@
	chmod +x $@

cortav.html: cortav.ct cortav
	./cortav $< -o $@ -m render:format html -y html:fossil-uv

.PHONY: syncdoc
syncdoc: cortav.html
	fossil uv add $<
	fossil uv sync





































>



>
>

>
>
>
>
|





|



|


>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
lua != which lua
luac != which luac
sh != which sh

extens = $(wildcard ext/*.lua)
extens_names ?= $(basename $(notdir $(extens)))
build = build
executable = cortav

prefix = $(HOME)/.local
bin_prefix = $(prefix)/bin
share_prefix = $(prefix)/share/$(executable)

$(build)/$(executable): sirsem.lua cortav.lua $(extens) cli.lua | $(build)/
	@echo ' » building with extensions $(extens_names)'
	echo '#!$(lua)' > $@
	luac -o - $^ >> $@
	chmod +x $@

$(build)/cortav.html: cortav.ct $(build)/$(executable) | $(build)/
	./cortav $< -o $@ -m render:format html -y html:fossil-uv

.PHONY: syncdoc
syncdoc: $(build)/cortav.html
	fossil uv add $<
	fossil uv sync

.PHONY: clean
clean:
	rm -f $(build)/cortav $(build)/cortav.html $(build)/velartrill-cortav-view.desktop $(build)/cortav-view.sh

$(build)/%.sh: desk/%.sh
	echo >$@ "#!$(sh)"
	echo >>$@ 'cortav_exec="$(bin_prefix)/$(executable)"'
	cat $< >> $@
	chmod +x $@

$(build)/velartrill-cortav-view.desktop: desk/cortav-view.desktop.tpl
	cp $< $@
	echo "Exec=$(bin_prefix)/cortav-view.sh" >>$@

%/:
	mkdir -p $@

.PHONY: install
install: $(build)/cortav $(build)/cortav-view.sh $(build)/velartrill-cortav-view.desktop | $(bin_prefix)/
	install $(build)/$(executable)  $(bin_prefix)
	install $(build)/cortav-view.sh $(bin_prefix)
	xdg-mime         install desk/velartrill-cortav.xml
	xdg-desktop-menu install $(build)/velartrill-cortav-view.desktop
	xdg-mime         default velartrill-cortav-view.desktop text/x-cortav

.PHONY: excise
excise: $(build)/velartrill-cortav-view.desktop
	xdg-mime         uninstall desk/velartrill-cortav.xml
	xdg-desktop-menu uninstall $(build)/velartrill-cortav-view.desktop
	rm $(bin_prefix)/$(executable)
	rm $(bin_prefix)/cortav-view.sh

.PHONY: wipe
wipe: excise clean