Published 2026-03-23 10:40:44 PDT
Welcome one and all to the new and (arguably) improved Jasco.website!
If you haven't noticed the website looks a little bit different. Not by much, almost all the styling is identical, but if you inspect this page or any page on the site it is no longer using a separate style sheet.
You're probably thinking "why? Style sheets are fine."
It's because every page on this site is now using Notex!
"What the hell is Notex?"
What?! You don't religiously read my blog posts? As I wrote about last October, Notex is a markup language that "compiles" into HTML. In that post I detail my frustrations with both writing raw HTML markup, markdown, and LaTeX. The solution was Notex. Now you may be confused, as I said I was already using Notex for the website, which was only true to some extent. All drafts were using Notex, but as soon as anything was actually published, modifying the Notex file did nothing to effect the published page. This wasn't the end of the world, occasionally needing to pop open the HTML so I can fix a typo, but then the two files would be out of sync, bad.
This always kinda irked me, but not as much as Notex did. The fundamentals, I liked, but there were a few rough corners that I kept cutting myself on. Unfortunately, since I just hacked everything together, changing how it worked would mean rewriting pretty much everything, which I put off until a couple weeks ago.
Since I'm going to have to be referring to both the original Notex and my new rewrite, I'm going to refer to the original as "Notex 1" and the rewritten one as "Notex 2". Some of the things I changed were:
I really don't know what I was thinking with Notex 1's function syntax. The "/@function_name" part was fine, but using ":parameters" was plainly stupid. You should be able to pass multiple parameters without needing to ensure there isn't any whitespace in the function call. This significantly reduced the capability of functions. In Notex 2 the syntax now is a bit more in line with C style functions, using the notation "/@function_name(parameter1, parameterN-1){parameterN}".
"That's not a C style function!"
Yes, but it is closer. The first set of parameters, everything within parentheses, are used to pass actual arguments to the function, whereas the subject of the function, is generally meant for the text that is actually displayed on the page.
For instance, "/@coloredText(red){Red text}" would be the hypothetical function "coloredText", that takes the first parameter as the color and the 2nd as the text that is meant to be colored.
To me, it just makes sense that the subject is different than the rest of the parameters and thus should be isolated in the syntax.
Also I completely threw out the whole function scope idea, all functions are inline. I have yet to find a situation where I need to pass the whole document to a function and if you want the whole line to be effected by a function, you can just pass it as the subject in the new style.
Again, I don't know what I was thinking with the whole "!style=@style_name" syntax. Well, I do know that I wasn't thinking about it. I hadn't really considered how I should handle it until the last minute, and I do know the problems that resulted from this horrible design. By limiting any document to only have 1 style tag it required every CSS rule to be defined in that style function.
Notex 2 uses a separate preamble section, defined with a block wrapped in square brackets at the very top of the document. Here you can set the document title with #Title. Any HTML within the preamble gets placed in the head and any plain text is added to a meta description tag.
You could hypothetically define styling within the preamble but the better way is to use the attribute system for styling.
Attributes are Notex 2's solution for styling. As a reminder, anything surrounded in curly braces are within a group and these groups can be infinitely nested. Attributes are applied at the group level. So anything within a group will have the styling associated with the attributes applied to it.
Of course there are other changes, but these are the ones that necessitated the rewrite.
While I was using Notex 1 in my day to day life, the problems previously described kept popping up. Most of them stemmed from scope creep that developed over my writing of its first iteration. I had no plans of it being used for anything besides my notes. The concept of functions didn't come to me until part of the way through development and so had always felt bolted on, but once I had them, all I could see was their potential utility. Instead of copy pasting each reoccurring element, I could simply define a function that filled in the parameters. But because Notex 1 was so janky, I never found it worthwhile to actually make them.
I was constantly fighting with the early design decisions I had made, needing to be modifying the compiled HTML document to fix the errors that arose from edge cases I hadn't imagined. Fortunately, it made writing Notex 2 far easier, because I already had a solid grasp of the problems that could arise.
While adapting my website tooling to take advantage of Notex 2, I adopted a radical approach. Instead of building the tooling to work cohesively with my back catalog of previously made posts, I built my desired writing flow. I got it to the point where I now should not have to open up the compiled HTML. The "template" directory is where all the Notex files live. This is then mirrored in the "published" directory. The compiled HTML is output to the "published" directory and any other files are copied over into their respective subdirectories.
Only once I got this working did I then start adapting my previous posts to use the new format. This was fairly easy since raw HTML can be embedded in a Notex document and will just be passed through in compilation. All it meant for most of them was stripping the header and footer and replacing them with the newly defined functions. Now if I ever want to update them, all I have to do is just modify the function and recompile all the pages.
After such a long time I'm looking forward to writing posts without needing to worry about fighting with janky software.