@movq@www.uninformativ.de I hear you! It’s so annoying. Ruff, the formatter?

Lol, never heard of that banana moment before, but it sounds very fitting. :-D

@movq@www.uninformativ.de That’s cool! :-)

Got up at 5 to have a shower and air out the bathroom before the sun hits, went back to bed. Strolled with my mate for one and a half hours and now I’m absolutely done. At 8 the temps were pleasantly cool, but that didn’t last long.

@movq@www.uninformativ.de Oh dear, Thunderbird became such garbage.

@movq@www.uninformativ.de Since you ask, it must be only the one in the title bar, but not the one below. :-( Let me suggest Newsboat to you: https://newsboat.org/

@movq@www.uninformativ.de Not sure, I very rarely see people wearing cowboy hats. They’re a great protection against the sun in my opinion. Even as a child, I always loved their looks, but I only wear them in summer for that particular reason. Unfortunately, they’re too cumbersome to carry around not on your head. And they don’t combine with bicycle helmets or head rests.

About one and a half decades ago, I made two hats myself. Sadly, they both turned out to be failures.

Haha, now that you mention the aliens, I cannot unsee them anymore. :-D

@david@daiwei.me You better stick to your doctor’s prescription of mowing three times a week.

@david@daiwei.me Thank you! They were so busy, my camera got dizzy:

Image

Skipped a meeting and went for a stroll this arvo because my head was aching due to tension caused by lack of physical activity. That was a very good decision: https://lyse.isobeef.org/waldspaziergang-2026-07-23/

I’m not a fan of light shows but that’s a cool UFO! https://youtu.be/DbSmUCCR9Es

Dang it, @david@daiwei.me, you blew my cover!

I was raised without a TV, so I don’t miss it one bit. My parents just didn’t by a new one after their super old black and white device died. Looking after a baby was maybe spare time activity enough for them. :-P

When there was some super cool program I wanted to watch, like a James Bond movie, I visited my grandma. Sure, it sometimes was a pity that I could not join yesterday’s TV series discussions with my classmates, but oh well. I survived that. Building stuff with Lego or playing outside was all I really wanted.

Apart from a few really good programs, there’s sooooo much trash, non-stop ads and the like. Even as a kid, I was very disgusted by all that. But I have to admit that visting somebody with a TV and watching a good show was usually a highlight. These days, I can easily waste all my time and more on YouTube. :-/

@movq@www.uninformativ.de @klaxzy@klaxzy.net Same situation here.

Data protection, @dce@hashnix.club! :-D

This revealed another bug in my client that I still need to fix at some point. Inserting an empty set of messages failed with an SQL logic error. Whoops. I didn’t think about that corner case.

@aelaraji@aelaraji.com Perfect! :-D

@david@daiwei.me Go down to “Releases”, there’s a link to the CHANGES: https://movq.de/git/jenny/CHANGES.html

@aelaraji@aelaraji.com @david@daiwei.me Hahaha, neither did I came across this before. :-D

@movq@www.uninformativ.de Similar to my Go IDE at work. GoLand hangs so often in this giant code base. :-D (But it could also be one or the other snake oil that’s forcefully installed and fucks with me every day.)

@david@daiwei.me Hahaha! The thing is, it doesn’t taste as good in summer as in winter for some unknown reason. Two or three decades ago I asked my grandma to bake some of her amazing gingerbread in summer. But she always refused, claiming that this only really works in winter. Of course, I didn’t believe that. Finally, after years of begging and pleading, she finally made a tray. And to my surprise, she was right. It wasn’t bad, no, no, not at all. It was really yummy. But the gingerbread in winter was just better. :-/

Maybe I should give it a shot myself. Perhaps she slightly changed the recipe on purpose. So that I will never break the tradition of seasonal food again. :-P It worked, at least I never asked her to bake gingerbread in summer again. :-D

Pretty cool, @thecanine@twtxt.net!

@movq@www.uninformativ.de Good question. Tarballs are probably not needed, but might be convenient for people who don’t want to or can use a version control system. Not sure if there are non-techies who use your software. Tarballs for branches are overkill, though, I agree.

Looking at this more closely: As for the feeds, how about filenames “tags.atom” and “commits.atom”? Unless, of course, they were already named like that before.

For the tags feed it would be cool to include the actual changelog entries to be more useful if somebody takes this approach to get notified of new versions. But that would mean you have to duplicate the changelog entry into the annotated tag. And then you can’t fix changelog typos in the feed anymore. Alternatively, the feed generation would need to extract the section from the the CHANGES file. That has the benefit of automatically providing changelogs for past versions in the feed.

I finally built a prototype of a marking gauge with a cutter wheel out of some scraps.

https://lyse.isobeef.org/tmp/streichmassprototyp-mit-messerrad/

It had been a long time in coming, I bought some replacement cutting wheels three years ago for exactly that purpose. I also found out that I need more M3 countersink bolts for future marking gauges that I want to make (maybe two or three more). Luckily, I had exactly one. I thought I got way more than that, but M3 is very, very scarce in my collection. My M3 bolt was barely long enough to attach the cutting wheel to the bar. But it’s okay for the prototype.

I was pleasantly surprised that I managed to drill the 2.5mm diameter hole almost perfectly in center in the 8mm diameter aluminium round bar. Center finder, drill press and vise with a vertical prism for the win!

I knew upfront that the M5 steel bolt to lock the bar in place definitely needs to be replaced with a brass or aluminium one (maybe with a knurled head). Otherwise, it cuts into the aluminium bar and leaves ugly marks. These burrs might even scratch the workpiece. But, of course, I don’t have any brass on hand either. Alternatively, I swap out the aluminium bar for a steel or even stainless steel one. Stainless might be tricky to precisely drill and tap, though.

I already learned a few things by making this prototype. The final wooden fence can be even a bit bigger. This round thing behind is also too short, I’d like it to be a tad longer and thicker. The final one will be made from hardwood, not spruce. Other than that, it’s great and already more practical than my store-bought marking gauge with its round fence. This only causes the tool to roll around on the workbench. Or even roll off. Stupid design.

Dang it! Suddenly, I’ve got real strong appetite for gingerbread.

@movq@www.uninformativ.de Sigh. :-(

@movq@www.uninformativ.de Oh, that’s actually quite a bit. I didn’t expect that. You definitely have useful things. :-)

Exactly, I now also send links to my fork. :-D

@movq@www.uninformativ.de Yeah, I’m interested in your future bot stats as well. I wouldn’t be surprised if they just keep hammering against all those now 404s. But I hope I’m wrong.

@movq@www.uninformativ.de Finally, your software is just perfect and finished by now, no need to report non-existing bugs or send in code changes. :-) How many tickets and merge requests did you get before moving to your own server?

