Re: Thoughts on the standardization of Org

[Devin Prater <r.d.t.prater@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5198 bytes --]

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 <mankoff@gmail.com> wrote:

>
> On 2020-11-03 at 00:24 -08, David Rogers <davidandrewrogers@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.
>
>

[-- Attachment #2: Type: text/html, Size: 5888 bytes --]