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: Sun, 12 Jun 2022 12:59:47 +0300 Message-ID: <83sfoaurqk.fsf@gnu.org> 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> <87wndmp63n.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14916"; 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 Sun Jun 12 12:02:43 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 1o0KQc-0003jP-72 for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Jun 2022 12:02:42 +0200 Original-Received: from localhost ([::1]:45790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0KQb-0007Zf-7r for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Jun 2022 06:02:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0KO5-0005ix-6l for emacs-devel@gnu.org; Sun, 12 Jun 2022 06:00:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44118) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0KO4-0005V6-RL; Sun, 12 Jun 2022 06:00:04 -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=Kc8eKY8BN4J+liltSjB5j5NQWHSHvyjQjaTl6UerrEY=; b=IE3MV40SFaEn 0PhTA1C3hjeBw+8TXgNg/Rl5eIJSOAh/+l6Y2Pbr6/4LfQIjqZHhx9eH5+cLqEbJqYF1Y2rtdDUN/ DQ8WgHZ3SPqo6JirbNKhwAdxiXnFrKf0w5DQ2l1XMdlPcJT2tHq1G6b7EMSOIjO4NEBKzFl8/YhHq l+D40pc45t5aWcD1FwaExVaWTER9ZCUehKZHZRfjCRt01r/7d++iv6vGNAXUti/nOZfQpWFSfXVQN le44IocRkaZi+hh0sDsgLToQjpl9XdXhURAdWJyVxiGJ33noGKDyKxITcJePsMm2gTnsrwHY0LCsM CaC/7ArEmXXnAFyhG++yFg==; Original-Received: from [87.69.77.57] (port=1177 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 1o0KO3-0000F9-DY; Sun, 12 Jun 2022 06:00:03 -0400 In-Reply-To: <87wndmp63n.fsf@localhost> (message from Ihor Radchenko on Sun, 12 Jun 2022 17:46:04 +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:291087 Archived-At: > From: Ihor Radchenko > Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org > Date: Sun, 12 Jun 2022 17:46:04 +0800 > > > 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. Thanks, I think this will indeed help in the future. > > 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. The syntax of TeX is dictated by an external tool. By contrast, the syntax of Org is determined by Org itself. 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. > >> | 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. 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. > 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 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. Adding keybindings is a solution to a problem. I'm saying that alternatives to that solution were not seriously explored fro those unbundled packages.