21–30 of 85 posts
Genuinly curious: > Why reinventing the wheel when we can just copy it! This project takes the only surefire way to get it right - use the original elisp parser implementation as a blueprint! Emacs Lisp code is under GPLv3 license, is it OK to rewrite it in another language (using original code as blueprint) and publish it under MIT?
Genuinly curious: > Why reinventing the wheel when we can just copy it! This project takes the only surefire way to get it right - use the original elisp parser implementation as a blueprint! Emacs Lisp code is under GPLv3 license, is it OK to rewrite it in another language (using original code as blueprint) and publish it under MIT?
Of course. That is a derivative work.
Genuinly curious: > Why reinventing the wheel when we can just copy it! This project takes the only surefire way to get it right - use the original elisp parser implementation as a blueprint! Emacs Lisp code is under GPLv3 license, is it OK to rewrite it in another language (using original code as blueprint) and publish it under MIT?
Of course. That is a derivative work.
How derivative is defined? Manual compilation is ok, but automatic is not? But what if I beleive that humans are just fancy machines? ;)
Earlier quoted context omitted.
Of course. That is a derivative work.
And if I compile some GNU code (for example written in C) to javascript with a compiler, then change some details here and there can I change the licence to MIT? How derivative is defined? Manual compilation is ok, but automatic is not? But what if I beleive that humans are just fancy machines? ;)
> How derivative is defined?
For the US, it's primarily defined in plain English in the USC. But subtle distinctions are made by court rulings/opinions.
> Org is probably the best and most complete plain text organizational system known to mankind. It has countless applications like authoring, publishing, task and time tracking, journal, blog, agenda, wiki etc...
Yes, absolutely.
> Unfortunately Org was originally developed for Emacs and therefore available only inside Emacs. It is a huge limiting factor for Org's development and popularization. Because of that it is not as popular outside of Emacs community as it should be.
"Unfortunately"? It is a dynamic tool, I don't understand what it would mean for it available outside of emacs except for if that were also a dynamic tool. Are you going to create a standalone dynamic org mode application? It seems better to make a "stripped down" emacs that only has org mode and literate programming features so as to not have as steep a learning curve as the entirety of emacs all at once. What other reason is there for this work except for avoiding the learning curve of emacs? Emacs has got to be one of the most configurable pieces of software outside of Operating Systems(maybe?) in existence.
Org mode is powerful because it is a plaintext system that gives hooks for emacs abilities like transformation (faces, folding, tagging/searching, agenda features) and execution of code with literate programming, and passing values around between code blocks and so on.
Why would this want to live outside of emacs? I do think the recently (and again two years ago) extremely popular post on org mode's markup language absolutely misses this point[1]. This post is also linked to from the repo.
I'd love to learn about what I'm missing here, and would love to get some answers to my questions or responses to my assumptions! I'm very interested in your roadmap and design decisions, I think your external links (except for that article) are fantastic. I will follow the project for sure.
I just think there is some mental disconnect with how org mode is represented and discussed on hn, and those discussions almost all seem to miss the majority of org mode abilities that absolutely depend on living in the style of environment that emacs provides. From reading the top discussions here, one might think org mode is in competition for the same space as markdown while that is not even remotely true [2].
[1]: https://news.ycombinator.com/item?id=19622019
[2]: https://hn.algolia.com/?query=org%20mode&sort=byPopularity&p...
PS: I am trying to do a more thorough review of the discussion about org mode on hn, and I will be taking actual notes and comment links down to better explain my ideas here rather that just general takeaways. Thanks for bearing with me, or letting me know if you disagree.
What sense does it make to have org mode outside of emacs? I think the entire power of the system would be that it explicitly lives within emacs. From the repo: > Org is probably the best and most complete plain text organizational system known to mankind. It has countless applications like authoring, publishing, task and time tracking, journal, blog, agenda, wiki etc... Yes, absolutely. > Unfortunately Org was origi…
Genuinly curious: > Why reinventing the wheel when we can just copy it! This project takes the only surefire way to get it right - use the original elisp parser implementation as a blueprint! Emacs Lisp code is under GPLv3 license, is it OK to rewrite it in another language (using original code as blueprint) and publish it under MIT?
It is not according to their FAQ.
Genuinly curious: > Why reinventing the wheel when we can just copy it! This project takes the only surefire way to get it right - use the original elisp parser implementation as a blueprint! Emacs Lisp code is under GPLv3 license, is it OK to rewrite it in another language (using original code as blueprint) and publish it under MIT?
https://www.gnu.org/licenses/gpl-faq.en.html#TranslateCode It is not according to their FAQ.
> If the original program is licensed under certain versions of the GNU GPL, the translated program must be covered by the same versions of the GNU GPL.
Earlier quoted context omitted.
The big difference between Markdown and the Org-markup is that the latter has syntax for various kinds of metadata, while Markdown is purely content. That metadata is used for things like task management, literate programming, spreadsheets, customizing export behavior, etc. One could, in theory, create an extended Markdown flavor that allows similar metadata, but that wouldn't be compatible with any existing tools an…
Pretty sure Markdown with metadata (sometimes referred to as "front matter") already exists and is called MultiMarkdown, no?
For example, in Org you can add task management data, scheduling information and arbitrary properties to the outline,
#+COLUMNS: %ITEM %TODO %ASSIGNED_TO %SCHEDULED %PRIORITY
#+PROPERTY: ASSIGNED_TO_ALL juki some other people
* TODO [#A] Some task with priority A
SCHEDULED:
:PROPERTIES:
:ASSIGNED_TO: juki
:END:
Some description.
For another example, you can add formulas to a table,
#+CAPTION: A table with formulas.
| foo | bar | Row sum |
|-----+-----+---------|
| 10 | 20 | 30 |
| 30 | 40 | 70 |
|-----+-----+---------|
| 40 | 60 | 100 |
#+TBLFM: $3=vsum($1..$2)::@4=vsum(@I..@II)
Genuinly curious: > Why reinventing the wheel when we can just copy it! This project takes the only surefire way to get it right - use the original elisp parser implementation as a blueprint! Emacs Lisp code is under GPLv3 license, is it OK to rewrite it in another language (using original code as blueprint) and publish it under MIT?