The comparison has two points one of which says that for "Complex scripts (Devanagari, Arabic)", ghostty-web has " Proper grapheme handling". But when I tried something extremely simple at the https://ghostty-web.wasmer.app/ or https://ghostty.ondis.co/ demos (just `echo "कवि"`), it failed pretty miserably (and in different ways in the two demos). So I'm not sure what to make of it.
(Seems slightly better in the actual Ghostty app, but not in any usable way: here was my comparison last year https://shreevatsa.net/post/terminal-indic/ and Ghostty is comparable to the other terminal apps, better than some, worse than some. Anyway the fact that it works in Ghostty but not in ghostty-web casts doubt on “Ghostty's emulator is the same battle-tested code that runs the native Ghostty app”. Do you understand what is going on?)
It's very much the same emulator but we're exposing a subset of functionality via WASM, in this case it wasn't handling grapheme codepoints correctly. It should be fixed on main (or @next).
bummer
> The code relies on old internal Infocom toolchains (ZILCH compiler, WATFOR,
> mainframe environment) that are not open and likely not preserved.
I hope some of those other Infocom tools eventually get open sourced for historic curiosity, but ZILF is probably going to remain the modern answer for how to compile these files.
> Basic Information on the Contents of This Repository
>
> It is mostly important to note that there is currently no known way to compile the source code in this repository into a final "Z-machine Interpreter Program" (ZIP) file using an official Infocom-built compiler. There is a user-maintained compiler named ZILF that has been shown to successfully compile these .ZIL files with minor issues. There are .ZIP files in some of the Infocom Source Code repositories but they were there as of final spin-down of the Infocom Drive and the means to create them is currently lost.
>
> ...
>
> In general, Infocom games were created by taking previous Infocom source code, copying the directory, and making changes until the game worked the way the current Implementor needed. Structure, therefore, tended to follow from game to game and may or may not accurately reflect the actual function of the code.
How bad is it? I mean you have the source, it could be ported. Or am I completely misunderstanding and you specifically want the old toolchains, in which case A respectful moment of silence for compilers lost.
Speaking of porting I have always vaguely wanted to port the original basic version of ultima, I mean never enough to actually do it, but I like the idea of the source being available to do so. even if it is just an accidental artifact of how it was made.
These statements really ring home when i'm thinking about my 20s and coding.
Back then, i'd dive right in, start coding, prove what works, figure it out as I go, then have to adapt the existing code to the figured out design. I was much more attached to that code and didn't want to lose it. Today, if I write code, I plan it out, have a good idea of how the pieces will work and then go implement it. And honestly, if the code gets thrown away, it's not the end of the world.
Code is really a small portion of what engineers do...
I started thinking about how to build this at one point but never got around to it. i've thought about doing this with QR code stickers, but the NFC approach might be nicer.
reply