@movq@www.uninformativ.de I’m completely with you. I just do rivo’s approach with some of my own stuff that nobody ever sees. But the vast majority gets a real version. Probably not a changelog, but a version. And it’s very small stuff.

Die Meisterschaft der Speisewagenschieber in Stuttgart: https://www.youtube.com/watch?v=OfgwdBBWzCw

Eine großartige Vorstellung einer Unfalluntersuchung. :-D

There: https://github.com/rivo/tview/issues/442#issuecomment-641898039

@movq@www.uninformativ.de Yes. The author tries hard not to break existing code, but apparently he did this time. In his defense, it’s not an official release, I just updated to master. Which is exactly what I always did in the past as there are no real versions (I even think that in one ticket he wrote years ago that master is always stable). That has finally changed a year ago, though: https://github.com/rivo/tview/releases/tag/v0.42.0

@movq@www.uninformativ.de Brilliant! Oh, I’m super happy to get it all wrong together with you. :-)

[Release notes] are meant for human beings, it’s a human-to-human interaction.

This is one of the most important messages. Absolute key, but misunderstood so often.

@movq@www.uninformativ.de Exactly!

Fuck me! I tried to upgrade tview and the first thing I notice is a shitload of added dependency versions:

go.mod | 18 ++++-----
go.sum | 97 ++++++++++++++++++++++++++++++++++++++-----------

My code does not compile anymore as the view.FormItem interface was extended. Get/SetDisabled(…) are quickly implemented, no worries.

But the tview.Primitive (what makes a widget) interface has now a bunch of PRIVATE methods. For focus handling. Would you believe that!? Thanks, I cannot satisfy this interface in my very custom widgets anymore. Okay then, I just embed *tview.Box. tt now successfully compiles, but does not react anymore on key presses and the message tree is not focused either.

I’m not in the mood to debug this shit. :-( Lunch time.

@movq@www.uninformativ.de I just ran across another thing. At least I personally couldn’t care less about CI infrastructure changes. Whether they’re using github action a or b or c or version v or w, it is not of my interest. At all. (It might be useful to estimate the supply chain attack risk, though.) If the maintainers want to include them in the changelog – and there are probably people to whom this information is crucial – it’s probably best to document CI infrastructure changes in their own section.

@movq@www.uninformativ.de You may want to include another antipattern to avoid in your article:

• bump $same_dependency from 1.0.0 to 1.0.1
  
• bump $same_dependency from 1.0.1 to 1.0.2
  
• bump $same_dependency from 1.0.2 to 1.1.0
  
• bump $same_dependency from 1.1.0 to 1.2.0

@movq@www.uninformativ.de Thank you very much! So, the concept is very similar. The root widget gets the input and can pass it to whatever child has the focus and so on.

My two main issues are the API design, that the input handler sometimes get an additional callback to notify the application about which element is focused, but sometimes not. And that focus switching sometimes just does not work as expected. Anyway.

As for rendering the selected button, I was also thinking about indicating it with some kind of border around it, square brackets seem to be a wonderful choice. :-)

Another thing: With multicolored TUIs, I find it usually hard to immediately tell which button is selected if there are just two. I’m asking people for any relevant information. :-)

Getting the vim key bindings to work for focus switching in this modal dialog took me forever. Only cursors and (Shift+)Tab are supported out of the box. I absolutely understand that, it’s fine. I installed an input handler on the dialog, but the focus always stayed the same.

After two wasted hours, I was in despair to copy the tview.Modal into my own code base. Of course, I had to fix all the private tview field accesses first. But even installing the input handler directly on the buttons themselves did not work. Even though, the handler was definitely executed, the focus did not shift. Forcing redraws as a last resort also did not work.

Looking through all the messy chained input handling, I eventually stumbled across another place in the tview.Form, which is internally used by tview.Modal. This messed around with app focus receptions and input handlers. This gave me the idea to make the tview.Application refocus my modal dialog after I told the modal dialog which button to select. And would you look at that, this did the trick! I haven’t completely figured out what is going on exactly, but I could get rid of my Modal clone again.

I always go through hell with focus handling in tview. Each and every time. It just does not feel natural to me. Complete brainfuck to wrap my head around. The Urwid API felt sooo much more refined, it never was an issue. It just works. In fact, I cannot think of any other TUI library that has remotely the same pain level when it comes to focusing widgets as tview.

Now I’m curious how movwin deals with that. ;-)

Every now and then, I think that I have carefully proof-read my message enough times and hit the “Add message” button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt’s cache. This is rather tidious:

1. Recall the sqlitebrowser ~/.local/share/twtxt/tt2.sqlite from my shell history.
   
