💾 Archived View for soviet.circumlunar.space › zwatotem › diff › hypertexting.gmi captured on 2024-09-29 at 01:44:00. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I bit the bullet and ...
... followed through with my complaints from this post,...
...and cpompletely failed with this one.
In other words, my master thesis is a mockup, like all of them (I failed to deliver any code), but at least I will publish it on both the web and gemini.
The actual technology my thesis was de-facto developed in was Microsoft Word. Actctually, if you want to be petty, it was Word and several code editors (whichever provided the best experience for the current programming language put into example). A while ago I reaized, that code pasted to Word from Visual Studio Code inherits the style of the editor's active theme. This knowledge lead to me pasting first code listings from VSCode. But this approach had several problems. The code blocks were semantically a part of regular text, not "enlisted objects". They were spellchecked by default, counted towards word statistics, cut straight through the page divide, couldn't be labled, couldn't be reffered to, obeyed the same set margins as other text. I wondered, if Word has a native way of embedding code in documents, like for picutres or vector graphics. Unfortunately, it seemed it was not the case.
So I went searching, and found some plug-ins which were supposed to format code in Word. Unfortunately formatting was all they did, so I was in the same place, as before. I stayed with "Easy code formatter", as I liked it's default format slightly better than what came from VSCode, plus it added a frame around every listing, which made it easier to distinguish. Later as I used other IDEs to edit my code I could keep the style the same.
What's notable, is that I wrote the thesis in Word's web view most of the time, rather that in page view. I truly didn't care about the looks of the paper, but about the semantics. Built-in styles provided headers and inline code styles, which I could later fine tune in bulk. The table of content generated live, which was very useful for navigation around the document.
For the citation I used Mendeley. Without this plug-in I would spend hours manually inserting each detail about each cited work instead of focusing on the important stuff.
When I finished and sent my work to the prereview I got feedback that the code really needs to be labeled and numerated, as it is very unclear, which paragraph refers to which code. At this point I had no choice, but to figure out how to actually make code into a free floating object. The solution - text fields - was obvious from the hine sight, however the conversion still proved to be very time itensive. I think we would benefit from native way of embedding code. We could have the syntax highlighting and checking in-place as well as instant placement in a field and exempt from the global margins. That last one was a real life saver for me in terms of apperance on paper. Wrapping lines are significantly uglier than whole code fitting on the page. However this whole transition came at a cost of deterioration in semantics. In web view code no longer was in the correct position between paragraphs and the lables frequently overlapped both regular text and the code itself. If I put enough effort I would probably fix it, but it is extemally hard to do it, especially since Microsoft removed anchors of objects from the view. This is really ironic, as when I was little I thought they are useless and confusing (and so did a lot of people aparently) but now, that I need them, I can't use them.
Initially I planned only web, as I firmly believe gemtext is just an insufficient format for any more serious paper (not that I think that my paper is particularly serious). My document was already full of meta-information that I thought was going to be preserved best in HTML, which is full of rich semantic tags.
I decided to do the whole thing with certain limitations:
With dream tooling and writing the thesis originally for the web, this should be as easy, or easier than in Word. Unfortunately there is no Word-like WYSIWYG editor for HTML, which is a bummer. Writing HTML by hand is a lot of boilerplate work, so I got tired quickly with little work done.
I decided to hold that publication for the time, and get it faster out there faster with gemini.
Writing in Gemini is more straightforward than writing in HTML, but a lot of information is lost along the way.
I was ready for loss of formatting of inline code, as well as other emphasis of singular words in text. I was also ready to lose all the inline references, as inline links are impossible in gemtext and the headers are not addressable at all. And of course all figures were doomed to be banished to separate files and linked.
What I was not prepared for is the limited depth of headings. My original document has fifth level of headers, if we exclude the title. Unaware of the problem I started rewriting the whole thing to a single file.
When I prereviewed the page for the first time I realized that this is fundamentally not going to work in one piece. I needed to restructure the thesis by subdividing it.
I extracted some sections to separate pages and linked them in the main article. It works, but it feels wrong.
The situation I found myself in reminded me of the craziest hypertext I have ever read.
Thesis on the nature of hypertext
This tesis is an absolutely unique piece of content on the internet. It treats about hypertext while being hypertextual itself. And it's not only in a sense that it contains links. It is maximally broken down into one-three paragraph pieces and each piece is crossreferenced with whatever happens to be mentioned on the way. Aside from this there are several indexes that list the whole thing by different criteria and a facade for external references. There is no set path through the text. One can jump the links deep-first, queue the pages broad-first as you go, or curate all the interesting pages from the index.
I haven't read the whole thing yet, but from what I have, I suspect I can learn a whole lot about hypertext and change my perspective on it.
I don't know, whether the Gemini Commitee had a certain result in mind when designing gemtext's headers, but I can assure you - indended or not - the result is definately pressure for smaller pages and more distribution.
Maybe instead of writing plain old blog style texts we shuold start creating this super-dense web of thoughts to allow the ultimate reader flexibility of choice. I don't know, but I will find out and implement whatever style I find fitting for the next iteration of my thesis on gemini.