Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jotaen
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
151.
▲
by
jotaen
4y ago
[x]it! files are UTF-8 encoded by default. The predefined syntactical elements (such as checkboxes, priorities, or due dates) are composed from ASCII characters, but outside of that (e.g. in item descriptions) you can use all available Unic
152.
▲
by
jotaen
4y ago
Thanks for your detailed notes, I’ll look through your links. Just to clarify for context, the “letter” definition is only relevant for tags, so outside of #tags (in item descriptions, or group titles) you can use any Unicode character you
153.
▲
by
jotaen
4y ago
With [x]it!, lexicographic sorting of lines works as well, as long as you stick to the following rules: - Write due dates first (if you use due dates) - Pad your priority with dots (if you use priorities) - Don’t use line breaks within desc
154.
▲
by
jotaen
4y ago
There currently are a bunch of editor plugins and one CLI tool. You find a collection of tools (all third-party) linked from the project website: https://xit.jotaen.net
155.
▲
by
jotaen
4y ago
Per specification, [x]it! files must be UTF-8 encoded. (See https://github.com/jotaen/xit/blob/main/Specification.md#fil... ) You can use Unicode characters in item descriptions, so you can write these te
156.
▲
by
jotaen
4y ago
> It would be simpler to just use the ISO date format. [x]it! is supposed to be edited (editable) by hand, and from an end-user perspective, I personally find ISO-8601 in its entirety relatively complex to grasp. The currently supported
157.
▲
by
jotaen
4y ago
Thanks for sharing your notes. Nesting of items is not supported, although the idea has come up. It’s on hold right now – that’s mostly due to practical reasons, because it’s relatively hard to implement in tooling. Allow me to clarify a fe
158.
▲
by
jotaen
4y ago
The maintainer wrote something about this here: https://support.hogbaysoftware.com/t/where-is-taskpapers-fil...
159.
▲
by
jotaen
4y ago
I’ve never used TaskPaper, but the capabilities of the data format look somewhat similar. I think the difference is primarily a philosophical one: [x]it! is a file format with a formal specification that’s open source.[1] There is no “canon
160.
▲
by
jotaen
4y ago
For reference, this is the discussion around subitems / nesting: https://github.com/jotaen/xit/discussions/2 As mentioned in that ticket, I’m still reluctant to add this to the [x]it! file specification.
161.
▲
by
jotaen
4y ago
rodo looks quite cool! It’s interesting to see how common the syntax is with these formats, so there seem to be “natural” patterns. [x]it! doesn’t try to be opinionated about what you use it for. So you could use it for your daily todos, bu
162.
▲
by
jotaen
4y ago
Creator here. [x]it! was deliberately designed as a strict data format that stands on its own, as I think this makes it easier to create tooling and work with the data programmatically. However, I think use-cases and preferences are as diff
163.
▲
Keeping track of CLI commands in software projects
(jotaen.net)
1 points
by
jotaen
4y ago
|
1 comments
164.
▲
by
jotaen
4y ago
Maybe worth noting that the 9-euro ticket is only for local public transport, such as buses, subways, or regional trains. Only the latter (RE) are operated by Deutsche Bahn, whereas buses and subways are mostly ran by local companies.
165.
▲
by
jotaen
4y ago
Same here: I regularly take long-distance train rides throughout all Germany, both with ICE (the fast one) as well as RE (the regional one), and for me it works smoothly for the most part.
166.
▲
by
jotaen
5y ago
Nesting is currently being worked on https://github.com/jotaen/xit/discussions/2 , as there are some questions to be figured out first. (Note that the [x]it! specification is a working draft right now, it’s no
167.
▲
by
jotaen
5y ago
Yes. What I did is try to choose default (common) scopes that have a high chance of being coloured the way I want, e.g. for the `[x]` token I use `markup.inserted` which is for markup diffs, so it should be green. Or `markup.underline` for
168.
▲
by
jotaen
5y ago
I’m seriously considering to make that mandatory via the spec. :D
169.
▲
by
jotaen
5y ago
Have you also tried checking all the items?
170.
▲
by
jotaen
5y ago
I didn’t include nesting in the first edition of the draft, because there might be some implications with it and I was curious for feedback on this. https://github.com/jotaen/xit/discussions/2 But it seems li
171.
▲
by
jotaen
5y ago
That’s how it works in Sublime, yes. You have a regex-based parsing engine that you configure via a YAML file, and there you assign scopes to the tokens.[1] As a default, the [x]it! Sublime Package uses the available default scopes. The use
172.
▲
by
jotaen
5y ago
You can have lexicographic ordering with [x]it!, as long as you stick to a specific structure, which is: - Write due dates first - Pad your priority with dots - Don’t use line breaks within descriptions - Don’t use titles Then it will sort
173.
▲
by
jotaen
5y ago
Yeah, I agree – as great as a separate file spec is, it’s only half the story without tools that provide useful functionality on top of it. For my current purposes, it’s syntax highlighting that makes a big difference.
174.
▲
by
jotaen
5y ago
> do you plan support for text unrelated to tasks ? I haven’t thought about that much yet. I’ve tracked it here for it to be discussed: https://github.com/jotaen/xit/discussions/10 > do you plan support
175.
▲
by
jotaen
5y ago
I think the viewpoints on that are wildly diverse. As far as I’m concerned, it’s the exact opposite. Hence, I think it’s great that there is a big variety of different approaches that everyone can pick from according to their own preference
176.
▲
by
jotaen
5y ago
It’s basically one way of allowing to create an information hierarchy, e.g. [ ] Work on #ticket=283 [x] Buy new computer. #done=2022-02-24 Then you could query for `#ticket`, or for specific values of it. (Well, that is, if you
177.
▲
by
jotaen
5y ago
> Question: why must the square brackets be used[2]? There is no technical benefit behind the square bracket notation. As you mentioned, it’s mostly for readability reasons. My take on pleasant plain-text formats is to make use of symbol
178.
▲
by
jotaen
5y ago
A few (cosmetic) details, for example: - They don’t support multiline item descriptions. They actually prohibit that for a specific reason, because you can’t sort the lines lexicographically anymore. In my opinion, that should be an optiona
179.
▲
by
jotaen
5y ago
> I feel like a spec like this was meant for a pretty niche group of people. That’s spot on actually.
180.
▲
by
jotaen
5y ago
I appreciate the criticism, thanks! I disagree, though, that adhering to standardised formats is not worth it. Currently, there are countless todo apps and editor plugins out there, which all do very similar things. However, each needs thei
More ›