2. Switch to the “Browse data” tab.
   
3. Go to the messages table and wait a second or two until it’s loaded.
   
4. Sort by the created_at column twice, so that I get descending order.
   
5. Select the first message, which is typically the one in question.
   
6. Find the “Remove currently selected row” button in the tool bar.
   
7. Commit the changes.
   
8. Close sqlitebrowser.
   

So, I finally implemented the removal of messages from the cache in tt. I can now hit d and confirm the removal. Bam! Should have done that ages ago!

https://lyse.isobeef.org/tmp/tt-confirm-message-removal.png

Next up is the search, I think.

@movq@www.uninformativ.de Right, at work, nobody gives a fuck. At all. There are so many universes between my definition of quality and everybody else’s.

Let’s stop here and enjoy the weekend or vacation. :-)

@movq@www.uninformativ.de Hahaha, great timing! :-D I love your article and agree with almost all your points.

On the AI changelog part, though, I’d rather recommend to just not have a changelog at all.

Another important thing for me is the deprecation notice section. What do I need to look out for in the future? Should I start to migrate to another API soon? Even right now? Or does it have time?

While going through these terrible GitHub release pages, I also found these “New Project Contributors” sections (yeah, for that, they found the time to make a section) annoying. Don’t get me wrong, sure, credit where credit is due. But come on. Soooooo much space for an inefficiently formatted (and also unsorted) list. At least it was easy enough to skip over it.

And then, there are also these changelogs or rather notice documents in general that are infested with multicolored emojis all over the place. My brain’s spam filter kicks in and shoves everything to /dev/null immediately. It’s especially a thing at work.

In my previous work project, we also used the Keep A Changelog Format. That was great. You wouldn’t believe how often I resorted back to that document. At least twice a week, often several times a day. I was very glad that we put in this effort. Of course, writing the changelog took its time, but it was worth every minute and more. Reading a many months old item, it was immediately clear. I was our best customer in that regard.

Now, it’s just the same auto shitshow with MR titles in a rolling date-versioned release scheme. It’s just our team who has to deal with that, though. I think I’m the only one who is not a fan of it.

I just fixed it.

@movq@www.uninformativ.de Next town, they use Fernwärme from the waste incineration plant to heat the hospital and probably also parts of the neighborhood. I don’t know how good it works, but in the cold months there’s always steam coming out of the manholes along the road through the woods. I very rarely am in this area, but whenever I am, the steam on the side of the road always amazes me.

@bender@twtxt.net Yeah, you absolutely must experience them yourself in person. :-)

Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this “changelog” is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then “Add feature X”, seventeen kilometers further down “Revert ‘Add feature X’”. Fuck you! Don’t include this shit in the first place!

Fits absolutely perfect in the pattern of rapid decline.

I must rip out all dependencies as soon as possible whose maintainers just don’t give a shit.

I went to check on the fireflies this season. But I didn’t see any. Instead lots of moths. At first, I thought it might have been still too light, but it was already dark enough for me to miss and destroy a snail shell. Bummer. Maybe it was too wet tonight. Although, it’s probably just another or two weeks until my glowing friends will finally show up.

In the beginning, I passed two beautiful deer on the edge of the forest. They were just ten meters away, but didn’t run off, really cool. :-) I kept on walking. Before I eventually left the woodland, a frog or toad crossed my path. It was very dark by then, though, so all I could see was a black blob.

Back in town, the street lamps on the first third were all turned off for some reason. I was already glad that I will reach home without getting blinded this time, but unfortunately, the other lamps were all operational.

@bender@twtxt.net Those damn foreigners shall not enjoy our German music, how dare they! Something like that.

@movq@www.uninformativ.de Hmm, indeed, this sounds a bit weird. Is it Fernwärme?

@movq@www.uninformativ.de What the heck! Construction work? Eventually, one has to resort to the good old bucket shower. Maybe raise the comfort level with a kettle.

It’s raining all day long over here. You could just stand outside for a while.

I hope it’s back sooner than later!

@prologic@twtxt.net Too bad.

@prologic@twtxt.net Ninjababypowpowpow, NINJA BABY POW POW POW! https://www.youtube.com/watch?v=1dK8NeTWN7w

The lyrics are also fitting quite well I have to say. :-) https://www.die-aerzte-archiv.de/bela-b/songtexte/song/ninjababypowpow.html

@movq@www.uninformativ.de Uh, uh, uh, yeah, nice! Perfect time to spend the holidays in Green- or Iceland. :-)

@movq@www.uninformativ.de Work to rule. And yeah, absolutely horrible time to look for something else. :-(

@movq@www.uninformativ.de Oh yeah, way better! :-) I didn’t spot the bug, though.