I have to admit that I use git format-patch so rarely, I always have to pull it up from my shell history. Haven’t used git send-email even once. I definitely have to look into that soon. Wanted to do that for several years. I typically upload the patch to my server and send a link via IRC.

Maybe I was just very unlucky, but my experience is that you can perfectly ignore people and their work who only do it for the “fame”. It’s almost always been from inferior quality to say the least.

@movq@www.uninformativ.de If only somebody had warned us! Luckily, no TV in this household. :-)

Why is there no English version of this interesting ZIP code article!? https://de.wikipedia.org/wiki/H0H_0H0 (Canadians know that this is Santa’s postal code.) https://www.canadapost-postescanada.ca/cpc/en/our-company/write-letter-to-santa.page

@movq@www.uninformativ.de Works good. I fully get and support your reasoning behind that change. There’s only one downside. Quickly looking at some code snippets in the browser helps me to quickly judge whether it’s worth to clone a repo or not. Oh well. :-) After all I know that movqware always is.

@movq@www.uninformativ.de Luckily, I’m not an autist. If you walk next to a busy road or airport, I totally get the annoying noises. I’d plug my ears, too. But I meant in the woods where there are almost only nature sounds. Maybe they miss the jackhammers etc. :-D

@david@daiwei.me Hell yeah, let’s finally reintroduce the big predators! :-D

