(#ex5vwtq) At around 19 seconds in the video, you can see some minor graphical glitches.
Text mode applications in Unix terminals are such a mess. Itās a miracle that this works at all.
In the old DOS days, you could get text (and colors) on the screen just by writing to memory, because the VGA memory was mapped to a fixed address. We donāt have that model anymore. To write a character to a certain position, you have to send an escape sequence to move the cursor to that position, then more escape sequences to set the color/attributes, then more escape sequences to get the cursor to where you actually want it. And then of course UTF-8 on top, i.e. you have no idea what the terminal will actually do when you send it a āšā.
ncurses does an amazing job here. Itās fast (by having off-screen buffers and tracking changes, so it rarely has to actually send full screen updates to the terminal) and reliable and works across terminals. Without the terminfo database that keeps track of which terminal supports/requires which escape sequences, weād be lost.
But gosh, what a mess this is under the hood ā¦ Makes you really miss memory mapped VGA and mouse drivers.
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.)
(#wap76wa) @lyse@lyse.isobeef.org I havenāt spoken to a single person yet who was a fan of all this. Not even the more conservative family members.
Some people have detonated several really loud bombs yesterday. This wasnāt a āBƶllerā. It shook my walls, doors, windows. Family members in other parts of the country reported the same ā¦ Is this a new trend?
The only good thing about this absolute craziness is that I can restock my rocket sticks. I picked up twelve along the way. Unfortunately, it looks like 99.999% of ammunition is bombs instead of rockets. Some sections of my street look exactly like an arbitrary Pakistanian town that Iāve seen online.
There was surprisingly much snow in the woods. Also, all ponds have frozen over. I didnāt expect that. Not at all. There were even illegal ice skating tracks in the natural reserve. We came across a large puddle and it was at least 10cm solid ice to the ground. Crazy!
(#y656lsa) @lyse@lyse.isobeef.org Itās actually not nearly as half bad as I really thought it would be. Just having to eventually deal with the ālowering downā to machine code / ARM64 assembly in the end once youāve verified the semantics in the VM.
(#y656lsa) @prologic@twtxt.net Not bad for a start, ey! Looking forward to see you going down these rabbit holes and opening one can of worms after the other. :ā-D Very, very impressive, hats off to you. :-)
(#p43aoaq) @lyse@lyse.isobeef.org A āHello Worldā binary is ~372KB in size. I currently have peephole optimization and deac code optimizations in play, and a few other performance related ones, but nothing too fancy. I have a test case that ensures fib(35) doesnāt regress too badly as I continue to evolve the language.
Do you think Mu (Āµ)ās native compiler and therefore emitted machine code āruntimeā (which obviously adds a bit of weight to the resulting binary, and runtime overheads) needs to support āruntime stack tracesā, or would it be enough to only support that in the bytecode VM interpreter for debuggability / quick feedback loops and instead just rely on flat (no stacktraces) errors in natively built compiled executables?
Excluding merges, 1 author has pushed 171 commits to main and 175 commits to all branches. On main, 294 files have changed and there have been 52880 additions and 18269 deletions.
inline and multiline code blocks using single/double/triple backticks (but no code blocks with just indentation)
markdown links using using [text](url)
markdown media links using 
And thatās it. No bold, italics, lists, quotes, headlines, etc.
Just like mentions, plain URLs, markdown links and markdown media URLs are highlighted and available in the URLs View. Theyāre also colored differently, similarly to code segments.
I definitely should write some documentation and provide screenshots.
(#5pjhgha) @lyse@lyse.isobeef.org You actually have a Markdown parser/renderer in there? Oh dear. I would have been (well, I am) way too lazy for that. š
It totally sounds like an active warzone around here. So, I just went on a very, very, very quick stroll to check out our sunset from ontop our hill (were all the bangs are way more horrible): https://lyse.isobeef.org/abendhimmel-2025-12-31/
Hurray, I finally fixed another rendering bug in tt that was bugging me for a long time. Previously, when there were empty lines in a markdown multiline code block, the background color of the code block had not been used for the empty lines. So, this then looked as if there were actually several code blocks instead of a single one.
(#2p27wba) @movq@www.uninformativ.de Yeah, I see. Just crudely checked on my computer, with around 0.013 seconds, Python 2.7 seems a tad faster than Python 3.14ās 0.023 seconds in this little program.
The lazy imports sound not too bad, but I just skimmed over them. There are surprisingly many exceptions, but yeah, no way around them. :-)
mu (Āµ) now has builtin code formatting and linting tools, making Āµ far more useful and useable as a general purpose programming language. Mu now includes:
An interpreter for quick āscriptinogā
A native code compiler for building native executables (Darwin / macOS only for now)
A builtin set of developer tools, currently: fmt (-fmt), check (-check) and test (-test).
I assume you made the thing load quickly, didnāt you?
Thatās the problem with Python. If you have a couple of files to import, it will take time.
I want this to be reasonably fast on my old Intel NUC from 2016 (Celeron N3050 @ 1.60GHz) and I already notice that the program startup takes about 95 ms (or 125 ms when there are no .pyc files yet). Thatās still fine, but it shows that Iāll have to be careful and keep this thing very small ā¦
Python 3.14 will bring lazy imports, maybe that can help in some cases.
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:
I just fixed another bug in tt where the language hint in multiline markdown code blocks had not been stripped before rendering. It just looked like it was part of the actual code, which was ugly. I now throw it away. Actually, itās already extracted into the data model for possible future syntax highlighting.
It just doesnāt look aligned properly: https://lyse.isobeef.org/tmp/misalignment.png Could be a yarnd issue, though, it might not expect a logo this large. Just wildguessing, no idea.
(#ys4znqq) @shinyoukai@neko.laidback.moe Because you might not want to commit all changed files in a single commit. I very often make use of this and create several commits. In fact, I like to git add --patch to interactively select which parts of a file go in the next commit. This happens most likely when refactoring during a feature implementation or bug fix. I couldnāt live without that anymore. :-)
If you have a much more organized way of working where this does not come up, you can just git commit --all to include all changed files in the next commit without git adding them first. But new files still have to be git added manually once.
(#555iyvq) @shinyoukai@neko.laidback.moe Do we now need ad filters in twtxt clients, too? O_o I hope not! Personally, I cannot stand the āSent with my crappy $phone/$appā e-mail footers.
(#iudi6qq) @shinyoukai@neko.laidback.moe Yeah, they donāt truly support XDG. In fact, I looked in the Go stdlib source code to notice all the differences and shortcomings.
(#3hge2sq) 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.
(#iudi6qq) Hmm, mine also resolves a leading tilde in these variables. And if $HOME is not specified it tries to resolve the userās home directory by user.Current().HomeDir. Maybe thatās overkill, I have to check the XDG spec.
But Iām definitely missing os.UserDataDir(). Thatās a bummer.
(#f2cdpva) @movq@www.uninformativ.de Thanks! Iāll have a look at SnipMate. Currently, Iām (mis)using the abbreviation mechanism to expand a code snippet inplace, e.g.
autocmd FileType go inoreab <buffer> testfunc func Test(t *testing.T) {<CR>}<ESC>k0wwi
or this monstrosity:
autocmd FileType go inoreab <buffer> tabletest for _, tt := range []struct {<CR> name string<CR><CR><BS>}{<CR> {<CR> name: "",<CR><BS>},<CR><BS>} {<CR> t.Run(tt.name, func(t *testing.T) {<CR><CR>})<CR><BS>}<ESC>9ki<TAB>
But this of course has the disadvantage that I still have to remove the last space or tab to trigger the expansion by hand again. Itās a bit annoying, but better than typing it out by hand.