@bender@twtxt.net gemini-cli, something something https://github.com/google-gemini/gemini-cli/issues/16723

https://github.com/unix-v4-commentary/unix-v4-source-commentary

A comprehensive, line-by-line commentary on the UNIX Fourth Edition source code (released November 1973; tape recovered from June 1974 distribution).

@prologic@twtxt.net I’d love to take a look at the code. 😅

I’m kind of curious to know how much Assembly I need vs. How much of a microkernel can I build purely in Mu (µ)? 🤔

Can’t really answer that, because I only made a working kernel for 16-bit real mode yet. That is 99% C, though, only syscall entry points are Assembly. (The OpenWatcom compiler provides C wrappers for triggering software interrupts, which makes things easier.)

But in long mode? No idea yet. 😅 At least changing the page tables will require a tiny little bit of Assembly.

Took me nearly all week (in my spare time), but Mu (µ) finally officially support linux/amd64 🥳 I completely refactored the native code backend and borrowed a lot of the structure from another project called wazero (the zero dependency Go WASM runtime/compiler). This is amazing stuff because now Mu (µ) runs in more places natively, as well as running everywhere Go runs via the bytecode VM interpreter 🤞

And tcell seems to support my urxvt in general: https://github.com/gdamore/tcell/blob/v2/terminfo/r/rxvt/term.go#L144

I’m trying to implement configurable key bindings in tt. Boy, is parsing the key names into tcell.EventKeys a horrible thing. This type consists of three information:

1. maybe a predefined compound key sequence, like Ctrl+A
   
2. maybe some modifiers, such as Shift, Ctrl, etc.
   
3. maybe a rune if neither modifiers are present nor a predefined compound key exists
   

It’s hardcoded usage results in code like this:

func (t *TreeView[T]) InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        switch event.Key() {
        case tcell.KeyUp:
            t.moveUp()
        case tcell.KeyDown:
            t.moveDown()
        case tcell.KeyHome:
            t.moveTop()
        case tcell.KeyEnd:
            t.moveBottom()
        case tcell.KeyCtrlE:
            t.moveScrollOffsetDown()
        case tcell.KeyCtrlY:
            t.moveScrollOffsetUp()
        case tcell.KeyTab, tcell.KeyBacktab:
            if t.finished != nil {
                t.finished(event.Key())
            }
        case tcell.KeyRune:
            if event.Modifiers() == tcell.ModNone {
                switch event.Rune() {
                case 'k':
                    t.moveUp()
                case 'j':
                    t.moveDown()
                case 'g':
                    t.moveTop()
                case 'G':
                    t.moveBottom()
                }
            }
        }
    })
}

This data structure is just awful to handle and especially initialize in my opinion. Some compound tcell.Keys are mapped to human-readable names in tcell.KeyNames. However, these names always use - to join modifiers, e.g. resulting in Ctrl-A, whereas tcell.EventKey.Name() produces +-delimited strings, e.g. Ctrl+A. Gnaarf, why this asymmetry!? O_o

I just checked k9s and they’re extending tcell.KeyNames with their own tcell.Key definitions like crazy: https://github.com/derailed/k9s/blob/master/internal/ui/key.go Then, they convert an original tcell.EventKey to tcell.Key: https://github.com/derailed/k9s/blob/b53f3091ca2d9ab963913b0d5e59376aea3f3e51/internal/ui/app.go#L287 This must be used when actually handling keyboard input: https://github.com/derailed/k9s/blob/e55083ba271eed6fc4014674890f70c5ed6c70e0/internal/ui/tree.go#L101

This seems to be much nicer to use. However, I fear this will break eventually. And it’s more fragile in general, because it’s rather easy to forget the conversion or one can get confused whether a certain key at hand is now an original tcell.Key coming from the library or an “extended” one.

I will see if I can find some other programs that provide configurable tcell key bindings.

@movq@www.uninformativ.de Sorry, I meant the builtin module:

$ python3 -m pep8 file.py
/usr/lib/python3/dist-packages/pep8.py:2123: UserWarning: 

