Nim's import rules are part of its generalization of OOP's obj.foo()
syntax. That is, in Nim, you don't have to put "foo" in a specific
class, just set the first parameter of "foo" to the type of "obj",
and this only works if you don't have to qualify "foo" (similarly to OOP
languages...)
I don't see how Nim's import is necessary for that to happen. You can allow the user to specify items to import without the qualifier (like Python's `from lib import foo`), and the universal function call syntax would work, too.
That is allowed, with the exact same syntax as Python. But then you still lose the qualification so I don't see any benefits, it's just more boilerplate to constantly adjust, git conflicts to fight with, etc.
The difference between valid PNG you can't decompress and invalid PNG is fairly irrelevant when your aim is to get an image onto the screen.
And considering we already have plenty of more advanced competing lossless formats, I really don't see why "feed a BMP to deflate" needs a new, incompatible spin in 2025.
More generally, PNG has a simple feature to specify what's needed. A file consists of a number of chunks, and one bit in the chunk specifies whether that chunk is required for display. All of the extensions I've seen in the past decades set that bit to "optional".
For example, this update includes a chunk containing EXIF data. As you'd expect, the exif chunk sets that bit to "optional".
> plenty of more advanced competing lossless formats
Other than JXL which still has somewhat spotty support in older software? TIFF comes to mind but AFAIK its size tends to be worse than PNG. Edit: Oh right OpenEXR as well. How widespread is support for that in common end user image viewer software though?
The back sensor had an indent too, so you could easily feel it. Hold your phone in your hand. Where does your index finger sit? If it is on the back of the phone, that's where the sensor was. It was very natural.
Sure, but I'm talking about where my fingers first reach when taking the
device out of my pocket.
In that case, I'm grabbing it with my thumb, index finger and middle
finger, and since the phone is seated upside down, my thumb reaches the
home button before I'm even holding it in my palm.
On phones with a fingerprint sensor on the back, I first have to get a
full grip, and then I can reach for the sensor.
Surely it's a hobby project. You have to have very specific tastes to browse in the terminal in 2025.
> using external binaries for protocols feels like sidestepping the real engineering
You could easily move all protocols to the main binary. The reason for the current arrangement is that this way, you can e.g. replace the HTTP handler with curl-impersonate, or add custom protocols like magnet (etc.) See the bonus directory in the sources for inspiration.
> tied to niche image formats like sixel/kitty which barely anyone supports.
Sixel & Kitty are the only image formats anybody supports. The alternatives are ASCII art (fun, but too pixelated) & hacking images onto the terminal thru the display server (is that still a terminal-based app?) But I'm happy to discuss further, I find the issue fascinating :)
> mac
The macOS issue is largely a function of the only person working on this not having a mac. If you do, you can help solving it by debugging it yourself & posting the results: https://todo.sr.ht/~bptato/chawan/63
chawan has a custom terminal module, so my knowledge about the standard X/Open curses is not that great.
That said, for the actual escape sequences, XTerm's ctlseqs.ms[1] is an invaluable resource. I also took many ideas from nick black's notcurses[2], and I especially recommend his notes on "sprixels".[3]
I have implemented changes based on your advice of using @media: grid, and everything looks better now. You can check it here: https://brutalinks.tech (it's a link aggregator similar to HN).
I had no idea this CSS API existed. I'll add that to my CSS, thank you! :)
I'll check if the issue tracker has anything related to supporting titled alternate stylesheets (and eventually allowing users to pick one of them), because on the website where I made efforts for the markup to look reasonable on links, I also have a "simple" style that removes most of the CSS fanciness.
Chawan never really used ncurses, only termcap. (ncurses just happens to implement termcap too.)
I started with termcap because I was already familiar with it through
w3m. But termcap is an obsolete interface, and cannot describe the only
useful attribute for modern terminals (true color). Its only benefit
was "maybe it accidentally works on a hardware terminal from the 80s",
which is cool but not really worth the extra failure mode.
So instead of migrating to terminfo, I ditched it completely in favor of
terminal queries (which were already necessary for other reasons).
There is still a built-in terminal database, to detect known TERM values
with XTerm incompatibilities. But a terminal that correctly responds to
queries will work out of the box, even if its TERM value is unknown.
> I started with termcap because I was already familiar with it through w3m. But termcap is an obsolete interface, and cannot describe the only useful attribute for modern terminals (true color). Its only benefit was "maybe it accidentally works on a hardware terminal from the 80s", which is cool but not really worth the extra failure mode.
Priorities, I guess. As long as I'm in a terminal, I'd rather have support for hardware terminals from the 80s than truecolor. But my only hardware terminal is a VT-420, so probably works for more or less anything that supports base XTerm (monochrome).
Could you please pull the macos-input branch from
https://git.sr.ht/~bptato/chawan and report back on what the `a` file
includes after opening a site and typing some commands?
(Should be created in the current working directory.)
Here's the contents of a. Let me know if there are any other commands you'd like me to type.
```
handleCommandInput 1, buffer "" c 'j'
handleCommandInput 2, buffer "" c 'j'
after handleCommandInput, buffer 0x104c5b780"j" c 'j'
handleCommandInput 1, buffer "" c 'k'
handleCommandInput 2, buffer "" c 'k'
after handleCommandInput, buffer 0x104ca8b70"k" c 'k'
handleCommandInput 1, buffer "" c 'l'
handleCommandInput 2, buffer "" c 'l'
after handleCommandInput, buffer 0x104c5bab0"l" c 'l'
handleCommandInput 1, buffer "" c 'k'
handleCommandInput 2, buffer "" c 'k'
after handleCommandInput, buffer 0x104ca8d20"k" c 'k'
handleCommandInput 1, buffer "" c 'j'
handleCommandInput 2, buffer "" c 'j'
after handleCommandInput, buffer 0x104c5b480"j" c 'j'
handleCommandInput 1, buffer "" c 'h'
handleCommandInput 2, buffer "" c 'h'
after handleCommandInput, buffer 0x104ca89c0"h" c 'h'
handleCommandInput 1, buffer "" c 'g'
handleCommandInput 2, buffer "" c 'g'
after handleCommandInput, buffer 0x104cae780"g" c 'g'
handleCommandInput 1, buffer "" c '1'
after handleCommandInput, buffer "" c '1'
handleCommandInput 1, buffer "" c '2'
after handleCommandInput, buffer "" c '2'
handleCommandInput 1, buffer "" c '3'
after handleCommandInput, buffer "" c '3'
handleCommandInput 1, buffer "" c '1'
after handleCommandInput, buffer "" c '1'
handleCommandInput 1, buffer "" c '2'
after handleCommandInput, buffer "" c '2'
handleCommandInput 1, buffer "" c '2'
after handleCommandInput, buffer "" c '2'
handleCommandInput 1, buffer "" c '3'
after handleCommandInput, buffer "" c '3'
handleCommandInput 1, buffer "" c '\3'
handleCommandInput 2, buffer "" c '\3'
after handleCommandInput, buffer 0x104cae690"\3" c '\3'
handleCommandInput 1, buffer "" c '\3'
handleCommandInput 2, buffer "" c '\3'
after handleCommandInput, buffer 0x104adaed0"\3" c '\3'
handleCommandInput 1, buffer "" c '\3'
handleCommandInput 2, buffer "" c '\3'
after handleCommandInput, buffer 0x104ca8720"\3" c '\3'
handleCommandInput 1, buffer "" c '\4'
handleCommandInput 2, buffer "" c '\4'
after handleCommandInput, buffer 0x104bf8d80"\4" c '\4'
handleCommandInput 1, buffer "" c '\3'
handleCommandInput 2, buffer "" c '\3'
after handleCommandInput, buffer 0x104caaa80"\3" c '\3'
handleCommandInput 1, buffer "" c '\4'
handleCommandInput 2, buffer "" c '\4'
after handleCommandInput, buffer 0x104ca8e40"\4" c '\4'
```
reply