Comment by getnormality
1 day ago
All well and good, but some Org Mode markup symbols are badly chosen if the purpose is human-to-human communication, and that is a profound demerit for a system that purports to structure and facilitate human-to-human communication. Most notably, asterisks are not good section headers. Pound signs are.
So people are not going to switch from Markdown for most purposes. It feels really wrong. And they will generally prefer one system.
YMMV obviously, some people have an easier time managing polyglot systems. But if the goal is to have One System, it won't be Org Mode. It'll be some version of Markdown. Perhaps Org Mode reskinned to look more like Markdown.
What's cool about Org isn't the symbols, but the semantics of a tree with tags, TODOs (along agenda & scheduling), and code blocks.
Org had the problem that a single implementation gained too many features and went underspecified, making the language unusable outside of emacs. Markdown has the reverse problem, lots of implementations with variance that leave you with the lowest common denominator (there's specs, but IMO having many specs is pretty much having no spec, just many implemenattions)
It'd be cool to see a language that standardised Org features, but tried hard to keep things readable/compatible with markdown.
Good outline of capabilities; one of the few in the comments! The tree with tags part is super interesting. I'm using beads more and having short codes for tickets is something I want my mark up to be better at, want to integrate.
I thought maybe neorg would be a counter-example, of something compatible. But it is its own format. Which has a specification repo! https://github.com/nvim-neorg/norg-specs/blob/main/1.0-speci...
> Perhaps Org Mode reskinned to look more like Markdown.
or, reskinned to look visually whatever one wants...
https://sophiebos.io/posts/beautifying-emacs-org-mode/
https://zzamboni.org/post/beautifying-org-mode-in-emacs/
I mention this, because I am not particular about which character symbolises what as long as it is consistent and documented.
However, some people do want things to look just so, and for them, few tools come close to Emacs orgmode.
One can certainly reskin the plaintext rendering to show up however one wants. This has the downside of "two systems" though, e.g. type ** but see it insta-rendered as ###. Although, I rarely type headings like that (character by character). I use the keybindings to "make header", "indent", "de-indent" etc.
Precisely. Emacs folks often talk about how incredibly powerful and flexible their system is, so working with a reskinned Org Mode markup system when dealing with other people's stuff should be completely trivial for them, right? They should consider accommodating less technically sophisticated people for whom different notations are a bigger burden, no?
Your wish is our command... I'd argue that Emacs package maintainers care a lot about usability, in general. This extends to when they craft a package for general use.
https://github.com/tvraman/emacspeak "the complete audio desktop" by our blind and sight-impaired friends, for our blind and sight-impaired friends (and others who must necessarily use speech interfaces)
https://github.com/pprevos/emacs-writing-studio for writers at large
fountain-mode for screenwriting and playwriting https://fountain-mode.org/
https://chrismaiorana.com/emacs-guides/org-mode-syntax/ ("for writers and thinkers")
markdown beautification
https://www.reddit.com/r/emacs/comments/10h9jf0/beautify_mar...
https://oxal.org/blog/powerful-emacs-hacks-image-markdown/
general beautification
https://github.com/pretty-mode/pretty-mode
etc. etc. etc.
If there is a specific kind of person's specific kind of text editing need, there's probably an Emacs package for that.
The real tragedy is how poorly Emacs itself is conveyed to people. Mouse-pointing etc. works just fine out of the box. And as the emacspeak package demonstrates, at its core, it is a very usable and humane piece of technology.
1 reply →
The problem isn't customising your editor to use the symbol you want, but to have a spec that allows freely sharing files back and forth without trouble.
Org has no specification other editors can follow (although people have tried adding support to other editors and also writing such a spec).
1 reply →