From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Sun, 12 Jun 2022 17:46:04 +0800 Message-ID: <87wndmp63n.fsf@localhost> References: <87leuca7v7.fsf@disroot.org> <87h74ztshe.fsf@gmx.de> <871qw31ois.fsf@yahoo.com> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25044"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 12 11:46:58 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 1o0KBN-0006Ia-VH for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Jun 2022 11:46:58 +0200 Original-Received: from localhost ([::1]:37510 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0KBM-0001HU-8g for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Jun 2022 05:46:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0K9z-0000Sh-VV for emacs-devel@gnu.org; Sun, 12 Jun 2022 05:45:32 -0400 Original-Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]:35566) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o0K9y-0003fJ-1c; Sun, 12 Jun 2022 05:45:31 -0400 Original-Received: by mail-pl1-x636.google.com with SMTP id o6so2761475plg.2; Sun, 12 Jun 2022 02:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=o8J3wlnRKWCk7h6BFS7tGMA7JZzblCw5xpVRkOM9F1E=; b=lCoBsQt5+5Yh0CXxZCSuL5vhZnn3mGNuPQTgrJnDlekb+EVnFcA/Gr6inI9LEu8LyZ PDkdO0kgFgPJSgPU6yDtnZhdwTx0czJ8uy9ihmgRivxl8ECGLdQtW/xzVdFAmyEzig1q wsnT6Xua/Vh9+riK2pNeA+i9hVa83P5yql6YVz1dRG39TXpiiXjJUO/kTvryWd6ebEAV qWrkuwe6HfCVzmLGeedx4OPnzepasMZO8tAhVhd+sdviK/uSamOkb0KjyznbjsAoXPmw 76bPoP8T8ZYiYSeW8Q+fNZJ5sDSqb8u9ZHVFKngikNCpqhWqmj5pvdCDwR0rsRCQsbFP UKCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=o8J3wlnRKWCk7h6BFS7tGMA7JZzblCw5xpVRkOM9F1E=; b=YDRFJysOa83yKzi4P+AjJNypgOntZSReu7owbH6XWv0WGf8YxQ45rbDrMYEp87YW0j 9W8fS0tsY4RlXamPOCiQ1TJasZ3Py7QuQTkSva8TAzHywA5s8zf8N4gpPPLhqLYVjn5v yKYqtWGgVy4dmjqdFKqfh1L4NqLg/kHvn29yjibXLRte7h4qR0NGVjmO39vxN1AskeWv /0yejKzhxPGnWYk3IhH5C+QcaWx+ytsLUK6IPMEgqPh5CFahE27RVbIup2Z+F0ci/u/e rSCITr+fNL/coQ1CLNWAUgEsrh9F8W1bEkrutEGM0baoDOw/FqWEfWH0g6NpGXTf6zR3 69zA== X-Gm-Message-State: AOAM5316J2wdzCBnokWyInK7OJwkqnkmar9cPYs99X42Y+BxDHBLXpTX IlSSoQ3C/nwtWDeGapsLkgV2Q9Le12zirg== X-Google-Smtp-Source: ABdhPJwgHfYa3YdxcnbLLEuF7ZWWE9sKSF0dyrKuHReviiDlWhK4Tb/YPfUAw134LyOn0eYnO1m5mg== X-Received: by 2002:a17:902:eac5:b0:167:54f6:a110 with SMTP id p5-20020a170902eac500b0016754f6a110mr43411957pld.127.1655027127979; Sun, 12 Jun 2022 02:45:27 -0700 (PDT) Original-Received: from localhost ([23.27.206.157]) by smtp.gmail.com with ESMTPSA id n22-20020a056a00213600b0051b9c02e4a3sm3000555pfj.178.2022.06.12.02.45.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jun 2022 02:45:27 -0700 (PDT) In-Reply-To: <831qvuw98i.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::636; envelope-from=yantar92@gmail.com; helo=mail-pl1-x636.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:291084 Archived-At: Eli Zaretskii writes: >> I do not want to start a serious discussion on this just yet as I do not >> plant to work on this specific area in near future, however I would like >> to answer some of your questions in order to provide some insight for >> Emacs developers. > > Thanks, but if we are not going to continue this discussion until we > come to some conclusions, I see no reason to keep talking about it. I > do understand better the difficulties now (thanks!), but I'm not yet > convinced that the existing solution is the best one. There are some interim conclusions for now. I agree that the approach Org takes on remapping may be improved. I will keep in mind to reach to emacs-devel about possibility to extend built-in Emacs functionality if it is required to get rid of the Org remappings. >> There is no difference between forward-paragraph and >> org-forward-paragraph on purely texture parts. The difference is only on >> the Org-specific constructs, where forward-paragraph would behave >> unexpectedly. > > How does Org make sure that the different behavior doesn't happen > without the user's intent? Isn't it possible that Org perceives > something as a sign of an "Org-specific construct" when the user > didn't mean that? When that happens, what can the user do to avoid > the unintended (from that user's POV) Org-specific behavior? > > These situations are where user control is necessary, especially for > casual, non-seasoned users of Org. ... >> You misunderstand orgtbl-mode. orgtbl-mode is optional minor-mode >> provided for users who want to edit tables "like in Org mode", but in >> _other_ major modes. Inside Org mode, tables are always supported. > > What if the user doesn't intend to use Org tables? How can such a > user turn off this automatic support, which interprets some patterns > of buffer text as an indication of a table, and turns on the special > behavior reserved for Org tables? Let me be clear here. Org syntax is fixed as much as possible. One cannot just tell Org to ignore tables in Org buffers. However, users can alter behavior of specific Org commands if they wish to. Using available customization and other usual Elisp tools. One would not expect, say, tex-mode behave correctly if the user arbitrarily changes buffer syntax table. Similarly, tables are the core part of Org syntax. >> Also, org-special-ctrl-o is non-nil by default. Using built-in open-line >> on Org tables can produce incorrect formatting. For example, calling >> open-line on the following table >> >> | this | is | table | >> | with | 2 | lines | >> ... >> The default behavior is not satisfactory and somewhat unexpected. > > You assume that users always expect what Org does in that case. This > is not a given, if we want to make Org more attractive for editing > text that is "less Org-specific", so to speak, like README files, NEWS > files, etc. We do not assume that users always expect specific behavior. That's wy org-special-ctrl-o is customization. It's default value has been agreed upon and has not been questioned by many. The current behavior is what most of Org users expect. The default open-line behavior is not. Otherwise, nobody would bother implementing org-open-line. >> > No, I'm saying that, sadly, we have no real control on what the >> > developers of unbundled packages decide to do. Thus, what you see >> > there is the evidence of our lack of control more than anything else. >> >> I do not get your point here. I was referring to the markdown-mode and >> Auctex to illustrate the _need_ to have numerous key bindings in order >> to edit complex Org documents. It is not just something introduced into >> Org out of the blue. Other people solved similar problems and did not >> come up with significantly less key bindings. If you say that usual >> 40-50 major mode bindings are sufficient, I am not convinced. > > 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. Best, Ihor