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: Sat, 11 Jun 2022 11:52:05 +0800 Message-ID: <87tu8rq2l6.fsf@localhost> References: <87leuca7v7.fsf@disroot.org> <87czfopmsd.fsf@gnu.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13999"; 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 Sat Jun 11 05:52:19 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 1nzsAc-0003TH-S4 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jun 2022 05:52:18 +0200 Original-Received: from localhost ([::1]:46094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzsAb-0004er-4k for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jun 2022 23:52:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzs9s-000400-DL for emacs-devel@gnu.org; Fri, 10 Jun 2022 23:51:32 -0400 Original-Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]:39590) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nzs9q-0001gl-9Z; Fri, 10 Jun 2022 23:51:32 -0400 Original-Received: by mail-pl1-x62a.google.com with SMTP id o17so797179pla.6; Fri, 10 Jun 2022 20:51: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:content-transfer-encoding; bh=RnoE0yOKEV2JwDZ6QK4DHTtJ366yGVhnk977TAVWBlI=; b=CMvrr9jUvNvsvfOMSX+BjCyaCv68ahDtj7DjGVe8UxGTB6YnmBff1qP4afm7+1BIhQ Dv0sgg+2Zyv0LDmaFWaq/tCR+sGuRgEKlUi/IQzFe7Nar/YT0nK6BSOhPcG/aAQI82ux smPOciOy32iw4hUVxLQPHwjstMOjtjCykd27ujwRPETUODvDVgCu0VZG8a3H9WBv/2/3 sBadG/Gf3UT1h1HMUIM5g4aT7hlMKvFpHezvN5Xekm3QnHsYWvpzJfjxqkJP869znZ2H fNS6nkgQYdtAicjGCTLK2qvkibjzUCW1ZPvCC1xU97Hd8l25nRQ28hdqWgO2kSSazcXq rgXg== 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:content-transfer-encoding; bh=RnoE0yOKEV2JwDZ6QK4DHTtJ366yGVhnk977TAVWBlI=; b=Pe4wdpgjIF4OrP58gcsI5VlEu+n9pPPhe2PojorRd3rKbPxA5b/52L0IV+YkqGKyLF RDTUxnhtwECa+UwUIdHSagZiRQo6Yf6qanUge6LnRNj9oTNWU/S0hrm5G3B1+lcZcexl BivmzSo2j05I0VoXv8wIkv+JXXTIFRU4It+ci+EKgcZwCYAWgHzEQCBxVcwI/Ntymsd8 QIHNIeTbgZF4yHDUYAlFcj0wGz4BWK3RTAoJPJPRy9zz0yWcyBXbvUUd0jBz5dxHYnMA ZFEFZHcMNr10WktqIb8Ok+6RaMRy/ZESpyvksFDl5IYyK/R3AtOOriTzQe0kLmkDipBj SMCg== X-Gm-Message-State: AOAM533+evMQXrVB0F6+1Kb3ciude5AfQbvZQepTObHCDwEH15h7YeU8 f4HksenSI2TmMHHDDOvhqS7ZHpAMwqiY7T3O X-Google-Smtp-Source: ABdhPJxILF9f83jrgvYLyYbqjFCROmvvU5SmLcZsXa+e9jRo5UIOWoV+gC5H7R66WRJn88S6L9tx6A== X-Received: by 2002:a17:90a:fa5:b0:1e2:ee1b:8f85 with SMTP id 34-20020a17090a0fa500b001e2ee1b8f85mr3030912pjz.216.1654919487756; Fri, 10 Jun 2022 20:51:27 -0700 (PDT) Original-Received: from localhost ([64.32.23.62]) by smtp.gmail.com with ESMTPSA id k2-20020a17090a658200b001e29a2a4abesm424608pjj.31.2022.06.10.20.51.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 20:51:26 -0700 (PDT) In-Reply-To: <831qvy41oj.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::62a; envelope-from=yantar92@gmail.com; helo=mail-pl1-x62a.google.com X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:291012 Archived-At: Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org >> Date: Thu, 09 Jun 2022 17:15:05 +0800 >>=20 >> > Are you sure this is always true? There are several dozens of >> > remapped commands; did you audit all of them? >>=20 >> I have audited a couple of them and relied on a good faith to other Org >> devs + absence of bug reports relevant to the raised concern. >> Rather then re-checking the remapped functions, I'd rather just fix any >> concrete bug reports about misbehavior, if such reports arise. > > Didn't this discussion raise such "bug reports"? Why not consider > what several people here said as such a bug report? The difference is > that these reports come from people who use Org rarely, so the > concerns are different. But if the Org developers want to have Org > adopted more widely, I think they should listen to these concerns, not > reject them. To clarify, it is metally difficult to process bug reports raised in such discussions because they are often entangled with quite negative attitude and much more broad claims. What I have summarised so far from the discussions: 1. Org mode shadows default C-S-/C-S- bindings. This can be solved in two ways: a. Change org-support-shift-select to t by default + fix the fact that org-support-shift-select is actually ignored by C-S-/. b. Disable Org mode arrow bindings by default and move them to a dedicated minor-mode / setting. (This will make existing Org users angry) Note that I do not see C-c / and C-c C-s as a bug. The first one is not recommended for major-mode but allowed. C-c C-s is dedicated to major modes. 2. Org mode binds too many keys The solution can be disabling those keys and moving them to dedicated minor modes / settings. After thinking, I do not like the idea of enabling some keys depending on the presence absense of tables/source blocks inside the Org file. This will not solve the issue in the files actually containing all those and may surprise users. 3. Some of the context-dependent Org command names are confusing as they do not reveal what the command does. The solution is to rename those commands to something more meaningful. Totally doable. =20=20=20=20=20=20 4. Org remaps some of the default commands. I can see how it can be confusing, but do not see it as a critical issue. See my response below. 5. Org mode is too slow to load. I do not see an easy way to resolve this apart from general refactoring and modularizing. Profiling is not very helpful in this specific case, unfortunately. At least, my profiling skills are not good enough. >> While I understand the possible fear of unexpected or unnatural >> behavior of the remapped command, I'd like to point out that command >> behavior can span over quite a significant range even without remapping. >> Just the fact that some major mode does not use remapping, does not mean >> that you are guaranteed to get the normal command behavior. > > Most major modes don't remap global and frequently-used commands. > Those that do are problematic, and should be fixed rather than be used > as examples of what's "kosher". Let's take one example: org-forward-paragraph that is remapping forward-paragraph. The docstring is: Move forward by a paragraph, or equivalent, unit. ... The function moves point between two structural elements (paragraphs, tables, lists, etc.). It also provides the following special moves for convenience: - on a table or a property drawer, move to its beginning; - on comment, example, export, source and verse blocks, stop at blank lines; - skip consecutive clocks, diary S-exps, and keywords. In Org mode, there is no single definition of a paragraph. The paragraphs or equivalent syntax elements are context-depended and we have to use parser to know where to move. The default forward-paragraph can only be controlled by paragraph-start and paragraph-separate regexps. Both are not sufficient to cater Org mode. Regexps do not cut it for Org mode. Hence, the built-in version of forward-paragraph is not usable in Org mode. If we did not remap it, forward-paragraph would not really move by paragraph, as it is understood by human. It would be more confusing than org version of the command. If you know a better way to resolve the described limitation, please let me know. Similar limitations motivated org-backward-paragraph org-backward-sentence org-comment-dwim org-forward-paragraph org-forward-sentence org-beginning-of-line org-end-of-line org-delete-indentation The following functions have a natural fallback to default behavior and might be moved to minor-modes enabled by default. However, their default behavior is context dependent and motivated by the lack of flexibility of the built-in equivalents. Similar to the above functions. org-open-line org-beginning-of-line org-end-of-line The following functions might be implemented using built-in Emacs functionality: org-transpose-words could use find-word-boundary-function-table org-fill-paragraph appears to be redundant as we do set fill-paragraph-function org-yank may be instead implemented using yank-handler property (it takes care about adjusting level of the inserted headlines), but not completely. We cannot control properties of text from outside of Org mode and thus the functionality cannot be fully implemented using built-in Emacs features The following commands are providing convenience self-alignment functionality and protect from accidental editing of invisible text (AFAIK, this issue is not addressed by Emacs): org-kill-line org-delete-backward-char org-delete-char org-self-insert-command I am not sure how to achieve equivalent functionality using built-in Emacs customisations. The following functions are convenience building for prople coming from outline mode. I do not see any problem here. org-backward-heading-same-level org-demote-subtree org-forward-heading-same-level org-ctrl-c-ret org-mark-subtree org-next-visible-heading org-previous-visible-heading org-promote-subtree org-kill-note-or-show-branches org-fold-show-children org-fold-show-subtree >> Some major modes rely on post-command-hook instead of remapping, which >> not only modifies the original command behavior in unspecified ways, but >> is also not directly visible from the mode bindings. Or consider changes >> in filter-buffer-substring-function and how it can modify killing text. > > And that is in your opinion a Good Thing? I don't think it is, and > therefore don't consider such problematic behavior a good example for > development. Maybe. But then we need a more "appropriate" way to implement the functionality Org provides. See the above. >> So, I'd say that your concern is not really justified. > > ??? Just because "others do that"? >> There is generally no reliable way to tell if an arbitrary major >> mode modifies standard command behavior just by looking at its key >> bindings. You have to rely on faith and report bugs if you stumble >> upon them. > > I don't see how this solves the concerns. We should still try to > minimize such problematic behaviors as much as possible. I'd like you to focus on the last example with filter-buffer-substring-function or on the ability for major mode to customise fill-paragraph-function or paragraph-separate, etc. Those changes can alter the default commands drastically. Yet, they will not be noticeable by users from looking at the M-x describe-bindings. I do not say that major modes should change the default behavior in unexpected ways. Rather the opposite - major modes should adjust the default commands to behave more expectedly within the major mode context. However, remapping is by no means an indication that a major mode is going to change things unexpectedly. Its neither sufficient nor required condition. >> > No, not IME. Show me another general-purpose editing mode that >> > defines so many key bindings. The only modes that get close are those >> > where text is read-only, so normal editing is impossible anyway. >> ... >> Auctex binds a decent number of key-bindings. VHDL mode binds even >> more (I just looked into one of the largest mode built-in prog >> modes). markdown-mode binds over 100 keys not counting prefix maps. > > Two of these aren't part of Emacs, and VHDL is an example of > programming language, where text is not really for human consumption. I get your point on VHDL. However, I am not sure why you reject the non-built-in examples. Are you implying that text modes outside Emacs core are worse than built-in? At least Auctex is largely popular among users and yet I have never seen as many complaints about Auctex complexity as I do for Org (I may be biased). Auctex and markdown-mode deal with similar editing tasks with Org mode. The fact that they also use large number of key bindings is an indication that they are really needed for editing complex documents. >> > And even those leave alone basic movement commands, like C-S- >> > which Alan mentioned. >>=20 >> C-S- is not a basic movement command. > > Of course, it is: it moves by paragraphs. Nope. It is unbound command working because of key translation: C- (translated from C-S-) runs the command forward-paragraph (found in global-map), which is an interactive native compiled Lisp function in =E2=80=98paragraphs.el=E2=80=99. >> By default, it is activating >> region. Without shift-select-mode, it is not bound to anything. > > But shift-select-mode is on by default. Fair point. Best, Ihor