That last attempt from last night is pretty interesting, because it introduced this idea of named blocks and also conditional “match” syntax. I’m really starting to feel like all these “@“ symbols are becoming too muddy. Since this syntax is less integrated with plain text, perhaps we don’t need all of the command flags? Could we just use a bracket syntax for groups?

					text-renderer “nav-bar” {
	block “prev” {
		@has-prev($self.id) => text-inline {\{prev\}(a|href=“$prev.id”)}
		@else => text-inline {None}
	}
	block “next” {
		@has-next($self.id) => text-inline {\{prev\}(a|href=“$next.id”)}
		@else => text-inline {None}
	}
	render {
		#self | $(self.title) |  #next
	}
}
				

This kinda works, but the brackets end up conflicting with a lot of things. I could remove the brackets, and only use indentation?

					text-renderer nav-bar
				
	block prev
		@has-prev($self(id))
			{prev}(a|href=“$prev(id)”)
		@else-none
				
	block next
		@has-next($self(id))
			{prev}(a|href=“$next(id)”)
		@else-none
				
	render 
		@use(prev) | $self(title) | @use(next)
				

This also kinda works. Now I also made it so that “@“ specifically is a “function” that operates on the contextual element, and “$” works the same way except for properties and can select prev, self, or next. We also use indentation to denote text blocks as well? This could be too much for other parts of the system.

How do we reconcile the fact that a text renderer has two collection contexts—the immediate list of text and the outer list of map elements? Technically these cant have groups, so you could just use @has-next and $next without parameters… this becomes very overloaded though. Perhaps at this layer of abstraction though, that’s okay. I should try a test run of all this to solve a real issue that I have, like the devlogs.

					query: all-devlogs
	include devlog
end
				
query-renderer: all-devlog-renderer
	render
		@render-query(devlog-renderer)
	end
end
				
map-renderer: devlog-renderer
				
	block: name
		log-$self(year)-$self(month)-$self(day)
	end
				
	block: header
		h1: {Devlog}(a|href="./devlog.html") < {20$self(year)}(a|href="./devlog-$self(year).html") < {$self(month-name)}(a|href="./devlog-$self(year)-$self(month).html") < $self(day)
	end
				
	block: title
		^|n @use(name)-title|
		^|u log-title-template ($self(month-name) $self(day), 20@self(year))|
		^|e|
	end
				
	render
		^|n log-@use(name)|
		@use(header)
		article:(class="log")
			@render-text[devlog-tag-nav]($self(tags))
			^|ui @use(name)-content|
			@render-text[devlog-tag-nav]($self(tags))
		^|e|
				
		^|n @use(name)-content|
		$self(content)
		^|e|
				
		^|n @use(name)-export|
		^|x dev@use(name).html|
		^|u document @use(name)-title @use(name)-content|
		^|e|
	end
				
end
				
text-renderer: devlog-tag-nav
				
	block: prev
		@has-prev($self)
			{← prev}(a|href="./devlog-$prev[$self](year)-$prev[$self](month)-$prev[$self](day).html",class="prev")
		@else-none
	end
				
	block: title
		@has-key(link)
			{$self}(span|class="title")(a|href=“$self(link)”)
		@else
			{$self}(span|class="title")
	end
				
	block: next
		@has-next($self)
			{ next →}(a|href="./devlog-$next[$self](year)-$next[$self](month)-$next[$self](day).html",class="next")
		@else-none
	end
				
	render
		x-rel-nav: @use(prev) | @use(title) | @use(next)
	end
				
end
				

Something that got awkward here was selecting *which* next/prev to use, and then also selecting a property. At this point, this is feeling really bloated and complicated. I’m not sure how much longer to pursue this, because there are much better ways to spend my time, though without this capability my ability to grow my site (and apply this stack to other sites) is limited.

—

Thinking more about if this was more of just a data-structure oriented system? Not really sure what I mean by that, but like the whole thing is really just about getting keys in maps and that’s about it.

Perhaps there are a handful of root level data structures, and each structure has a list of valid components.

—

I went and separately played around with the syntax for this a bunch in VSCode, and got to a place I’m a lot happier with. Basically, there’s a handful of object types (@def, @map, @query, @TYPE-renderer), and each object has another set of legal child objects (@key, @block, @switch, etc). Finally, most objects take parameters which are always strings (except group indices) and a string has an inline form and a block form. Both forms allow interpolation using functions that start with “$” which operate on the context.