| 15 Nov 2025 |
 Emma [it/its] | the fanciest progress bar ive seen was one that somehow did pixel level stuff | 10:17:43 |
 maralorn | But I am happy to sell themes in the in-app store. 🥴 | 10:17:47 |
| Emma [it/its] | not sure if it was using sixels or what | 10:17:51 |
| Emma [it/its] | nor which package manager that was | 10:18:09 |
| maralorn | I mean it is actually not that hard to build a solid progressbar with one-eighth of a character steps via unicode box drawing characters. | 13:02:16 |
| maralorn | But my feeling was that having progressbars spanning a the full height of a line would be to massive and hurt the overall aesthetic of nom. | 13:03:15 |
| Emma [it/its] | sounds like pacman might be a good option then :P | 13:07:28 |
| Emma [it/its] | because its only the left and right borders that realy take up a full line | 13:07:43 |
| maralorn | I am not against whimsy. 😄 | 13:11:51 |
| maralorn | Just feels a little bit derivative. | 13:12:05 |
| maralorn | I guess we could make it configurable at some point. 😄 | 13:13:12 |
| Emma [it/its] | fwiw, the pacman default is just #'s without colors :P you enable the pacman animation by adding ILoveCandy to the pacman config | 13:30:22 |
| maralorn | Ah, I see. | 13:33:03 |
| Emma [it/its] | not that it isnt a common configuration for obvious reasons :P | 13:33:40 |
| maralorn | Okay, my plan was anyway to have three levels for nom: ascii-only, only-unicode, full-emoji | 13:34:28 |
| maralorn | And we can add a fourth level whimsy-overload | 13:34:48 |
| 17 Nov 2025 |
 saygo.2 | In reply to @maralorn:maralorn.de
saygo.2: And in regards to "try"-ing I’d be more than happy to help/mentor. Should nom-build stay a pure wrapper? I envision that nom will support more flags once optparse is used. Should we use something like nom build <nom-args> -- <nix args> or stay with the current pure ? | 15:22:04 |
| saygo.2 | * Should nom build stay a pure wrapper? I envision that nom will support more flags once optparse is used. Should we use something like
nom build <nom-args> -- <nix args> or stay with the current pure ? | 15:22:14 |
| saygo.2 | Right now there also is inconsistency in --version. `nom-build --version` lists the nix and nom version, but `nom build --version` does not. | 15:24:31 |
| saygo.2 | * Right now there also is inconsistency in --version. `nom-build --version` lists the nix and nom version, but `nom build --version` only lists nix | 15:25:04 |
| saygo.2 | ugh element ate my <> characters | 15:27:57 |
| saygo.2 | * Should nom build stay a pure wrapper? I envision that nom will support more flags once optparse is used. Should we use something like
`nom build (nom args) -- (nix args)` or stay with the current pure `(nix args)`? | 15:28:58 |
| maralorn | I guess that sounds like a bug we should fix. | 15:29:06 |
| maralorn | I haven’t made up my mind about this. There are different thinks to consider, e.g. how to not break tab completion. | 15:29:07 |
| maralorn | But I think I would like it to stay a drop in replacement, but maybe we can just "inject" nom specific options with a common prefix. | 15:29:08 |
| maralorn | e.g. --nom-show-tree | 15:29:08 |
| maralorn | Or --nom-show-outputs | 15:29:35 |
| saygo.2 | In reply to @maralorn:maralorn.de
I haven’t made up my mind about this. There are different thinks to consider, e.g. how to not break tab completion. Ill see how optparse applicative handles this. There is some support for wrapper programs like nom for example here https://hackage-content.haskell.org/package/optparse-applicative-0.19.0.0/docs/Options-Applicative.html#v:forwardOptions and completions should be customizable enough to make -- work well too | 15:38:22 |
| maralorn | Cool! | 15:38:55 |
| maralorn | This is relatively greenfield so if you find arguments to do stuff differently please tell me so that we can discuss. | 15:39:35 |
