Marcin Cieślak is a user on mastodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

Request for comments:

When you're authoring text, or code, do you have keybindings that make use of meta or super key combinations?
In Gopherine I need to add support for a few keystrokes related to hypertext editing that have no equivalent in any of the traditional keymaps (not in emacs, vim standard configs at least)

1/2

#gopherine #gopher2049

For example, say I am using the vim keymap and I enter Insert mode to change hypertext content of a page I'm viewing, and I need a keystroke to move between multiplexed text lines. For one line of text, I have parallel data in parallel streams for the same line, and I need keystrokes to move to the previous and to the next stream.
I am currently using Super + Right Arrow for Next Stream, and Super + Left Arrow for Previous Stream.
Does that make sense to you guys?

2/2
#Gopherine #Gopher2049

@h Vaguely reminds me of "show codes" in WordPerfect.

@vertigo It's a bit like that, except that codes aren't interspersed with the text. I'm trying to be clever about the way parallel data is displayed. 80x25 text mode didn't allow for much visual richness back then, but with the powerful graphics capabilities we have today I think I'm onto something.

@vertigo Basically, in any common multiplexed hypertext you're typically going to have those four streams, which could be displayed as four columns the moment you are editing a given line, but they could be rendered completely different (animation transforming the text) when you leave that line, and it would look something more like wysiwyg, or optionally something similar to a SGML tag with attributes.
But in the text, it's really four streams, all with separate data each.

@h I don't follow. What are these streams? Why exactly 4?

/cc @vertigo

@akkartik @vertigo

1) Plain text (utf8)
2) Styling
3) Layout
4) Hyperlinking

Not necessarily in that order, but the text is generally stream #1.
Will probably have to make that a hard MUST if I eventually write a RFC.

@h @akkartik @vertigo 1) is there any place for more semantic markup? Does it go into #4 ? or is it out of scope? 2) how can I pass a piece of those streams in a toot like <person>Immanuel Kant</person>

@saper

Excellent question, Marcin.

1) The central idea is that there is no markup, no complex parsing heuristics anywhere.

2) I haven't spec'ed out semantic data, nor other things like client-side scripting. When I do, those will have optional streams of their own.

@akkartik @vertigo

@h @akkartik @vertigo Ok, I understand that a whole point is not to have markup at all (that's why there are parallel streams). But you need to have a container format to transmit it over a bit-banged serial channels we mere mortals have to use.

Instead of 'Speaking to <a href="h@social.coop">Mr H</a>' will I be saying

(
(Speaking to Mr H)
(by the way, (Mr H) is hyperlinked to (h@social.coop), thank you)
)

?

@saper
The container is a kind of multiplexed text.
I call it extended text format.
(text/extended as opposed to text/plain, file extension .xtxt)
Not unlike the way multimedia container formats work.

And serialised objects will most likely look similar to the way they do in Rebol, unless somebody complains with convincing strength and delicate persuasion 🙂

cc @akkartik @vertigo

@h @akkartik @vertigo Yes, you could use Matroska for example. (we could put .mkv's on Mastodon).

How would you reference hyperlayer to the text? Binary offsets? Some path expressions?

@saper
I have a presentation in the works for this, and I'm trying to get started blogging so I become somewhat less inefficient in communicating these things. I'm not a great writer, and part of this process will necessarily involve converting myself into one.

But maybe I can type up something succinct here.
Say I have a piece of hypertext, and the textual representation of this is "Hello, world!"

@saper So, in this framework, "Hello, world!" goes in a :text stream in our container.
For the purposes of our simple demo we're going to have a second stream called :links.
"Hello, world!" is line 1 on stream :text.

We want to make "world" be an hyperlink to something else. So we need to indicate, on a parallel line, on stream :link that that word is linked, and where it points to.

@saper So a visual representation of our text as a document would look like:

:text | : links
"Hello, world!" | world something://elsewhere

@h What about

:text 'Hello, baby, baby!'
:links 'baby' baby.to

which baby is this?

@saper The first one. If you need to specify the second one you need to specify you want to skip the first.
In an earlier prototype I did this adding pipe characters as a prefix indicating how many occurences you want to skip. So, in your case, say I have

:text "Hello, baby baby baby"
:links ||baby baby.to

That would link the third occurence.

@h ok, so you have a primitive path language to point to things, understood, thanks!

@saper As primitive as possible.That's the idea, to avoid any complex parsing heuristics. Only simpleminded loops.

@saper Things get more complex when you point to other things, of course.

And that's just a textual representation, :text and :links aren't strings in a text file, but multiplexed streams.
You can, of course use a tool to assemble a multiplexed hypertext from plain text files.
I have some little tools I call muxt, muxcat and demux for the purposes of handling extended text.

Marcin Cieślak @saper

@h the question is how (in)efficient a round-trip might be - from the serialized multiplexed format into editable buffers. This is what currently makes visual editor slow on - go to en.wikipedia.org/w/index.php?t and press "switch to visual editor'.

Watch the progress bar.

· Web · 0 · 0

@saper MediaWiki is sitting on top of a massive amount of Javascript and DOM stuff, and it's constantly converting between serialised HTML and DOM, using Javascript.
Performance is not MediaWiki's fault. We're not going to have a markup to maintain, and a DOM to update from markup, markup makes everything too complicated.

@saper Keep in mind that the type of hypertext I'm talking about is read/write. So the client is capable of editing objects directly. This is nothing new.
Pre-www systems have had this forever since Doug Engelbart's NLS.

The www sacrificed some things as trade-offs to make it scale globally. Now there is no need to keep observing those trade-offs.