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 11:56:29 +0300 Message-ID: <831qvuw98i.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2583"; 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 10:58:03 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 1o0JQ3-0000TX-Eo for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Jun 2022 10:58:03 +0200 Original-Received: from localhost ([::1]:40292 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0JQ2-00064A-30 for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Jun 2022 04:58:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0JOp-0005Ga-CV for emacs-devel@gnu.org; Sun, 12 Jun 2022 04:56:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43452) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0JOo-0005i9-It; Sun, 12 Jun 2022 04:56:46 -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=tayOzSNOTe71j4uQcsOR/xfYaOdfOAC4YMURvoOqDpA=; b=raTAygKRCqnM GNS/1j2q27yeHAwu0jXt6cnYeMaR9C2hDgxCDUZ4buYtPEwPq+6wBQkd7zgPs3Q2o4ML8KhnHYHqi w+8X1ipgdkQXQgzjDVrBHhkcW0CYdWOscUHzXJHG5o0X80rGxb4BjLezv8LQ6jEJhCZpswQ4I+rdu LXypWp3/ppRCPPcxcSTEQpcfJYaKw1nT5TvnhIjWRheegBZFykBoXVX8GJqnUd3L6j5Xg1ezk8dd4 QPWprgtpsDr6VpRRaAJyAeIzI+siBDcbl6JdwNc0PLExGbYn2Xz0AYSBf2Hzs1Hyu8WwoA6g+TVow XClfvu0HaL/ny+TYAJfF4Q==; Original-Received: from [87.69.77.57] (port=1151 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 1o0JOo-0001NC-30; Sun, 12 Jun 2022 04:56:46 -0400 In-Reply-To: <87a6aiqnpc.fsf@localhost> (message from Ihor Radchenko on Sun, 12 Jun 2022 16:40:31 +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:291078 Archived-At: > From: Ihor Radchenko > Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org > Date: Sun, 12 Jun 2022 16:40:31 +0800 > > > For a serious discussion of this example, I'd need more detail about > > the aspects you mentioned above (it is not trivial to deduce them from > > looking at the top levels of org-forward-paragraph). Specifically: > > > > . how does paragraph definition depend on context in Org, and what > > are the possible definitions in the existing contexts? > > . why don't paragraph-start and paragraph-separate fit Org, and can > > we come up with a small number of additional variables that would > > augment these two so that the built-in forward-paragraph could be > > extended to cover Org? > > 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. > > My main concern is that forward-paragraph is used when editing the > > purely textual parts of an Org document, and when used there, casual > > users of Org will expect it to behave as the command behaves in plain > > text. Any deviation from the behavior of the built-in command will > > confuse such users when they edit the plain-text parts, and should > > therefore be avoided. > > 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. > >> org-open-line > >> org-beginning-of-line > >> org-end-of-line > > > > Each of these (and other examples you provided) should require a > > separate serious discussion. Let's take open-line as an example. It > > is basically the built-in open-line, unless org-special-ctrl-o is > > non-nil. A trivial extension of the built-in command could have > > prevented the need to remap. (And why does the support for tables in > > org-open-line need to be turned on outside of orgtbl-mode?) > > 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? > 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 | > > will produce > > | this | is | table | > | with | > 2 | lines | > > while org-open-line will produce > > | 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. > > 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.