I don’t get people strolling in nature with headphones on and constantly staring at their phones all the time. Why even go outside if you cover ears and eyes? Okay, you’re on the move and smell the country air, but still. Yesterday, one girl was wearing earphones and reading a real book while walking on a field path. Better than a phone, sure, but what the hell!?

@david@daiwei.me I first thought that this is a real lake, but it’s just a lake of craziness. :-D A town owned by a company (or so it reads to me), that’s insane.

Let me send you some nice 17°C.

@prologic@twtxt.net Yeah, great documentary. I was reading up on Orcas a few months ago. Zoos are really problematic.

Hurray! Finally, the thunderstorm is right over us. The last days we always got skipped. The rain smells so great. :-)

Ta, @david@daiwei.me, much appreciated.

@movq@www.uninformativ.de Hahaha, I didn’t expect anything like that. But yeah, makes perfect sense. :-D

Sunset few days ago:

Image

@prologic@twtxt.net Haha, no, you’re off the hook this time. :-D It’s totally my fault.

@movq@www.uninformativ.de Den Lärm haben sie gut rausgefiltert. Ist mir jedenfalls nicht negativ aufgefallen. Oder es war einfach zu interessant. Tauschen möcht ich aber mit Dir echt nicht. :-(

@movq@www.uninformativ.de Now I’m curious what happened.

@movq@www.uninformativ.de Bwahahaha, absolut großartig! :‘-D

We strolled up our backyard mountain. Visibility wasn’t the best, despite the rain we got yesterday. Oh well, scenery was really beautiful, though.

I found it super funny that we almost overtook a jogger before she turned off to another path right in front of us (yeah, we’ve got a smart pace, but this girl was slow as a snail).

https://lyse.isobeef.org/waldspaziergang-2026-07-18/

@dce@hashnix.club I see, ta!

@movq@www.uninformativ.de @prologic@twtxt.net @itsericwoodward@itsericwoodward.com Let me join the Enterprise Ruined It For Me Club. :-D

@david@daiwei.me Yeah, with the long and thus taller list entries, things are getting off hands. Ah, when focused, you wouldn’t differentiate between read or unread.

@prologic@twtxt.net A screenshot won’t help in this case, as you don’t see anything. :-D It starts off just fine with a conversation tree like that:

Unknown conversation root
└╴Read reply
  └╴Read subreply

Everything works. After reloading the feeds, a new message becomes part of the conversation, so the conversation e.g. looks:

Unknown conversation root
└╴Read reply
  ├╴Read subreply
  └╴Unread subreply

However, the bug is that the whole conversation is not shown at all. None of the three (or four with the root) messages appear in the message tree view. My recursive SQL determining the messages to display is clearly broken.

Tops 25°C is a very welcome change. Tomorrow just 21°C (but right before I went to bed they forecasted two degrees less today).

@david@daiwei.me It’s truly mind-boggling. All the hand full of episodes I’ve seen so far on this channel are amazing. Totally worth tuning in. I have to catch up a lot. :-)

Spitzenmäßige Doku über @movq@www.uninformativ.des kleinen Hausflugplatz: https://www.youtube.com/watch?v=F72t2fpiWPo

That’s such a cool The Rest Is Science episode: What Are The Odds You’ll Become A Fossil? https://www.youtube.com/watch?v=cYvDaDb_mbw

I should really fix this damn bug where new replies to read replies to unknown conversation roots are not showing up in tt. I run into this bug almost daily for weeks now.

