I'm coming at this from the viewpoint of accessibility. I am a blind person, who is pretty technical, but not technical enough to bend Emacs to my will as easily as some of you do. But I have begun bending Org-mode to fit what I use it for, and love heading folding and having all things pertaining to work, for example, in one document, and being able to easily find things from there and navigate using folding. I've since moved from Mac, where I used Emacs and Emacspeak, to Windows, where most blind people use VS Code. And I love how streamlined VS Code is. No linter is inaccessible because of using parts of the interface that the TTS extension author hasn't made accessible yet, because the whole UI works with the screen reader. Sure, it's not perfect yet, but Language Tool, Grammarly, all Markdown extensions, all work great with my screen reader in VS Code, and I love using those tools. But no Markdown extension comes close to the power and flexibility of Org-mode in Emacs.
Yes, this could be me just wishing Emacs worked better with accessibility tools in Windows and we didn't have to rely on Emacspeak and such in other operating systems, because ultimately Emacspeak pretty much relies on the author or other contributors working around Emacs, to make Emacs' modes work well in an auditory environment. And that works great, until you roam outside of the use cases set forth by the developers. And not all Emacs/Emacspeak users are developers, so cannot then make these use cases, like Hugo-mode and Jekyll-mode, before I asked the maintainer of those modes if there was anything they could do to make their modes work better with Emacspeak, work better. And I'm not saying that we should dumb down Emacs for people like me, but I do think that VS Code and other editors that try to help out the writer or developer and such, have their place, and so Org-mode should have a more prominent place within these editors. Besides, I think bringing Org-mode to VS Code would help bring Org-mode to the web, which would be pretty cool, since VS Code is pretty much built on web technologies. And there is an Emacspeak package for Windows, but it is no longer maintained, and I think most Emacspeak users use Linux or Mac anyways. And one can sort of use Emacs in a Terminal with a screen reader, but you can't use C-N, C-P, or other Emacs-specific keys, defeating one purpose of even having Emacs in the first place. I might just get a virtual machine up and going and just use that, just for Emacs and Org-mode. :) And yes, there are things that Emacspeak can do that current screen readers do not. Emacspeak shows syntax highlighting through speech effects and parameter changes, and has many sounds for common actions, which helps a lot. But the non-standardization of many Emacs packages, and the popularity of VS Code among blind people who want to code, or learn to code, or are more technically inclined like me, make it far easier for me to recommend VS Code with a current screen reader than to recommend blind people switch to Linux or Mac, and use Emacs with Emacspeak. Of course, I'm only one blind person. There are blind people who have mastered Emacs and use it for everything, but I just want things to work for me nowadays, and find myself much more productive on Windows and VS Code, but really miss Org-mode and its simple power that I could actually grasp. Devin Prater On Tue, Nov 3, 2020 at 6:15 AM Ken Mankoff <mank...@gmail.com> wrote: > > On 2020-11-03 at 00:24 -08, David Rogers <davidandrewrog...@gmail.com> > wrote... > > I disagree (in principle, not just because it would be difficult) with > > the idea of “expanding beyond Emacs”. Org-mode benefits greatly from > > current and future Emacs development, and asking to standardize “just > > the parts that are not Emacs” would cause Org-mode to lose that huge > > advantage. Org-mode relies heavily on the editor it’s built on, and if > > it ceased to rely on Emacs, it would be forced to rely on “nothing at > > all” instead. Not only that, but for Org-mode users being able to > > count on all of Emacs is a big part of why it works. This means > > separating Org-mode from Emacs is a “lose-lose” idea. > > It seems like you have never used Orgzly or read on Org file on GitHub. > Those are not ideas, but are actual current real-world win-win > implementations of parts of Org outside of Emacs. > > More of these would be better. > > Everyone on this thread who says you can't separate Org from Emacs is > correct that it is unreasonable to expect a 100 % bit-compatible and > keystroke-compatible experience outside of Emacs. I don't think that level > of re-implementation was what the OP was suggesting. > > Again: GitHub. Orgzly. The conversation should move from "it can't be > done" or "it isn't helpful" (why so much negativity on this thread?) to > > + What parts can be standardized and re-implemented outside of Emacs. > + How do we define graceful failure for the other parts. > + How do we support 3rd-party implementation in a way that benefits all of > us. > > -k. > >
