Embracing ordered rather than named parameters can make this so much cleaner (that’s why most folks would prefer add(1, 2) to {"function":"add", "augend": 1, "addend": 2}). It’s strange that p2 comes before p1.
["line",{"x":34,"y":44},{"x":141,"y":85}]
The same argument applies to points — way name their components when they will always be the same?
["line",[34,44],[141,85]]
If you’re willing to abandon JSON, you can make it even cleaner. There’s no real need for quotes around the mode:
[line,[34,44],[141,85]]
And it’d be nice to have some whitespace:
[line, [34, 44], [141, 85]]
And come to think of it, those commas don’t really add anything:
[line [34 44] [141 85]]
Hmmm, if you switched from brackets to parentheses I bet you have a library which could handle this for you:
Why use a new format instead of SVG or JS+canvas? The latter would deviate from "plain text" but it's still pretty close. It avoids reinventing the wheel and a webbrower is installed on almost every computer with a display.
I wasn't aware of Markdeep when I built this, but looking at it now, it's 6k+ lines of code: https://casual-effects.com/markdeep/latest/markdeep.js And then you need a browser underneath that weighs in at multiple GB (a scale that transcends lines of code metrics) By comparison, lines.love contains 2.6k LoC, and underneath it is LÖVE containing 100k LoC. This sort of analysis of the total size of the software supply chain and total hackability of the entire stack is what motivates me to look past web browsers. Once they grow past a certain size there is zero value to being open source for 99.99% of people.
(I do love that Markdeep is a single file of js without the ubiquitous pox of 1k-line package-lock.json!)
> I just wrote a thin wrapper around the somewhat verbose JS Canvas API that lets me write code such as
As I said at the start of OP, I want to draw by doodling. So writing code would seem to be disqualified.
> Why use a new format instead of SVG or JS+canvas? It avoids reinventing the wheel and a webbrower is installed on almost every computer with a display.
My goal is to move off browsers. Reinventing the wheel can also often be a good thing.
> Why use a new format instead of SVG or JS+canvas?
Because those are both hellaciously complex, and implementing a usable fraction of the functionality of either is not a job for a single hobbyist programmer. At least, I don’t think they are — I could be wrong. Even if I am, the number of programmers who can write code to draw a line given a JSON description has to be orders of magnitude of orders of magnitude larger than the number who can write an XML parser, an SVG implementation, a Javascript parser and runtime or a canvas implementation.
> {"p2":{"x":141,"y":85},"mode":"line","p1":{"x":34,"y":44}}
Embracing ordered rather than named parameters can make this so much cleaner (that’s why most folks would prefer add(1, 2) to {"function":"add", "augend": 1, "addend": 2}). It’s strange that p2 comes before p1.
The same argument applies to points — way name their components when they will always be the same? If you’re willing to abandon JSON, you can make it even cleaner. There’s no real need for quotes around the mode: And it’d be nice to have some whitespace: And come to think of it, those commas don’t really add anything: Hmmm, if you switched from brackets to parentheses I bet you have a library which could handle this for you:Any sufficiently complicated C or Fortran program…
Why use a new format instead of SVG or JS+canvas? The latter would deviate from "plain text" but it's still pretty close. It avoids reinventing the wheel and a webbrower is installed on almost every computer with a display.
Another format to look at is Markdeep which has support for rendering ASCII diagrams and is very close to plain text: https://casual-effects.com/markdeep/features.md.html
Personally, I just wrote a thin wrapper around the somewhat verbose JS Canvas API that lets me write code such as
when I want to draw diagrams in my Markdeep notes.I wasn't aware of Markdeep when I built this, but looking at it now, it's 6k+ lines of code: https://casual-effects.com/markdeep/latest/markdeep.js And then you need a browser underneath that weighs in at multiple GB (a scale that transcends lines of code metrics) By comparison, lines.love contains 2.6k LoC, and underneath it is LÖVE containing 100k LoC. This sort of analysis of the total size of the software supply chain and total hackability of the entire stack is what motivates me to look past web browsers. Once they grow past a certain size there is zero value to being open source for 99.99% of people.
(I do love that Markdeep is a single file of js without the ubiquitous pox of 1k-line package-lock.json!)
> I just wrote a thin wrapper around the somewhat verbose JS Canvas API that lets me write code such as
As I said at the start of OP, I want to draw by doodling. So writing code would seem to be disqualified.
> Why use a new format instead of SVG or JS+canvas? It avoids reinventing the wheel and a webbrower is installed on almost every computer with a display.
My goal is to move off browsers. Reinventing the wheel can also often be a good thing.
I do have tools to export documents to html/markdown/SVG: https://git.sr.ht/~akkartik/lines2.love#associated-tools But I myself am trying to live outside the browser as much as possible.
> Why use a new format instead of SVG or JS+canvas?
Because those are both hellaciously complex, and implementing a usable fraction of the functionality of either is not a job for a single hobbyist programmer. At least, I don’t think they are — I could be wrong. Even if I am, the number of programmers who can write code to draw a line given a JSON description has to be orders of magnitude of orders of magnitude larger than the number who can write an XML parser, an SVG implementation, a Javascript parser and runtime or a canvas implementation.
What about TinyVG? Seems fit for this purpose.
https://tinyvg.tech/
Oh this is awesome! I might try my hand at implementing it, though maybe not in lines.love..
It looks pretty neat. I like that it has a textual representation!
The solution I use for this problem is a vs code excalidraw plugin that saves the drawing inside the png rendering of it.
So you include the image into your markdown or code comments and can then edit it in a vscode window.
Another one I used for a while is asciiflow.com or the monodraw mac app
https://marketplace.visualstudio.com/items?itemName=pomdtr.e... (I didn’t make it, just a happy user)
Previously: https://news.ycombinator.com/item?id=31637910 (Jun 2022, 192 comments)