@movq@www.uninformativ.de Ich war nie im Ubuntuusersforum unterwegs. Aber zu Delphizeiten damals im „Planet Quellcodes“-Forum aktiv, das es längst nicht mehr gibt. Ich schätze, die Hochzeiten der Foren sind einfach rum. Heutzutage ist einmal sehr viel mehr Wissen andersweitig zugänglich und dann sind vermutlich die allermeisten Leute auch einfach auf Soziale-Medien-Plattformen unterwegs. Oder werden die eigenen Projekte auf dem eigenen Blog und dergleichen vorgestellt.

Dann gab’s auch (zumindest gefühlt) eine Zeit, in der man einfach keine sinnvollen Antworten mehr in Foren bekam. So kam das mir jedenfalls vor. Ist schon eine ganze Weile her, aber ich kann mich noch dunkel erinnern, dass ich bei Forensuchtreffern häufig auf Reaktionen à la „such doch selber“ stieß. Oder einfach zuhauf komplett falsche Antworten vorgeschlagen wurden. Ich hab mir dann angewöhnt, Forenbeiträge komplett zu ignorieren.

Einige Foren haben auch noch damit angefangen, anonyme Zugriffe zu unterbinden oder zumindest einzuschränken. Das half im Rückblick natürlich auch nicht, dieses Medium attraktiv zu machen.

@aelaraji@aelaraji.com That’s totally fine if you work at the beach. :-)

@david@daiwei.me Right now, tt’s theme is baked into the binary. I have to edit the ui/styles.go and recompile. Luckily, this almost takes no time. But my todo list already includes a bullet point to make this customizable via the configuration file. :-)

@david@daiwei.me Ha, I just noticed that I changed Newsboat’s defaults. Right from the factory, new items are just bold, while read ones aren’t. No different colors, white on black. Focused items are bold yellow on blue. No matter the read status. I think that’s why I started to play with the config to differentiate them. It’s been so long ago that I didn’t know anymore I even messed with that.

And yes, you’re right, the red on black is borderline readable. Also, my white on green focus is rather silly. But I’m sooo used to it, I don’t realize how bad the contrast is. To be fair, I don’t spend a lot of time in the lists. Aha, there are new articles, Enter to hit the artice view, read it, press n to immediately jump to the next unread article, rince and repeat, finally I’m back in the article list view.

Default theme, read focused:

Image

Default theme, unread focused:

Image

Lyse’s schlimmbesserung, read focused:

Image

Lyse’s schlimmbesserung, unread focused:

Image

@dce@hashnix.club I should maybe look into it some day.

@david@daiwei.me I had to look these up, horror isn’t my genre at all. :-D No idea what the cool kids use today, but I still have zsh as my interactive shell. For shell scripts, though, I try to stick to POSIX and only resort to bash if really needed or it would be too cumbersome.

@david@daiwei.me Not sure if you only mean the code segments or in general. In theory, a general darker text color for read messages would probably work. The thing is that regular white on black is quite standard. In Newsboat, new articles are red (I opted for yellow here) and read ones white. I found that useful and kinda copied it for tt.

@prologic@twtxt.net @movq@www.uninformativ.de Same with tt, hash v2 has to be used right from the epoch onward. (And now replying to a message with a timestamp before the epoch still results in a v1 hash.)

We got some rain. Not a whole lot, but it’s actually cooler now and the temperatures outside are below the ones inside.

Cool, @dce@hashnix.club. You’re the first one I come across who actually writes Korn shell scripts. :-)

As an alternative, I also gave a much simpler teal on gray with reversed colors on focus a shot. Hmm, not so sure either. :-?

Unread messages:

Image

Read messages:

Image

@movq@www.uninformativ.de The nice thing about properties is that you can compute and cache things on the fly at first attempt and also ensure validation for writing. But like you said, since it’s not obvious that reading or writing might do some more things, it’s strongly advised to avoid doing expensive stuff disguised as properties.

I reckon the vast majority of property use cases is to provide read-only access. At least that was my impression when I was doing a lot more in Python.