I think I could work with the feature set. I typically don’t need a lot. Until I do. :-D The message tree in tt is an example of that. But tt is also special that it needs something like this in the first place. It’s unusual.

@bender@twtxt.net @movq@www.uninformativ.de Ta! It’s the chemtrails that they cannot stomach. :-D

@movq@www.uninformativ.de Be careful, sounds like the latter to me. Get a good rest, though! And maybe slow down a tad once you’re back. But now, enjoy your private hacking. :-)

@movq@www.uninformativ.de That is really cool! Maybe it would look nicer if the selected entry highlighted the whole row, not just the individual cells in that row without the column spacers. :-? But maybe I’m wrong. Everyone has their own taste.

And no, it’s not pointless at all. I find this really interesting. The videos and photos are perfect for me. Even if I had the source code, I would not use that toolkit, as I’m not a fan of movable windows in TUIs. I want all my own programs to be fullscreen all the time. 8-) Having said that, it’s still an absolutely brilliant source of inspriation that will come in handy one day. So, keep posting. :-)

We just got some unicorn vomit again: https://lyse.isobeef.org/abendhimmel-2026-06-09/

Herzlichen Glückwunsch, @arne@uplegger.eu!

@itsericwoodward@itsericwoodward.com Turns out, this is a bug in my config to cache synchronization. Nickname changes in the configuration file are just not synced to the cache at startup if the feed URL already exists in the cache. I must have fixed this typo in my config ages ago, because I don’t even recall having that spelling mistake to begin with. Yet, the cache was happily showing the erroneous nickname. Composing a reply automatically adds the mentions from the conversation participants. Everything originates from the cache, so, I successfully poissoned my replies.

@itsericwoodward@itsericwoodward.com Dang it, my apologies for butchering your nick, mate! :-( Unbelievable, that I did not notice this in all those months. But it’s great to trade mention errors. :-)

@itsericwoordward@itsericwoodward.com I just want to let you know that your mention completion seems to be broken. :-) The URL is duplicated with a comma in between. Actually, the protocols differ. I suspect that you extract all url metadata fields from the feed, not only the canonical one used for hashing (the first one) and join them. I’m not completely sure, I would need to read up on the specs (it’s already past bed o’clock, though), but I guess that there is no explicit rule for picking the mention URL. Without having thought about it too much, I reckon the safest bet is to stick to the hashing URL when in doubt and the URL that was used to subscribe to the feed is not available for whatever reason. The URL from the subscription list is probably even better.

@movq@www.uninformativ.de Exactly! :-D

I just came across these two covers which stood out to me:

• https://www.youtube.com/watch?v=tVvhHydubR0

  played a bit faster, and faster is almost always better
  

• https://www.youtube.com/watch?v=rpwGUx0Sz_4

  a choire’s polyphony usually makes things automatically better

@movq@www.uninformativ.de Classic song! :-)

The targets are well spread across the forest, it’s impossible that they end up hitting others on accident. The only dangerous station is the one with the white swan. Since they shoot from the other side of the tad pole pond, they might actually hit people on the forest path (where I took the photo) when they miss the target and provided the shot is powerful enough. We were on our way before the archers started their loop trial.

@movq@www.uninformativ.de Great, now I’ve got the Shadow On The Wall earworm for some reason. :-D

@movq@www.uninformativ.de Oh, whoops, hahaha! :-D Yeah, I also noticed Markus’ Unicode work yesterday. Really cool.

@bender@twtxt.net @prologic@twtxt.net Hahaha, okay, I’ll leave them then. :-D

@movq@www.uninformativ.de That’s my experience, too.

@movq@www.uninformativ.de Great to be asked for feedback! I just noticed that the first wcwidth version was derived from Markus Kuhn’s C code. I came across him in my ISO 8601 and RFC 3339 endeavors the other day. https://www.cl.cam.ac.uk/~mgk25/iso-time.html What a surprise. :-)

@movq@www.uninformativ.de I see the Make rewrite popping up on the horizon. :-)

We came across lots of animals in our woodland. There’s a medieval market this weekend in the neighboring town and they use these targets for the bowmen.

https://lyse.isobeef.org/waldspaziergang-2026-06-06/

I might have to clean windows tomorrow. https://lyse.isobeef.org/voegel-2026-06-05/

@movq@www.uninformativ.de Not bad. How many e-mails or other forms of feedback did you get?

@movq@www.uninformativ.de Ah, I see. Oh, so not even make, just a shell script. :-)

@movq@www.uninformativ.de Yes.

Maybe management should replace itself with AI…

@movq@www.uninformativ.de :-D