My proposal doesn’t seem to me to compromise human readability and editability (and certainly doesn’t compromise version control) so just to make sure we mean the same thing, an example:
space update mydeck.spc
where mydeck.spc = ”
The [quick] brown fox jumped over the [lazy] dog.
;UID=SDFGHJKERTYUICVBN;
Three commonly-used nonsense variable names:
1. foo
2. bar
3. baz
;;
OCaml :: A fast, functional, strongly-typed programming language.
;;"
would find in the deck the first note using the NID, and then add the second and third (having no NIDs, they cannot be found), generate new NIDs, and update mydeck.spc to something like = ”
The [quick] brown fox jumped over the [lazy] dog.
;UID=SDFGHJKERTYUICVBN;
Three commonly-used nonsense variable names:
1. foo
2. bar
3. baz
;UID=LUKAGSDSDFGHJKEE;
OCaml :: A fast, functional, strongly-typed programming language.
;UID=HJKERTYUIVHBFJVBN;"
which you can then checkin. The only edit we would expect users to perform on an NID is to delete it when copy pasting to assign a new NID to the edited version, and that is certainly feasible. Do you still find this objectionable?
Space shouldn’t mutate the file in the general case, because it should be possible to check out a repo of Space files, run Space over all of them, and not have any changes in your tracked files.
Currently, ;; is a separator; it’s optional after the last card. The change you propose is backwards-incompatible with existing Space files. This is only an issue for me, since I’m likely the only human with a lot of space files, but it’s a pain point.
Those IDs are not human-readable. You could do high-entropy human-readable IDs with work, but they would necessitate shipping a dictionary with Space. I don’t mind doing this so this isn’t really a rebuttal.
Generally, the first bullet point is the only really hard problem. There’s no global name scheme we can use that will allow people to put global IDs for cards into a Space file. This is reducible to the problem that Bitcoin solves, so we could solve it with Bitcoin, but that’d be a massive pain. There are hackier solutions, but they’re hacks, and I’m really hesitant to include something that doesn’t get it right the first time because in the very unlikely case Space explodes in between the hack and the fix for the hack, Space will just be crippled forever.
Notice that I can’t reply very frequently because as an open feminist on Less Wrong, I’m targeted by a large amount of actively anti-feminist users who downvote productive comments like the above.
My proposal doesn’t seem to me to compromise human readability and editability (and certainly doesn’t compromise version control) so just to make sure we mean the same thing, an example:
space update mydeck.spc
where mydeck.spc = ”
would find in the deck the first note using the NID, and then add the second and third (having no NIDs, they cannot be found), generate new NIDs, and update mydeck.spc to something like = ”
which you can then checkin. The only edit we would expect users to perform on an NID is to delete it when copy pasting to assign a new NID to the edited version, and that is certainly feasible. Do you still find this objectionable?
I do, for the following reasons:
Space shouldn’t mutate the file in the general case, because it should be possible to check out a repo of Space files, run Space over all of them, and not have any changes in your tracked files.
Currently, ;; is a separator; it’s optional after the last card. The change you propose is backwards-incompatible with existing Space files. This is only an issue for me, since I’m likely the only human with a lot of space files, but it’s a pain point.
Those IDs are not human-readable. You could do high-entropy human-readable IDs with work, but they would necessitate shipping a dictionary with Space. I don’t mind doing this so this isn’t really a rebuttal.
Generally, the first bullet point is the only really hard problem. There’s no global name scheme we can use that will allow people to put global IDs for cards into a Space file. This is reducible to the problem that Bitcoin solves, so we could solve it with Bitcoin, but that’d be a massive pain. There are hackier solutions, but they’re hacks, and I’m really hesitant to include something that doesn’t get it right the first time because in the very unlikely case Space explodes in between the hack and the fix for the hack, Space will just be crippled forever.
Notice that I can’t reply very frequently because as an open feminist on Less Wrong, I’m targeted by a large amount of actively anti-feminist users who downvote productive comments like the above.