And I'm curious about nesting being "pretty difficult to implement in tooling"---how do you mean? At least with emacs I found it no more difficult than counting whitespace characters: https://git.sr.ht/~rfm/tdtd-mode/tree/master/item/readme.md
I’ve tried to implement the item nesting in the [x]it! Sublime Text plugin. The problem there was that I didn’t manage to implement strict rules for subitems. If you consider the following example:
[x] Example item
[ ] Subitem
[ ] Another Sub-Sub Item
Continuation of the first item’s description
Some problems I encountered:
- The “Another Sub-Sub Item” should not be allowed, because it skips one level (from the first to the third, instead of to the second).
- The “Continuation of the first item’s description” should not be allowed, because it only makes sense for sub-items to appear after an item’s description, but not in between.
- It also doesn’t seem to be possible for sub-items to inherit their parent’s status, e.g. if the parent is checked, to also colour the sub-item as if it was checked.
Oh, interesting. When you put it that way---"Example item" and "Continuation ..." being the same semantic unit---I see the problem. And why nesting is easier to implement when the semantics are based on lines.
I think it's also interesting the way you say "The “Another Sub-Sub Item” should not be allowed". Seems to me the format and tooling should do what the user wants and expects, or at least try to. Why not allow it if the user wants it that way?
I realised that I made a small mistake in my code sample above, but I can’t edit the post anymore. It should have been:
[x] Example item
[ ] Subitem
[ ] Another Sub-Sub Item
Continuation of the first item’s description
(Last line is indented, because continuations of descriptions have to be indented.)
The “Another Sub-Sub Item” wouldn’t make sense in my mind, because the idea is that the text maps to well-defined data structures, in this case a tree structure. So an item can have child items, which each can have child items, and so on. However, “Subitem” doesn’t have direct child items.
I find this restriction important, because it would allow to parse the text into relatively simple programmatic models.
> The “Another Sub-Sub Item” wouldn’t make sense in my mind, because the idea is that the text maps to well-defined data structures, in this case a tree structure. So an item can have child items, which each can have child items, and so on.
> However, “Subitem” doesn’t have direct child items.
I'm not sure if the difference in our approaches is philosophical or practical. Why shouldn't "Another Sub-Sub Item" be considered a direct child? What if the user added the extra spaces unintentionally? What if, just for fun, they wanted to indent their list like:
[x] Example item
[ ] Subitem
[ ] A Sub-Sub Item
[ ] A Sub-Sub Item
[ ] A Sub-Sub Item
Continuation of the first item’s description
If that was my list, and my list's parser couldn't handle that, I wouldn't be very happy. But what would/could/should I expect the behavior to be? I'd hope, given the rule that a child has more leading whitespace than its parent, that all three Sub-Sub Items would be treated as peers.
> You might not be impressed much with my environment—I pretty much just copied the acme colors—but some people have put a lot of work into making their setups look sexy.
> I wish this post touched on some deeper reasons that the author was "disenchanted" with Apple.
It's mainly the feeling of ownership. Apple's apparently increasing hostility toward third-party upgrade-and-repair shops (see the whole "right to repair" issue) forces owners of their machines to use their support exclusively. I'd prefer to have more options for upgrading my hardware than buying a new machine. These decisions make sense for Apple but not for me. Maybe it's because they're still small but Purism hasn't set me up for this sort of antagonistic relationship.
There's also the increased sense of creativity with Linux. It feels a little bit like working with Legos. Because "unix philosophy" and such that other commenters feel are trivial wastes of time, I'm free to make the machine behave as I wish. And I like that.
Of course there are also superficial things. I don't like notifications that force a behavior, like being forced to opening System Preferences because the only button on the notification is "View". But it's also more than that.
> Having dabbled in tiling window managers, terminal music players, and many other /r/unixporn memes
I mean, if you want to demean things you don't like as "memes", that's your prerogative. But I don't use a tiling window manager or terminal music player to impress people. I use them because I like them---they're fast, the mental models make sense, they expose me to new/unfamiliar concepts, and I can customize them to suit me.
> Many of the things mentioned here (e.g., tiling WMs, emacs _REALLY?_) are not mutually exclusive with macOS.
True. I've been using emacs (yeah, really) on macOS for a decade. No complaints there.
> I wonder if the author has realized that rebranded ODM hardware (Librem and System76) and a modern Macbook are unfortunately not in remotely the same league.
The Librem 13 is easily the best-feeling laptop I've ever used.
The Purism forums show there's some variability but my experience has been great. The Librem 13 is the best-feeling laptop I've ever used. It's sturdy (unlike a Macbook Air) but thinner and lighter than my 10-year-old Macbook. It's in a very satisfying middle ground. The keys are great and the trackpad, though not quite as nice as Apple's, is very good.
My one complaint is with the color. Smudges definitely appear pretty quickly. On the other hand, I'm less likely to type with gross fingers now and I wipe down my machine more often (maybe a couple times a month), which isn't necessarily a bad thing.
And I'm curious about nesting being "pretty difficult to implement in tooling"---how do you mean? At least with emacs I found it no more difficult than counting whitespace characters: https://git.sr.ht/~rfm/tdtd-mode/tree/master/item/readme.md