Re: Orgdown: negative feedback & attempt of a root-cause analysis
Karl, thanks for all of this, and for writing and posting your blog entry (words of caution for many). my thoughts on your project are something like this: - i think non-emacs tools to deal with org mode files is a Good Thing. - for me, the main motivation is to allow *me* to share an org mode file with someone -- say via a git repo -- and have them be able to do something reasonable, if restricted, with it -- extract the code, query subtrees or tables, etc. -- without recourse to emacs. - i think collaborative editing with non-emacs users should be not be a goal of *this* endeavor. - for me, your main invention, and the place (non pro-versus-con) discussion should focus, is on your levels: what's at level 1, at what level is org-mode itself, etc. there are some tricky things here (e.g., for tables, what to do with hlines, with column width specifications, at the various "conformance levels"?) - and, sigh, i prefer some other name; like "org mode syntax (level 0)". maybe it will acronymize into omsl0 (gasp!). who knows. i do think "orgdown" was a clever choice, but i'm not a fan. cheers, Greg
Re: Orgdown: negative feedback & attempt of a root-cause analysis
On Wednesday, 1 Dec 2021 at 22:17, M. ‘quintus’ Gülker wrote: > There is Git, of course, but unless you are a programmer, using Git is > pretty much arcane. I was not yet successful to explain Git to MS Word > users, who are actually happy with the change tracking tooling Word > has built in. Though that might be more of a topic for the > emacs-humanities mailing list rather than this list. It's more widespread than that; in engineering, almost all (but not all!) of my colleagues do the same and it's difficult to get them to listen about the advantages of proper version control. > Am Dienstag, dem 30. November 2021 schrieb Karl Voit: >> People do not seem to realize what it took to get there - which is >> partly understandingly because I had to learn by doing what it takes >> to get the idea into a coherent and consistent form. Karl, I tweeted soon after your presentation at EmacsConf 2021 that although my use of org relies on much more than just the simple markup (I use babel and citations extensively), the idea of a standard for the markup was welcome. Do not give up. Okay, the name might be contentious... ;-) -- : Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Orgdown: negative feedback & attempt of a root-cause analysis
Karl Voit writes: > Hi, > > I've summarized my current state of mind about the whole Orgdown > fiasco into a blog article: > https://karl-voit.at/2021/12/02/Orgdown-feedback/ > > Don't worry, I tried to analyze my own faults as well so that others > might be able to learn from this unfortunate situation. Hi Karl, thanks for writing up your experiences. I'm not surprised about the reaction you got from reddit. I gave up on reddit some time back due to the toxic nature of too many threads. I don't know why it is so often toxic, but it really isn't worth the hassle. Starting up a project is difficult. I have an open source JS library which has turned out to be far more popular than I expected (averages over 150k downloads each week). I'm not sure I was ready for the commitment maintaining such a project involves - especially the long term nature of it. At times, I ahve had problems with rather 'entitled' users who demand ridiculous things from a free bit of software and who can become extremely rude and somewhat nasty when I don't do what they want. I've learnt to just ignore them. The best advice I can give is to suggest you just put the whole thing on the back burner for a month or so and then come back to it. During that time, other comments are bound to come through and I find the later comments are often far more considered and less emotional than initial responses. Stepping back gives the subconscious part of your brain time to process everything and will likely provide additional clarity once it has had time to percolate.
Re: Orgdown: negative feedback & attempt of a root-cause analysis
Thank you for writing all this down Karl. Thank you for your efforts and I truly am sorry for everything you've been put through emotionally. I know very well how a few particularly nasty comments can sap your energy as the brain cycles on them over and over. I hope you come out of this the stronger and so does the project On Wed, Dec 1, 2021, 17:44 Karl Voit wrote: > Hi, > > I've summarized my current state of mind about the whole Orgdown > fiasco into a blog article: > https://karl-voit.at/2021/12/02/Orgdown-feedback/ > > Don't worry, I tried to analyze my own faults as well so that others > might be able to learn from this unfortunate situation. > > -- > get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: >> get Memacs from https://github.com/novoid/Memacs < > Personal Information Management > http://Karl-Voit.at/tags/pim/ > Emacs-related > http://Karl-Voit.at/tags/emacs/ > > >
Re: Orgdown: negative feedback & attempt of a root-cause analysis
Hi, I've summarized my current state of mind about the whole Orgdown fiasco into a blog article: https://karl-voit.at/2021/12/02/Orgdown-feedback/ Don't worry, I tried to analyze my own faults as well so that others might be able to learn from this unfortunate situation. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)
Am Dienstag, dem 30. November 2021 schrieb Karl Voit: > One of the next things I do have on my list is to try out crdt as > I've learned at EmacsConf21 that it is mature enough to be used in > practice. > > If that holds true, we can start dreaming of having a Etherpad-like > session from our GNU/Emacs while peers are connected to the same > session via some web-based tool/service. I never heard of crdt, but distributed editing sounds useful. There is Git, of course, but unless you are a programmer, using Git is pretty much arcane. I was not yet successful to explain Git to MS Word users, who are actually happy with the change tracking tooling Word has built in. Though that might be more of a topic for the emacs-humanities mailing list rather than this list. > The dominant feedback of > https://www.reddit.com/r/emacs/comments/r4cq3o/orgdown_the_new_name_for_the_syntax_of_orgmode/ > was negative comments on the name and nothing else. Even here, > although due to a much more civilized style, the name choice was the > dominant topic and not the idea. I have to take this as a strong > signal here and I'm very close in giving up on Orgdown as a project. The civility of this list is one of the reasons why I like to read it. I find it incredible how people behave on these so-called social media. That alone indicates that something is wrong with them. You should not give up on the project. As I have learned from reading this thread, there appear to be people who already work on formalising org’s grammar. You ought to talk to them and see if it is possible to unite efforts. Tom Gillespie in a message further down this thread has mentioned that formalising org is a huge effort. I agree with that, but your novel concept of “compatibility levels” is something I could see as an intermediate step. It could help to accelerate the formalising efforts and non-Emacs tools could start targetting them quickly. But I might be wrong on seeing this as an advantage; I have never written formal specifications. It is certainly your success to have generated this discussion thread; I was not aware of any similar formalisation efforts. I hope that if nothing else, it contributes to this efforts. > People do not seem to realize what it took to get there - which is > partly understandingly because I had to learn by doing what it takes > to get the idea into a coherent and consistent form. I do not think anybody wanted to feel you bad. Most are trying to provide constructive criticism to you in order to improve your suggestions. There are very few people who are fundamentally opposed to your effort, because they firmly believe there can be no org outside of Emacs. My suggestion is to ignore them and continue on your path, because your idea has no impact on them and they can by definition not help you to improve it. Naming is one of the hard things in Computer Science. Just leave the naming issue aside and work with the people here to formalise the compatibility levels. > Bastien told me that he would be interested to see hard numbers on > my assumption that Org-mode syntax is easier to learn and type in > comparison to other LWM. And he is right: some research work in > order to get numbers would be awesome to shed some light on the > forest of assumptions. Maybe somebody in a position to realize such > a case study gets motivated now? ;-) Entirely subjectively, typing: #+begin_src python #+end_src manually without help of the editor feels more difficult than typing: python Any non-Emacs org(down) editor should ensure to ease typing that. For the purposes of refining your proposal conducting the “case study” simply by inquiry on this mailing list might suffice. Many people around here know Markdown and I guess there is no value in applying rigorous scientific standards here. > Does "assuming too much on other people's world because on my own > small world" have a scientific name? I might be in danger of having > this disease? *g* I have fallen to this earlier. My computer is full of things to solve problems many people simply do not even have. I need citation software that interacts with my Biblatex files, for instance. Since my e.g. my work collegues do not even use Biblatex, they do not have such a need. Typing citations out by hand is rather popular in my area; if it is not done manually, people appear to use Citavi. I certainly know not a single person in my area who uses Biblatex. Another example is that I have a rather longish ~/.xinitrc file for automatic starting of several applications, like the PulseAudio sound server. Somehow, this is a problem others appearently do not have; it exists because I inflict to myself the pain of using Linux with i3 and Emacs, which I perceive as productive rather than painful, not to mention the privacy advantages. There was a time when I tried to convince people from my setup as the correct one for everyone, but today I know it is not. As an aside,
Re: Orgdown: negative feedback & attempt of a root-cause analysis
Tom Gillespie writes: > Karl, >The exact naming of a thing is nearly always the most contentious > step in trying to promulgate it. In my own field we can easily get all > parties to agree on a definition, but they refuse to budge on a name. > As others have said, I wouldn't worry about kibitizing over the name. > > I would however worry about the larger negative reaction. From my > perspective I think the issue is that there are many efforts working > toward a formalized specification for Org syntax and Org mode > functionality, and some of those stakeholders who have invested > significant effort may feel blindsided by a public declaration > announcing Orgdown because they were not consulted and not > made aware that you were working on it. > > I appreciate the amount of work that you have put in, I have devoted > hundreds of hours to working on an alternate implementation of org > in Racket that uses a formal ebfn in hopes that others will be able > to use it as a guide and as a way to talk formally about how Org > parsers and implementations should behave. > > It would thus be easy for me to say that your approach has put the > cart before the horse, because there are countless nuances in the > specification for Org syntax which must be addressed before any > levels of org compliance can be specified, otherwise the behavior > between levels will be inconsistent. > > If I were to say this, it would not be fair to you at all. The ideas > and motivation for Orgdown are vital and important. You have put > in enormous thought and effort, all because you care about Org > and want to see it succeed. > > The issue is that any shared specification for Org syntax is > fundamentally about how to coordinate as a community. > The way that Orgdown was presented to the community feels > (to me) like it is being imposed top down or coming from an > individual source, not from an open and visible community > process (the subject of your original email reads as a declaration > in english, and thus can be quite off putting, though I know that > was not the intention). > > I personally haven't bothered with promulgation because I think > that we are not technically ready as a community to approach > outreach to other developers in a way that we can succeed. > > The good news is that all of this can co-exist if we want it to, > but we need to be clear about our objectives as a community. > > To me these objectives are as follows (and I would love > to hear from others about additional or alternate objectives). > > 1. To never fracture Org syntax so as to avoid the nightmare > of markdown flavors. (This means being able to say clearly > as a community that a parser is out of compliance and that > it is up to the user to fix their files. The ruby org parser used > by Github is a major issue here.) > 2. To provide a clear specification for what graceful degradation > looks like when parsing Org syntax if a parser does not support > some portion of that syntax (e.g. should property drawer lines > be excluded or rendered as plain text?). > 3. Provide a solid basis on which further formal specification > can be built. (My interests in particular are around providing > consistent semantics for org-babel blocks across languages > so that babel implementations can clearly communicate what > runtime features they support.) > > The approach for Orgdown can absolutely meet all three of > these objectives, however in its current form Orgdown1 is not > sufficiently well specified to avoid fracturing the syntax. > This is because Org syntax is extremely complex (even the > elisp implementation of Org mode is internally inconsistent) > and there are edge cases where behavior will diverge if parsing > of even the simplest elements is not fully specified. > > There are many ways to remedy this, however they require > a more formal approach. A number of us are working to build > technical foundations for such a formal approach, but I do not > think that any of those projects are ready to be used to > specify discrete levels of Org syntax parsing compliance. > > If I may, I would suggest that an Orgdown0 is something that > could be well specified, but it would avoid parsing of markup > altogether and only deal with the major element types. Parsing > paragraphs and all the org objects is not something that can > be done piecemeal. There are too many interactions between > different parts of the syntax, and in some cases the existing > specification desperately needs to be revisited due to the > complexity that it induces or because it is underspecified. > Of course this would make Orgdown0 fairly useless as a > replacement for markdown, but at least it would be a start. Everything you comment here seems very sensible to me. Anyway I have to say that, in my case, the name 'orgdown' is not the issue, but the underlying idea under the naming, whatever the name is. IMHO, reduce Org to a markup language or, to put it somewhat metaphorically
Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)
Tom Gillespie writes: > Karl, >The exact naming of a thing is nearly always the most contentious > step in trying to promulgate it. In my own field we can easily get all > parties to agree on a definition, but they refuse to budge on a name. > As others have said, I wouldn't worry about kibitizing over the name. > > I would however worry about the larger negative reaction. From my > perspective I think the issue is that there are many efforts working > toward a formalized specification for Org syntax and Org mode > functionality, and some of those stakeholders who have invested > significant effort may feel blindsided by a public declaration > announcing Orgdown because they were not consulted and not > made aware that you were working on it. > > I appreciate the amount of work that you have put in, I have devoted > hundreds of hours to working on an alternate implementation of org > in Racket that uses a formal ebfn in hopes that others will be able > to use it as a guide and as a way to talk formally about how Org > parsers and implementations should behave. > > It would thus be easy for me to say that your approach has put the > cart before the horse, because there are countless nuances in the > specification for Org syntax which must be addressed before any > levels of org compliance can be specified, otherwise the behavior > between levels will be inconsistent. > > If I were to say this, it would not be fair to you at all. The ideas > and motivation for Orgdown are vital and important. You have put > in enormous thought and effort, all because you care about Org > and want to see it succeed. > > The issue is that any shared specification for Org syntax is > fundamentally about how to coordinate as a community. > The way that Orgdown was presented to the community feels > (to me) like it is being imposed top down or coming from an > individual source, not from an open and visible community > process (the subject of your original email reads as a declaration > in english, and thus can be quite off putting, though I know that > was not the intention). > > I personally haven't bothered with promulgation because I think > that we are not technically ready as a community to approach > outreach to other developers in a way that we can succeed. > > The good news is that all of this can co-exist if we want it to, > but we need to be clear about our objectives as a community. > > To me these objectives are as follows (and I would love > to hear from others about additional or alternate objectives). > > 1. To never fracture Org syntax so as to avoid the nightmare > of markdown flavors. (This means being able to say clearly > as a community that a parser is out of compliance and that > it is up to the user to fix their files. The ruby org parser used > by Github is a major issue here.) > 2. To provide a clear specification for what graceful degradation > looks like when parsing Org syntax if a parser does not support > some portion of that syntax (e.g. should property drawer lines > be excluded or rendered as plain text?). > 3. Provide a solid basis on which further formal specification > can be built. (My interests in particular are around providing > consistent semantics for org-babel blocks across languages > so that babel implementations can clearly communicate what > runtime features they support.) > > The approach for Orgdown can absolutely meet all three of > these objectives, however in its current form Orgdown1 is not > sufficiently well specified to avoid fracturing the syntax. > This is because Org syntax is extremely complex (even the > elisp implementation of Org mode is internally inconsistent) > and there are edge cases where behavior will diverge if parsing > of even the simplest elements is not fully specified. > > There are many ways to remedy this, however they require > a more formal approach. A number of us are working to build > technical foundations for such a formal approach, but I do not > think that any of those projects are ready to be used to > specify discrete levels of Org syntax parsing compliance. > > If I may, I would suggest that an Orgdown0 is something that > could be well specified, but it would avoid parsing of markup > altogether and only deal with the major element types. Parsing > paragraphs and all the org objects is not something that can > be done piecemeal. There are too many interactions between > different parts of the syntax, and in some cases the existing > specification desperately needs to be revisited due to the > complexity that it induces or because it is underspecified. > Of course this would make Orgdown0 fairly useless as a > replacement for markdown, but at least it would be a start. > Hi Tom, I pretty much agree with everything you wrote. I also feel it is unfortunate that Karl received so much negative focus on the name and not on the underlying idea - but I'm not surprised. As you say, naming is extremely hard and getting consensus is even har
Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)
Karl, The exact naming of a thing is nearly always the most contentious step in trying to promulgate it. In my own field we can easily get all parties to agree on a definition, but they refuse to budge on a name. As others have said, I wouldn't worry about kibitizing over the name. I would however worry about the larger negative reaction. From my perspective I think the issue is that there are many efforts working toward a formalized specification for Org syntax and Org mode functionality, and some of those stakeholders who have invested significant effort may feel blindsided by a public declaration announcing Orgdown because they were not consulted and not made aware that you were working on it. I appreciate the amount of work that you have put in, I have devoted hundreds of hours to working on an alternate implementation of org in Racket that uses a formal ebfn in hopes that others will be able to use it as a guide and as a way to talk formally about how Org parsers and implementations should behave. It would thus be easy for me to say that your approach has put the cart before the horse, because there are countless nuances in the specification for Org syntax which must be addressed before any levels of org compliance can be specified, otherwise the behavior between levels will be inconsistent. If I were to say this, it would not be fair to you at all. The ideas and motivation for Orgdown are vital and important. You have put in enormous thought and effort, all because you care about Org and want to see it succeed. The issue is that any shared specification for Org syntax is fundamentally about how to coordinate as a community. The way that Orgdown was presented to the community feels (to me) like it is being imposed top down or coming from an individual source, not from an open and visible community process (the subject of your original email reads as a declaration in english, and thus can be quite off putting, though I know that was not the intention). I personally haven't bothered with promulgation because I think that we are not technically ready as a community to approach outreach to other developers in a way that we can succeed. The good news is that all of this can co-exist if we want it to, but we need to be clear about our objectives as a community. To me these objectives are as follows (and I would love to hear from others about additional or alternate objectives). 1. To never fracture Org syntax so as to avoid the nightmare of markdown flavors. (This means being able to say clearly as a community that a parser is out of compliance and that it is up to the user to fix their files. The ruby org parser used by Github is a major issue here.) 2. To provide a clear specification for what graceful degradation looks like when parsing Org syntax if a parser does not support some portion of that syntax (e.g. should property drawer lines be excluded or rendered as plain text?). 3. Provide a solid basis on which further formal specification can be built. (My interests in particular are around providing consistent semantics for org-babel blocks across languages so that babel implementations can clearly communicate what runtime features they support.) The approach for Orgdown can absolutely meet all three of these objectives, however in its current form Orgdown1 is not sufficiently well specified to avoid fracturing the syntax. This is because Org syntax is extremely complex (even the elisp implementation of Org mode is internally inconsistent) and there are edge cases where behavior will diverge if parsing of even the simplest elements is not fully specified. There are many ways to remedy this, however they require a more formal approach. A number of us are working to build technical foundations for such a formal approach, but I do not think that any of those projects are ready to be used to specify discrete levels of Org syntax parsing compliance. If I may, I would suggest that an Orgdown0 is something that could be well specified, but it would avoid parsing of markup altogether and only deal with the major element types. Parsing paragraphs and all the org objects is not something that can be done piecemeal. There are too many interactions between different parts of the syntax, and in some cases the existing specification desperately needs to be revisited due to the complexity that it induces or because it is underspecified. Of course this would make Orgdown0 fairly useless as a replacement for markdown, but at least it would be a start. Best, Tom
Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)
On Tue, 30 Nov 2021 at 17:46, Karl Voit wrote: > > I chose an in-between approach: defining only a minimal set (name, > common structure/idea/documentation, Orgdown1, providing a > collaborative home on GitLab) and hope for a project community that > will take over (or at least support) from there, discussing syntax > elements for Orgdown2 and taking the project to its next logical > steps. > > In hindsight, this decision was wrong. > > Quite frankly, I don't have the energy to throw away everything and > start from zero with a different name. > > People do not seem to realize what it took to get there - which is > partly understandingly because I had to learn by doing what it takes > to get the idea into a coherent and consistent form. > > Simply switching to a different name is not just search&replace. It > would reset the project almost to its very start again, losing the > go-live effect of previous weekend (whose effect might be > questionable considering the name discussion), its project URL that > is now out there, the motivation video which aims to explain the > motivation to users of Emacs, the EmacsConf21 talk publicity, and it > would require much effort to reach the status where Orgdown is now. Hi Karl, I was at the EmacsConf2021, but I was totally exhausted due to other chores and spoke to very few people there... I think that your work is VERY important. I am one of the people who have tried to learn Org lots of times and got stuck the same number of times, and any initiative that splits the features - either syntactic or semantics - into layers of different complexity and importance will help me very much. My suggestion about the name is: it's your project, changing its name is not a trivial task, and the people who complained about the name did not offer help. If I were you would simply put "find a better name for the project and change its name to it" in my TODO list as a low-priority task. Cheers =), Eduardo Ochs http://angg.twu.net/#eev https://emacsconf.org/2021/talks/test/
Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)
Karl Voit writes: > * M ‘quintus’ Gülker wrote: >> Am Montag, dem 29. November 2021 schrieb Karl Voit: >>> It seems to be the case that the name "Orgdown" is the reason why >>> the Org-mode community does not support the idea of an >>> implementation-agnostic definition of the syntax. Which is ... kinda >>> funny if you think about it. This does not represent my answer correctly. I explicitly said that org is implementation-defined, so *full* compatibility cannot easily be achieved outside Emacs. That does not prevent partial compatibility. >>> Well if the project is not working out, at least I made my point and >>> we continue to have all those misunderstandings and lack of Orgdown >>> support in 3rd party tools (because Org-mode is way too big). >> >> I think the project has value; better tooling outside of Emacs is >> something org can only profit from in my opinion. One point that has not >> been raised yet are scenarios of collaborative work; I would enjoy it >> quite a bit if I could work on documents together with people who do not >> like Emacs as an editor for whatever reason. Currently, org as a file >> format is pretty much excluded if collaboration is intended with someone >> who does not use Emacs. The natural choice in these cases is Markdown. > > I agree. > > One of the next things I do have on my list is to try out crdt as > I've learned at EmacsConf21 that it is mature enough to be used in > practice. > > If that holds true, we can start dreaming of having a Etherpad-like > session from our GNU/Emacs while peers are connected to the same > session via some web-based tool/service. That would be pretty nice. You might also want to look at orgzly[1], org-js[2], or markup-rocks[3]. [1]: http://www.orgzly.com/help [2]: https://github.com/mooz/org-js [3]: https://markup.rocks/ All of these call org-mode syntax simply "org". > There were two possible generic approaches for me: start from zero > with an open process, involving peers in all choices such as naming, > Orgdown1 syntax elements, ... You can also just take up the already given arguments, form a decision, and then move forward. > Simply switching to a different name is not just search&replace. It > would reset the project almost to its very start again, losing the > go-live effect of previous weekend (whose effect might be > questionable considering the name discussion), its project URL that > is now out there, the motivation video which aims to explain the > motivation to users of Emacs, the EmacsConf21 talk publicity, and it > would require much effort to reach the status where Orgdown is now. Why is that? From the technical side a simple entry in NEWS „Orgdown now uses the name Org Syntax as alias“ and a second domain should suffice. It’s the emotional side that no one but you could solve. > My guess is that most people do not suffer much from different > Markdown flavors because they rarely mix them in their workflows. I > guess most people are using Markdown only in their text editor OR > only in GitHub/GitLab org files OR only within any other > Markdown-tool. Or they just don’t use 90% of markdown features. Titles, quoted, bold, emphasis, links, inline-source, source-blocks. Which is a big difference compared to Org mode. Even with that, source-blocks tend to break between implementations. >> Maybe most documents are very simple files. README files for FLOSS >> projects, forum posts, blog posts. For such content the features where >> the Markdown implementations differ are usually not required. > > This sounds also a plausible explanation and is also boosted by > another posting as an answer to yours. And markdown has inline HTML: Anything missing (like tables) is just exported from org-mode as HTML. > I don't think that users of LaTeX/ConTeXt are part of the target > group. They would actually lose a bit of having control, I think. > And Overleaf might be too hard to beat I guess although I personally > don't like to use cloud-based services but meanwhile that's the > opinion of a tiny minority. Switching from LaTeX to Org-Mode was a very empowering step for me, because it simpified most documents a lot, enabled quick restructuring, allowed for easy tracking of TODO-states and using executed inline-code via babel — and I gained HTML export for free. It’s not the tool for a single paper to one journal that only has to fit one format and is never edited after final submission, but for any larger writing, org-mode is quite a boost in productivity. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)
Hi, * M ‘quintus’ Gülker wrote: > > Am Montag, dem 29. November 2021 schrieb Karl Voit: >> It seems to be the case that the name "Orgdown" is the reason why >> the Org-mode community does not support the idea of an >> implementation-agnostic definition of the syntax. Which is ... kinda >> funny if you think about it. >> >> Well if the project is not working out, at least I made my point and >> we continue to have all those misunderstandings and lack of Orgdown >> support in 3rd party tools (because Org-mode is way too big). > > I think the project has value; better tooling outside of Emacs is > something org can only profit from in my opinion. One point that has not > been raised yet are scenarios of collaborative work; I would enjoy it > quite a bit if I could work on documents together with people who do not > like Emacs as an editor for whatever reason. Currently, org as a file > format is pretty much excluded if collaboration is intended with someone > who does not use Emacs. The natural choice in these cases is Markdown. I agree. One of the next things I do have on my list is to try out crdt as I've learned at EmacsConf21 that it is mature enough to be used in practice. If that holds true, we can start dreaming of having a Etherpad-like session from our GNU/Emacs while peers are connected to the same session via some web-based tool/service. > I agree that the name is kind of odd as it seems as if it is necessary > to invoke some association to Markdown. Other markup languages also do > not need that -- Textile, Asciidoc, etc. Perhaps it is best to simply > ignore the naming issue and focus on the actual work instead. It is far > more important to get the compatibility levels defined. After that you > can still reconsider the naming. The dominant feedback of https://www.reddit.com/r/emacs/comments/r4cq3o/orgdown_the_new_name_for_the_syntax_of_orgmode/ was negative comments on the name and nothing else. Even here, although due to a much more civilized style, the name choice was the dominant topic and not the idea. I have to take this as a strong signal here and I'm very close in giving up on Orgdown as a project. I did underestimate the power of the name choice as I clearly was impatient because I was looking forward to interesting discussions on the idea itself like in this sub-thread. There were two possible generic approaches for me: start from zero with an open process, involving peers in all choices such as naming, Orgdown1 syntax elements, ... While this approach offers maximum community involvement, my fear was to get into too many long discussions about details before I could express my vision to anybody in a concise way. Second approach: define everything myself up to Orgdown7 (as an example) and publish with a big bang. The downsides here are obvious. I chose an in-between approach: defining only a minimal set (name, common structure/idea/documentation, Orgdown1, providing a collaborative home on GitLab) and hope for a project community that will take over (or at least support) from there, discussing syntax elements for Orgdown2 and taking the project to its next logical steps. In hindsight, this decision was wrong. Quite frankly, I don't have the energy to throw away everything and start from zero with a different name. People do not seem to realize what it took to get there - which is partly understandingly because I had to learn by doing what it takes to get the idea into a coherent and consistent form. Simply switching to a different name is not just search&replace. It would reset the project almost to its very start again, losing the go-live effect of previous weekend (whose effect might be questionable considering the name discussion), its project URL that is now out there, the motivation video which aims to explain the motivation to users of Emacs, the EmacsConf21 talk publicity, and it would require much effort to reach the status where Orgdown is now. >> Oh, there is a very large danger here of getting something that is >> not compatible with Org-mode any more. I don't think that this would >> be a good thing. At least the different flavors killed the fun of >> Markdown for me. > > The astonishing thing is that most people manage to get along despite of > the incompatibilities of the different Markdown flavours. Otherwise > Markdown would not be such a success. Why is this? What can be learned > from this for creating org tools outside of Emacs? Actually surveying > this might be of interest. I agree and I have thought about it myself already. My guess is that most people do not suffer much from different Markdown flavors because they rarely mix them in their workflows. I guess most people are using Markdown only in their text editor OR only in GitHub/GitLab org files OR only within any other Markdown-tool. I might be in an unusual situation where I do have to work with GitHub/GitLab flavored Markdown README files AND with DIY company solutions that work with pp
