From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AN5ELc9zoV8GBwAA0tVLHw (envelope-from ) for ; Tue, 03 Nov 2020 15:14:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 6E8hKc9zoV+ecQAAB5/wlQ (envelope-from ) for ; Tue, 03 Nov 2020 15:14:23 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 066379403A6 for ; Tue, 3 Nov 2020 15:14:22 +0000 (UTC) Received: from localhost ([::1]:39032 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZy0q-0000WU-9c for larch@yhetil.org; Tue, 03 Nov 2020 10:14:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZxSr-0001sM-2Q for emacs-orgmode@gnu.org; Tue, 03 Nov 2020 09:39:13 -0500 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]:39707) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZxSm-00082U-RX for emacs-orgmode@gnu.org; Tue, 03 Nov 2020 09:39:12 -0500 Received: by mail-il1-x132.google.com with SMTP id q1so16306521ilt.6 for ; Tue, 03 Nov 2020 06:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bUe73UjFZqMcktd79aG+qDMqIOKEQSPOMm9EmC25zE4=; b=JFicEznnar869VHsElFyciqeml8Hhglcug/1Z7/n7j3TXdy2q4tRmwTvJPng0+ZIbI qUSyFGkOy3SdXxl/tZDJ2Jts48Ow4PHo1yzNeClNSjQzKlDx6Pc+D6nX+M8+NxOe5tpv GaUTeqBEV8OSKll5isAsGwq94Qr+4/YlUko8M98fqXs6ypzSjoOpWAtRYcrkr9NRIZkR HOLaFx+jEVluFWkPXQPgUdr9JTvXOKg4zMGIssJnJuJo5RMfDzLVHiu5dwNwqr5D3yCW Dtx4EhBXPxTkrwRVdSsXmmV3W6wgZuuBx/F8kdROVw7fW4NY8rmYoYm5I4FKNEiziCRs 6mgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bUe73UjFZqMcktd79aG+qDMqIOKEQSPOMm9EmC25zE4=; b=cigCA/BMnQGTJkE7W5qMPUfGJY9bvwoqGxiqjLfTw9Ip4lMlZChHwcKDlfbm//h7+w ut7StXgJ5NnOagz2j/vClrGyXGbf6yLDWFUAVKRHRabu+3UZZwzpk2ugEx2zlOJHA+pJ M15CChHQBVF+UupFTCdxvDHLaNcpvWZx/XD0QTHynanWGXaHXtGNDQEFR50s6V7jtqIV NnAPHl1wkK6Iol7YFHB4mZedQGO5fq4o/+iIdc6QjU46i8HtXaAGP5hs3JstRhKMLp4X bTuuJwHd6FMW969c83je23XPnsOZ7Qd1wlQrUBSeKaXqQyEl/u7/sNTq6v9ko9bYLlsa 2Gvw== X-Gm-Message-State: AOAM532Rp4Q2POC7uHbxoY06sn9MlRlpR60/eeIlKMn6mNFX2iNNeADc dftdd98EInmECjvhcVQeeK0iX/5tVCvotrxHPNc= X-Google-Smtp-Source: ABdhPJxRpZS4QT7o8NXCDmyQ8fMX41ooOyFOmfyZm2eE3zkBGHJEvSJZ8Uv6VqgmE5oJ1Xla88A6Kkrggmrvq71c00s= X-Received: by 2002:a92:1f19:: with SMTP id i25mr15656215ile.198.1604414347359; Tue, 03 Nov 2020 06:39:07 -0800 (PST) MIME-Version: 1.0 References: <87eelaeixa.fsf@gmail.com> In-Reply-To: <87eelaeixa.fsf@gmail.com> From: Devin Prater Date: Tue, 3 Nov 2020 08:38:54 -0600 Message-ID: Subject: Re: Thoughts on the standardization of Org To: Ken Mankoff Content-Type: multipart/alternative; boundary="0000000000003f3be705b334d3bc" Received-SPF: pass client-ip=2607:f8b0:4864:20::132; envelope-from=r.d.t.prater@gmail.com; helo=mail-il1-x132.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Rogers , emacs-org list Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=JFicEznn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: Yuy2OvJXGkbG --0000000000003f3be705b334d3bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > > On 2020-11-03 at 00:24 -08, David Rogers > wrote... > > I disagree (in principle, not just because it would be difficult) with > > the idea of =E2=80=9Cexpanding beyond Emacs=E2=80=9D. Org-mode benefits= greatly from > > current and future Emacs development, and asking to standardize =E2=80= =9Cjust > > the parts that are not Emacs=E2=80=9D would cause Org-mode to lose that= huge > > advantage. Org-mode relies heavily on the editor it=E2=80=99s built on,= and if > > it ceased to rely on Emacs, it would be forced to rely on =E2=80=9Cnoth= ing at > > all=E2=80=9D 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 =E2=80=9Close-lose=E2=80=9D 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 leve= l > 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 o= f > us. > > -k. > > --0000000000003f3be705b334d3bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 bendin= g Org-mode to fit what I use it for, and love heading folding and having al= l things pertaining to work, for example, in one document, and being able t= o 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 bl= ind 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 extensio= n author hasn't made accessible yet, because the whole UI works with th= e screen reader. Sure, it's not perfect yet, but Language Tool, Grammar= ly, all Markdown extensions, all work great with my screen reader in VS Cod= e, and I love using those tools. But no Markdown extension comes close to t= he power and flexibility of Org-mode in Emacs.

Yes, this= could be me just wishing Emacs worked better with accessibility tools in W= indows and we didn't have to rely on Emacspeak and such in other operat= ing systems, because ultimately Emacspeak pretty much relies on the author = or other contributors working around Emacs, to make Emacs' modes work w= ell in an auditory environment. And that works great, until you roam outsid= e 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 l= ike 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 p= retty cool, since VS Code is pretty much built on web technologies. And the= re 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 Emac= s in the first place. I might just get a virtual machine up and going and j= ust 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 paramet= er 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 Co= de among blind people who want to code, or learn to code, or are more techn= ically inclined like me, make it far easier for me to recommend VS Code wit= h a current screen reader than to recommend blind people switch to Linux or= Mac, and use Emacs with Emacspeak.

Of course, I&#= 39;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 mis= s Org-mode and its simple power that I could actually grasp.
Devin Prater<= /div>


On Tue, N= ov 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> wrot= e...
> I disagree (in principle, not just because it would be difficult) with=
> the idea of =E2=80=9Cexpanding beyond Emacs=E2=80=9D. Org-mode benefit= s greatly from
> current and future Emacs development, and asking to standardize =E2=80= =9Cjust
> the parts that are not Emacs=E2=80=9D would cause Org-mode to lose tha= t huge
> advantage. Org-mode relies heavily on the editor it=E2=80=99s built on= , and if
> it ceased to rely on Emacs, it would be forced to rely on =E2=80=9Cnot= hing at
> all=E2=80=9D 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 =E2=80=9Close-lose=E2=80=9D idea.<= br>
It seems like you have never used Orgzly or read on Org file on GitHub. Tho= se 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 c= orrect that it is unreasonable to expect a 100 % bit-compatible and keystro= ke-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.

=C2=A0 -k.

--0000000000003f3be705b334d3bc--