From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Wed, 15 Jun 2022 15:49:06 +0300 Message-ID: <83czfart19.fsf@gnu.org> References: <87leuca7v7.fsf@disroot.org> <8735gj4ceo.fsf@gnu.org> <87ee038ipt.fsf@gmx.de> <87o7z61v59.fsf@gmail.com> <87bkv527p5.fsf@gmail.com> <835yld93w7.fsf@gnu.org> <877d5t0yrn.fsf@gmail.com> <83o7z47m7y.fsf@gnu.org> <8735gfs3is.fsf@localhost> <838rq75jhg.fsf@gnu.org> <87fskfqj97.fsf@localhost> <83zgin3zcm.fsf@gnu.org> <87fskei4fa.fsf@localhost> <831qvy41oj.fsf@gnu.org> <87tu8rq2l6.fsf@localhost> <83czffzo73.fsf@gnu.org> <87a6aiqnpc.fsf@localhost> <831qvuw98i.fsf@gnu.org> <87wndmp63n.fsf@localhost> <83sfoaurqk.fsf@gnu.org> <87tu8mv79u.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14072"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 15 14:51:25 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o1SUW-0003TO-Uv for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Jun 2022 14:51:25 +0200 Original-Received: from localhost ([::1]:54686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o1SUV-00080h-Ed for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Jun 2022 08:51:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1SSS-0006ld-T3 for emacs-devel@gnu.org; Wed, 15 Jun 2022 08:49:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60714) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1SSS-00067f-1d; Wed, 15 Jun 2022 08:49:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SnB37JZNUfcuKa5kIcRpOhjMMIBWtk1fvygw4XFMKbc=; b=Jq2jYFJh0GeY PzeARfytjRRkPUS7hcHiDBOoDORKwUFbtcKQWN/XWenHeu+RU5jAHab8bC5vV12MBNUAkxrQdJpIX m1TqCu1jJ0/eiVkVetWhV5ix+QpN9taBuq1nUqoZm4Wrk5LSI0f7gzgiZVUs6Fc5iebcnzm0tcmKW /64cauxcNNvjL1wyV2GFCHCqw1SM2j9Pf8lny7XMVJkq16xb/EOR22DdqRlmYVSgcrAvJ6/+abpBQ l3kpqc7qx3XfHs9LhpB1xBYjDfUTXx0yl/ZN9IkeR7QuDc/TaVHXNBbgNA3Wj/g28R5jDXNYe0BHC Hw5CImRaoPGOROj+/G7iCQ==; Original-Received: from [87.69.77.57] (port=4938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1SSR-0004Le-Gv; Wed, 15 Jun 2022 08:49:15 -0400 In-Reply-To: <87tu8mv79u.fsf@localhost> (message from Ihor Radchenko on Wed, 15 Jun 2022 13:13:17 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291210 Archived-At: > From: Ihor Radchenko > Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org > Date: Wed, 15 Jun 2022 13:13:17 +0800 > > Eli Zaretskii writes: > > > The syntax of TeX is dictated by an external tool. By contrast, the > > syntax of Org is determined by Org itself. > > Not exactly. We have to keep backwards compatibility and keep in mind > external packages. So, syntax changes in Org must be avoided unless > strictly necessary. And they should be backwards compatible even if the > changes are necessary. This is a tangent, entirely unrelated to what I said. My point was that, unlike TeX source, which can only be submitted to TeX, and therefore must follow TeX syntax and is written by people who are familiar with TeX, Org is being advertised as a mode for editing mostly-plain text. And in plain text, what Org decided to take as an indication of a table could very well be something else, because the user just typed plain text, and was oblivious to its meaning in Org. So Org is _unlike_ TeX mode, in that the assumption that every environment or markup are only used where their Org meaning is intended -- that assumption is not necessarily true, while it is in TeX. > > Is an Org table always preceded by some directive that makes it > > impossible to interpret innocent text as a table? If so, perhaps the > > problems that were bothering me don't actually exist. > > > > But if Org interprets some text patterns as meaning that there's a > > table here, that could be contrary to user expectations. > > Org tables are always preceded by ^[ \t]*| That's what I remembered, and that is exactly what bothers me in the context of this discussion: seemingly innocent text sequences are interpreted by Org in some very special way, and the user doesn't always have good means to disable that interpretation when it is not intended. > I am not sure what is the problem here. One can just not start lines > with | or put zero-width space if starting lines from | is absolutely > necessary. Imagine a user who has no idea that a space and a | at the beginning of a line means it's an Org table, and thus won't realize that this magically changes how commands behave in that chunk of text. That is the problem that was in my mind when I said that the special table-related behavior should be better controllable and perhaps off by default. > >> We do not assume that users always expect specific behavior. That's wy > >> org-special-ctrl-o is customization. > > > > Relying on a user option for something that can need frequent > > adjustment is not the best UX. defcustom is only a good solution when > > it expresses a more-or-less constant user preference that change only > > very rarely. If I may need to change the value before invoking a > > command, that's inconvenient. > > I am not sure why you need a frequent adjustment of org-special-ctrl-o. If some instances of the same sequence of characters are indeed meant to be a table, and other instances in the same file aren't, or if I need to edit a file where they have this meaning and soon after a file where they don't, I'd need to flip the option on and off very often. > >> It's default value has been agreed upon and has not been questioned > >> by many. > > > > Maybe because most Org users are frequent Org users and always know > > what they want well enough? As mentioned, I have other kind of users > > in mind. > > I understand, but we have to consider the needs to majority of users, > right? Majority of Org users or majority of Emacs users? If we want to promote Org to be used more widely and frequently, that would inevitably mean it will be used by Emacs users who use Org only infrequently, and those are the ones I'm thinking about. We should make it easier to use Org infrequently, by people who don't do everything in Org. > >> > I'm not arguing with the need, I'm arguing with the particular > >> > implementation that caters to that need. > >> > >> Sorry, but I do not understand what you mean here, except that you are > >> dissatisfied with the existing implementation. AFAIU, you objected the > >> number of Org bindings. That many of them are not needed. I think my > >> reply was targeting your objection. I did not recognize any kind of > >> reference to implementation specifics. > > > > Adding keybindings is a solution to a problem. I'm saying that > > alternatives to that solution were not seriously explored fro those > > unbundled packages. > > How can you tell it with confidence? I can, because I'm talking about what the Emacs core developers did (or, rather, did not do). If you somehow interpreted that to allude to the developers of the respective packages, that was not the intent. IOW, I'm saying that when you compare the ELPA packages to Org in these aspects, the comparison is not really valid, because Org gets much more attention from the core developers than the ELPA packages, especially since there's a tendency to use Org in more situations. > If you have an ideas about any better way to deal with editing > complex markups, please share it. As I said before, these issues should be discussed one by one. There's no reason to believe there will be a single solution for all of them.