pep8 has been renamed to pycodestyle (GitHub issue #466)
Use of the pep8 tool will be removed in a future release.
Please install and use `pycodestyle` instead.

  $ pip install pycodestyle
  $ pycodestyle ...

I can’t seem to remember the name pycodestyle for the life of me. Maybe that’s why I almost never use it.

@lyse@lyse.isobeef.org It’s not super comfortable, that’s right.

But these mouse events come with a caveat anyway:

ncurses uses the XM terminfo entry to enable mouse events, but it looks like this entry does not enable motion events for most terminal emulators. Reporting motion events is supported by, say, XTerm, xiate, st, or urxvt, it just isn’t activated by XM. This makes all this dragging stuff useless.

For the moment, I edited the terminfo entry for my terminal to include motion events. That can’t be a proper solution. I’m not sure yet if I’m supposed to send the appropriate sequence manually …

And the terminfo entries for tmux or screen don’t include XM at all. tmux itself supports the mouse, but I’m not sure yet how to make it pass on the events to the programs running inside of it (maybe that’s just not supported).

To make things worse, on the Linux VT (outside of X11 or Wayland), the whole thing works differently: You have to use good old gpm to get mouse events (gpm has been around forever, I already used this on SuSE Linux). ncurses does support this, but this is a build flag and Arch Linux doesn’t set this flag. So, at the moment, I’m running a custom build of ncurses as a quick hack. 😅 And this doesn’t report motion events either! Just clicks. (I don’t know if gpm itself can report motion events, I never used the library directly.)

tl;dr: The whole thing will probably be “keyboard first” and then the mouse stuff is a gimmick on top. As much as I’d like to, this isn’t going to be like TUI applications on DOS. I’ll use “Windows” for popups or a multi-window view (with the “WindowManager” being a tiny little tiling WM).

@lyse@lyse.isobeef.org It’s already fixed:

https://github.com/openbsd/src/commit/668f1f05e71c5e979d278f1ad4568956226715ea

Question is when that fix will land. 😅

On my way to having windows and mouse support:

https://movq.de/v/95bbbbd3e8/basic-windows.mp4

It would be cool to have something like Turbo Vision eventually.

(I considered just using Turbo Vision, but it’s a C++ library and that’s not quite what I’m looking for. But it’s not yet completely off the table.)

Well, you girls and guys are making cool things, and I have some progress to show as well. 😅

https://movq.de/v/c0408a80b1/movwin.mp4

Scrolling widgets appears to work now. This is (mostly) Unicode-aware: Note how emojis like “😅” are double-width “characters” and the widget system knows this. It doesn’t try to place a “😅” in a location where there’s only one cell available.

Same goes for that weird “ä” thingie, which is actually “a” followed by U+0308 (a combining diacritic). Python itself thinks of this as two “characters”, but they only occupy one cell on the screen. (Assuming your terminal supports this …)

This library does the heavy Unicode lifting: https://github.com/jquast/wcwidth (Take a look at its implementation to learn how horrible Unicode and human languages are.)

The program itself looks like this, it’s a proper widget hierarchy:

https://movq.de/v/1d155106e2/s.png

(There is no input handling yet, hence some things are hardwired for the moment.)

Ok, the standard library implementation is wonky at best, at least in regards to XDG, because it really doesn’t implement it properly. https://github.com/golang/go/issues/62382 I stick to my own code then. It doesn’t properly support anything else than Linux or Unixes that use XDG, but personally, I don’t care about them anyway. And the cross-platform situation is a giant mess. Unsurprisingly.

If your very popular project with lots of stars on GitHub is over 10 years old, and you’re still at a pre-1.0 version because you’re using SemVer and a 1.0 would mean making some kind of commitment and that’s somehow not desirable for you, then I think you’re doing something wrong. 🤔

Got a nice conspiracy theory for you:

https://mastodon.social/@mcc/115670290552252848

Actually wait I just thought about this and realized that the precise timing of the ACTUAL GitHub seed bank, by which I mean the Arctic Code Vault, on 2020-02-02, makes it more or less a perfect snapshot of pre-Copilot GitHub. Also precisely timed before we all got brain damage from COVID. This is the only remaining archive of source code by people with a fully working sense of smell

(Bonus points because the Arctic World Archive is located in Svaldbard and that’s the name of the AI in Stacey Kade’s “Cold Eternity”.)

H… Ho… How have I not heard about vim-tagbar before? 😳

https://github.com/preservim/tagbar

@shinyoukai@neko.laidback.moe is that https://github.com/owncloud/ocis (Go based, instead of PHP 🤮)?

@aelaraji@aelaraji.com I think I’ll just end up using the Official CrowdSec Go library 🤔

@prologic@twtxt.net if done right, zs derivatives can even generate twtxt feeds alongside RSS for blogs as well

@movq@www.uninformativ.de unison seems pretty fast for me, and quite nice looking on my macOS desktop. It’s bsed on GLFW, but it seems to work quite well 🤔

Because OP twtxt seems to be a cross-post from the Fediverse, I am bringing some context here. It refers to this GitHub issue. This comment explains why the issue described is happening:

This is usually due to notarization checks. E.g. the binaries are checked by the notarization service (‘XProtect’) which phones home to Apple. Depending on your network environment, this can take a long time. Once the executable has been run the results are usually cached, so any subsequent startup should be fast.

OP network must be running on 1,200 Baud modem, or less. 🤭 I have never, ever, experienced any distinguishable delays.

@zvava@twtxt.net

(#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing

I like that property (an off-ramp to location-based addressing), so I think I could live with that approach. ✅

(I’m not sure why we’re using text fragments, though. Wouldn’t that link to the first occurence of 2025-10-01T10:28:00Z? That’s not necessarily correct. And, to be proper URLs that Firefox and Chromium understand, it would also need to be written as 2025%2D10%2D01T10:28:00Z. The dash carries meaning, sadly. I think all this just creates needless complication. How about we just go with https://example.com/tw.txt#2025-10-01T10:28:00Z?)

Hi everyone, here’s a little introduction of my twtxt client (still WIP).

The client I’m developing is a single tenant project that runs entirely in the browser (it might use an optional backend).

It’s entirely based on native web-components and vanilla JS, it is designed to act closer to a toolkit than a full-fledged client, allowing users to “DIY” their own interface with pure html or plain javascript functions.

Users can also build their own engines by including a global javascript object that implement the defined internal API (TBD).

I’m planning to build a system that is easy enough to build and use with any skill level, using only pure html (with a homebrew minimal template engine) or via plain JS (I’ll be also providing some pre-made templates too).

Everything can be self-hosted on any static hosting provider, this allows to spread twtxt within communities like Neocities and similarly hosted websites (basically any Indieweb/Smallweb/Digital garden website and any of the common GitHub/Lab/Berg/lify Pages).

It will be probably named something like TxtCraft or craf.txt but I’m not really sure yet… 🤔 (Maybe some suggestions could help)

I’m still in the experimental phase, so there’s no decent source-code to share yet, but it will soon enough!

@zvava@twtxt.net @movq@www.uninformativ.de I’m not entirely sure about the spaces, but maybe they were omitted to simplify parsing of mentions in the form of @<nick url>. If the next token after the @<nick does not look like a URL, it’s not a mention but regular text. This is just wild guessing, though.

Looking at the regex and tests in the original twtxt reference implementation seems to confirm that theory in the sense as it relies on whitespace as the delimiter:

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-30-25.png

Another thing about nicks is that the original twtxt reference implementation converts nicks to all lowercase:

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-20-39.png

You probably know this already, the original twtxt file format specification can be found here: https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html

As for extensions, I don’t know of anything outside of twtxt.dev that has actually been (partially) implemented. However, there is also the issue tracker of the official reference implementation. You might wanna dig through that. For example, there is an alternative suggestions of multiline messages: https://github.com/buckket/twtxt/issues/157

@kat@yarn.girlonthemoon.xyz, see this one, regarding “Anubis” (which I believe you use, right?): https://github.com/eternal-flame-AD/pow-buster

@lyse@lyse.isobeef.org You might enjoy this one: https://github.com/TheMozg/awk-raycaster

Wooaahh, my goodness, this is completely crazy! :-D https://gist.github.com/Keith-S-Thompson/6920347

@prologic@twtxt.net Here’s one: https://github.com/vmykh/printer_labs/blob/master/escp2ref.pdf

@lyse@lyse.isobeef.org we NEED syntax highlighting in our man pages!!!! (FWIW i think bat can do that lol)

“You can fork it and fork yourself” 😂

@movq@www.uninformativ.de yeah man pages are good but these days i kinda prefer tldr and especially cheat.sh

@kingdomcome@yarn.girlonthemoon.xyz I REPLIED TO THIS AND NOW IT’S NOT SHOWING WTFFFF anyway what i said was that i have some fun stuff in the daily note template already like ASCII weather forecast from wttr AND a jenny holzer quote from fortune!!! i should add more fun stuff!!!

@kat@yarn.girlonthemoon.xyz I HIT ENTER BEFORE I COULD PASTE LMFAOOOOOOOOO I MEANT TO ADD THIS https://github.com/9001/copyparty/

Since Wayland compositors handle input devices on a lower level than X11 window managers, every compositor has to figure out on their own what a “mouse wheel click” is:

• https://github.com/labwc/labwc/issues/1068
  
• https://github.com/labwc/labwc/pull/2933
  

(I think “Wayland compositor” is a misnomer. They are full-blown display servers that also do compositing, plus Wayland window management, plus X11 window management.)

One can only hope that all this eventually gets moved into the wlroots library. (I’m not sure if that’s possible, nor if people would want that.)

this is pretty cool, especially with a customized dmenu build:

https://github.com/biox/shmoji/

I give up.

Let’s try again next year. I don’t have the stamina. Death by a thousand paper cuts.

Can’t set up a meaningful taskbar: https://github.com/labwc/labwc/discussions/2924 (This is not a labwc issue, it’s a generic issue in the broader Wayland ecosystem.)

@lyse@lyse.isobeef.org Rust is so different and, at the same time, so complex – it’s not far fetched to assume that I simply don’t understand what’s going on here. The docs appear to be clear, but alas … is it a bugs in the docs? Is it a lack of experience on my part? Who knows.

By the way, looks like there was a bit of a discussion regarding that name:

https://github.com/rust-lang/rust/issues/120048

I wanted to port this to Rust as an excercise, but they still have no random number generator in the core library: https://github.com/rust-lang/rust/issues/130703

@kat@yarn.girlonthemoon.xyz i found this, could be a good start: https://github.com/seaweedfs/seaweedfs/wiki/Getting-Started

speaking of minio

https://nale.io/gh will go to my GitHub, mark another self-hostable app successfully deployed.

#puttingilderstowork

@prologic@twtxt.net yeah, that will work perfectly. Because you are using “please”—which we all know is a magic talisman word of obedience—all uploads of your code to Github will be automatically paused, until such magic word is removed. 😂

No Github

Please don’t upload my code on Github!

I’m thinking about putting this up on all my projects and even on the front page of my Gitea instance 🤔

https://github.com/dotnet/runtime/pull/115733

@prologic@twtxt.net You can read more about the “cryptic” live coding language Punctual in my newsletter

@prologic@twtxt.net that will not be a problem; as long as it doesn’t affect authenticated users it wouldn’t make a difference. But we are comparing apples and eggs here. I don’t access GitHub while unauthenticated, but I can see how others might. It comes across as anti-web in general.

@bender@twtxt.net Basically the way I’m reading this is 1 RPM. This is a rather aggressive rate limit actually. This basically makes Github inaccessible and useless for basically anything unless you’re logged in. You can basically kiss “pursuing” casually, anonymously goodbye.

Imagine if I imposed that kind of rate limit on twtxt.net?! 🤣

@movq@www.uninformativ.de, “60 requests per hour”, eh? Was that a thing (that is, unauthenticated access to GitHub)?! I know I am on the minority, perhaps, as I rarely (or never) access GitHub unauthenticated.

RIP GitHub https://github.blog/changelog/2025-05-08-updated-rate-limits-for-unauthenticated-requests/

Good thing I left long ago.

@movq@www.uninformativ.de yeahhh very true stuff. find is annoying af i just use fd when i can

@movq@www.uninformativ.de Yeah I actually use sift a lot these days for most “searching” – at least code and text searching. For finding files by name I still use find | grep.

@kat@yarn.girlonthemoon.xyz Look into using something like pyrra for creating and managing SLO(s) with Prometheus 👌 I use this myself actually, plus I also use HetrixTools for external monitoring with SLO-style measures via status.mills.io 👌