Personally, I think that this just reads a lot nicer:

oink.my_property
oink.my_property = 42

Than:

oink.get_my_property()
oink.set_my_property(42)

Btw, any field access is implemented using method calls. I might be wrong, but I believe there’s always __getattr__ and __setattr__ involved. 8-)

Unread messages are yellow, while read messages are white in tt. Focusing them just alternates the fore- and background colors. With the old color scheme, I disliked that inline code and code blocks were basically just the opposite of normal text. Hence, unread code was white and read code yellow. I found this often confusing, especially with larger code blocks. Sure, there are the timestamp and author columns that still show the usual white (read) and yellow (unread) background for selected messages, but still.

This is how it was before with unread messages:

Image

Before with read messages:

Image

So, I just reworked the code styles. Not sure if I like that or if it is actually an improvement. Unread code is teal on gray when not in focus and becomes blue on orange when focused. I thought the dark gray code background on a black regular background is still nice and subtle. The same similarity in colors for focused messages meant to go with an orange code background on a yellow regular background. The teal was too light, so went with a blue foreground color:

Image

When read and unfocused, the new color scheme calls for the same code style teal on dark gray. However, with white as the main background for selected messages, I went with a light gray code background and a blue code foreground. Again, the contrast with white and teal wasn’t good enough. Vice versa, blue on dark gray is also not all that readable:

Image

It looks like a parrot. Let’s see if I begin to like it.

@movq@www.uninformativ.de My grief with Java is that it’s sooo verbose. Sure, all the enterprise garbage makes it a hell lot more terrible, but even regular Java feels always so lengthy. And back in the days when I was using it daily, I missed so many convenient things in the stdlib after having experienced Python’s “batteries included”. Not sure if or how recent Java versions caught up.

@david@daiwei.me Oh, really? I thought I’ve posted compose view screenshots before. Anyway. Glad you like it as much as I do. :-)

The update interval has always been one second. I just didn’t remember and thus tried to time it by watching the preview update while typing. It felt like roughly under two seconds, but apparently my inner clock was off. After taking the screenshot and then examining it more closely, I noticed that the interval is stated right in the UI. :-D So, I just amended my message and didn’t bother taking a new screenshot. I figured I just leave it alone and see who spots the change, if at all. And, of course, you found the easter egg. Congrats, mate! 8-)

@movq@www.uninformativ.de Looks like subject parsing is broken.

@david@daiwei.me Ramen! Bon appetit.

@balloon-fu-sen@tw.fus.f5.si Not bad, quite a groovy sound.

@zvava@twtxt.net hunter2

@prologic@twtxt.net Not sure if this really counts as a draft mode or this is what you had in mind. I just was in the editor for ages and didn’t close it. tt provides an integrated preview for the rendered message in there. It automatically updates every second.

Here’s a screenshot of the compose view with the conversation context on the top to which to reply to, the editor in the middle and the almost-live preview at the bottom, I hope it’s big enough:

Image

But it’s not like I hit the “Add message” button in the compose view (the one currently selected on the screenshot), see the message in the conversation tree and then come back into the compose view to continue editing. There’s no edit functionality in tt. Once the message is appended to my twtxt.txt file on disk, all I can do is edit it with vim. The U+2028 line breaks are really annoying to deal with (I’m sure I could do something about that if I spent the time), so I try to avoid that at all costs.

Once new messages have been added to my local file, I then manually upload the file to my server in a separate terminal. There’s no upload command integrated into tt. Right from my very first message in the beginning, I’ve always done it exactly like that. I’m used to this and it really doesn’t bother me. But I can see that others might not be fans of that at all. I might add an upload mechanism to tt at some point in the future.

@david@daiwei.me Very nice!

Dear weather gods, can we please also have a decent amount of rain and not just a few drops that only make the humidity even worse?

@dce@hashnix.club I like the teal colors in the file manager.

@david@daiwei.me You mean, you mean… like mowing down a whole rain forest in a thunderstorm’s brutal heat? :-?

Show us today’s rain. :-)

Now, that’s cool shit, I have to say! Discovering so many hidden sounds… With Fotric Acoustic Imager: https://youtu.be/CKJT_ECOsK4

@david@daiwei.me Hahaahaaahaaaaa, that was funny as heck, mate! I had to laugh really hard! :‘-D

@david@daiwei.me Hahaha, for sure. (But my observation wasn’t meant as a complaint.)

@david@daiwei.me :-D

Wow, 79 new messages over night, similar numbers in the past days. Looks like we’re surfing a high-traffic wave again. :-)

@prologic@twtxt.net @david@daiwei.me Thanks! Hahaha, rest assured, it was not right from the beginning at all. I had to fix it over and over again.

Uuhh, nice, @eldersnake@we.loveprivacy.club is back!

@prologic@twtxt.net Perhaps somebody tried to register “yarn_secret_service”. 8-)

@prologic@twtxt.net Where’s the before picture!? :-D

@movq@www.uninformativ.de Yes, this is absolutely a no-go!

A long time ago when the first telemetry shitstorm happened, I added export GOTELEMETRY=off in my ~/.zshrc. But it doesn’t seem to be picked up at all (I actually call this sabotage!):

$ go env GOTELEMETRY
local

$ go env -w GOTELEMETRY=off
go: GOTELEMETRY cannot be modified

$ go telemetry off

$ go env GOTELEMETRY
off

@prologic@twtxt.net @david@daiwei.me I just want to bring up the following: From a data protection point of view, edits and deletions are important. But that’s about it, I will not join discussions on that topic. :-)

@prologic@twtxt.net You also have to tell us the username!

Hell yeah, @kat@yarn.girlonthemoon.xyz is back! \o/

Hurray, I can now press gg instead of g to go to the top in tt. Much better! :-) Other multi-key combinations are also easily possible now.

I should probably write a real article about this at some point, but here we go. The only downside with my new key binding system is that it breaks tview’s established pattern. You’ve got an InputHandler(), that is implemented using WrapInputHandler(…). It typically then directly implements the switching logic depending on the key press. Something like this:

func (w *Widget) InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    // WrapInputHandler allows for intercepting key events with SetInputCapture(…)
    // from the outside for customization. This handles the default key bindings.
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        switch event.Key() {
        case tcell.KeyRune:
            if event.Modifiers() == tcell.ModNone {
                switch event.Rune() {
                case 'k':
                    w.scrollUp()
                    return // we already handled the event, stop processing

                case 'j':
                    w.scrollDown()
                    return
                }
            }
        }

        // We didn't handle the key event. Maybe the parent
        // widget knows what to do with it.
        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    })
}

From the outside, you can intercept and either stop or continue the widget’s original key handling with a potentially rewritten key event using SetInputCapture(…):

w := NewWidget()
// customized or additional key bindings
w.SetInputCapture(func(event *tcell.EventKey) *tcell.EventKey {
    switch event.Key() {
    case tcell.KeyUp:
        // Rewrite the event, so the "cursor up" key is an alias
        // for the vim key binding "k", that is handled by the
        // wrapped input handler above. (I know, I know, this is a
        // completely unrealistic example, why would anyone use
        // cursor keys when there are vim key bindings available?!)
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)

    case tcell.KeyRune:
        if event.Modifiers() == tcell.ModNone {
            switch event.Rune() {
                case 'q':
                    app.Stop()
                    // we already handled the event, do not pass it
                    // to the wrapped input handler above
                    return nil

                case 'r':
                    toggleMessageReadStatus()
                    return nil
            }
        }
    }

    // we didn't handle the event, pass it to the wrapped
    // input handler above
    return event
}

Since they all expect a single key, I’ve noticed that using multiple dedicated KeyBindings of mine on these different levels kinda breaks multi-key handling with common prefixes. The outer-most KeyBinding captures the prefix, but it can’t transfer it to the inner one if not handled by the outer one. At least not without some more (potentially ugly) changes. So, I now have to work with just a single KeyBindings object for the entire widget chain (if it consists of multiple other widgets or the regular input handler and input capture are in the game). The outside needs to register all its key bind customizations or extensions at the same level that the original widget handles its default ones. Doable by exposing the widget’s KeyBindings instance, but not pretty. You always have to keep this in mind.

With the KeyBindings, it will look like that:

type Widget struct {
    parent tview.Primitive

    // make it available to children or the outside either by
    // direct field access or by providing a getter method
    KeyBindings *bind.KeyBindings
}

func NewWidget() *Widget {
    w := &Widget{KeyBindings: &bind.KeyBindings{}}
    w.KeyBindings. // default key bindings
        Bind0(bind.KeySequence('k', w.scrollUp).
        Bind0(bind.KeySequence('j', w.scrollDown)
    return w
}

func (w *Widget) InputHandler() InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        // also note the missing support for focus transfer at the moment
        event = w.KeyBindings.Capture(event)
        if event == nil {
            return
        }

        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    }
}

And then from the outside, or in a child widget:

w := NewWidget()
w.KeyBindings. // additional or customized key bindings
    Bind1(bind.KeySequence(tcell.KeyUp), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)
    }).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind0(bind.KeySequence('r'), toggleMessageReadStatus)

When directly working with tview primitives that are not part of custom widget implementations, the following works well so far:

textView := tview.NewTextView().
    SetWordWrap(true).
    SetText("…")
    SetScrollable(true)
textView.SetInputCapture((&bind.KeyBindings{}).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind1(bind.KeySequence('g', 'g'), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyHome, 0, tcell.ModNone)
    }).
    Capture)

I need to sleep on this some more.

Also, writing very long messages like this one is really not all that fun in tt’s editor. I should absolutely provide a way to shell out to vim.

(Took me about one and a half hours to compose, holy crap. But not only because of not using vim. Although, that might have saved me a quarter hour or so for sure. Proof-reading this message also uncovered quite a few bugs in my real documentation. So, that’s a big win!) Good night!

@david@daiwei.me Not so keen on the mowing part. :-)

@prologic@twtxt.net That’s a good way to keep spammers out:

Your browser did not pass the anti-spam check! Please make sure JavaScript is enabled and try again.

It was turned on.

@david@daiwei.me Haha, great response!

@movq@www.uninformativ.de Hottest room is still at 24°C. But that will change in this week, no doubt. :-(

@david@daiwei.me I don’t want to start the discussion again, but edits wouldn’t be an issue if we had agreed on a better addressing scheme. Maybe edit more as a quiet riot. :-P

@david@daiwei.me Oh boy, that looks super yummy! :-) I want to have rain here, too!

@david@daiwei.me Exactly. Spaces are fixed, tabs always break the layout when the tab sizes are different.

@david@daiwei.me Hahaahaaahaaaahaaaaa, so good! :‘-D

Nice product, I should probably buy it:

Image

@prologic@twtxt.net For what it’s worth, the twt hash extension is specifically modeled after yarnd’s implementation with all the quirks coming from Go’s stdlib: https://twtxt.dev/exts/twt-hash.html#timestamp-format

“All timezones representing UTC must be formatted using the designated Zulu indicator Z rather than the numeric offsets +00:00 or -00:00. If the timestamp does not explicitly include any timezone information, it must be assumed to be in UTC.”

@aelaraji@aelaraji.com @david@daiwei.me @prologic@twtxt.net It depends on the tab size, but often, a tab aligns the following character to next column that is a multiple of eight.

1      8       |16     |24     |32
2026-07-12T08:11:34+02:00      Here goes the text
2026-07-12T06:11:34Z   Here goes the text

@david@daiwei.me Oh no, what a giant waste of time. :-(