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: Thu, 09 Jun 2022 17:15:05 +0800 Message-ID: <87fskei4fa.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10332"; 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 Thu Jun 09 14:10:33 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 1nzGzf-0002X6-So for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Jun 2022 14:10:31 +0200 Original-Received: from localhost ([::1]:35196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzGze-0003wl-9v for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Jun 2022 08:10:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41188) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzEFL-0005Cz-Of for emacs-devel@gnu.org; Thu, 09 Jun 2022 05:14:32 -0400 Original-Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:46842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nzEFJ-00075X-Lz; Thu, 09 Jun 2022 05:14:31 -0400 Original-Received: by mail-pf1-x42e.google.com with SMTP id j6so20532218pfe.13; Thu, 09 Jun 2022 02:14:28 -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=h+lN3jof5JVwLe3dsysNytOUwhzHoHGGj/DoTjk105g=; b=DwQIkySWxdoMjLN1sb8i5m62LARR2QkeKi3Xe+gToWqz9LyAkStCYUyMSvsE0WXpHT 9RH4lIroTVu4cZPr7xyGUjy8gRMIGFgb7rTro9qouCz8aSR5d5Yzmwh8EpFXF6/D91ks jp0HDSZIpUJ7SbudaKn1ezEPUvJzeQFPx03Gv3QEso8Ztwa+/dfEnlUWMcHYX7vo7axe Bfz+MmwsJ6eBwagcA62OCc7xjCv1nMYunk6m6vXhs9rLpj5NoWrhog5fqxBdTQ3Q+Rwl /kSZt3sSqfBY+tWOfz3/QoKwjQ+Bm5sxzG0i5XwA44++h70rOKpFa4Sv2s23tR0ncBr3 kfAw== 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=h+lN3jof5JVwLe3dsysNytOUwhzHoHGGj/DoTjk105g=; b=1ZvKkobe+bc0jryKSMXQ0HHXRSU+rIQE0RzGZqZXmLwxbzLZ6WJR2HkSxM3Qcfqv0i JUsER6yGwG2UnLSI7R1etyqmfo1FjxOZjc+fINF6tKcWXDhf+oL/KjNDrYcDM/wGKwuU j/HsHn2aCdKGquNiMZe5B+30tujkRJ85o/2D/B54CMDO+M2yOzqgKwLqZvgqvL/+FZfu DDHAR2hM9utDR/ZH2nkg8HjDOWeuTCyd1jjoYM0XEibRg1PGNe40XlKhTlQXsSmgl+Zo u6IVXlItQ2g8gqaFZAVOZhMBDLDCflqrdLpnSyWPOmx4aVak/lnXrd5xVf0iuOQEBiCP oxDA== X-Gm-Message-State: AOAM531Road/dSSBEcH2qT8eXXzfR6DNhyTBfugRgA9uemMHdhuL6Vpx NzvGxkJcmWtjbBHwMmAUBEittOAZh8qnjg== X-Google-Smtp-Source: ABdhPJzlRvm9bpyWtCDxzS1BP8cUNzKtuNudRY/EQ5uYrSXrVzSh6CJPS76ieXjMrky4oXdRP2wWug== X-Received: by 2002:a63:d008:0:b0:3fc:f8bb:4ed9 with SMTP id z8-20020a63d008000000b003fcf8bb4ed9mr31608785pgf.215.1654766067143; Thu, 09 Jun 2022 02:14:27 -0700 (PDT) Original-Received: from localhost ([64.32.23.62]) by smtp.gmail.com with ESMTPSA id k20-20020a17090aaa1400b001dc37aef4ffsm15403652pjq.48.2022.06.09.02.14.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jun 2022 02:14:26 -0700 (PDT) In-Reply-To: <83zgin3zcm.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=yantar92@gmail.com; helo=mail-pf1-x42e.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:290967 Archived-At: Eli Zaretskii writes: >> Not really. The remappings usually intend to re-implement the usual >> expected Emacs behavior inside Org. It's just that it is not always >> possible using the built-in functions. Hence, we implement a layer on >> top. >> >> There should not be anything to learn with regard to remapped commands >> given that Org defaults are not changed. > > Are you sure this is always true? There are several dozens of > remapped commands; did you audit all of them? 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. > And anyway, even if what you say is 110% true, how am I as a user to > know that up front? I'm used to read the documentation of every > command I don't already know by heart, so when faced with such massive > remapping, I have quite some reading to do before I can feel myself at > ease. > > And please note that, unlike Alan, I _do_ use Org, just not very > often, at least these days. So what I'm sating doesn't come from the > POV of an anti-Org user. I _want_ Org to be easier and less demanding > to use. 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. 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. So, I'd say that your concern is not really justified. 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. >> > The difference is that we had years or decades to get used to the >> > Emacs defaults, and once Org is turned on in a buffer, one has a lot >> > of new stuff to get used to. Unless Org is used constantly, you will >> > forget most of those changes till the next time, so this re-learning >> > experience will be repeated every time. >> >> Isn't it the same for any other major mode? > > 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. I am not sure what you mean by general-purpose. 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. > And even those leave alone basic movement commands, like C-S- > which Alan mentioned. C-S- is not a basic movement command. By default, it is activating region. Without shift-select-mode, it is not bound to anything. Org does provide support for shift-select-mode, but we never got overwhelming requests to enable this support by default. C-/, which is the actual basic movement command is not overridden by Org. AFAIK, the only shadowed command is M-/ with its other C-/ binding being untouched. However, I am not even sure what Org can do about this. Arrow bindings are one of the most core and frequently used commands. Removing them will dissatisfy existing users. Note that Emacs dedicates C-c + letter for user bindings. Anything else is not guaranteed to be not shadowed by major/minor modes. If users absolutely want they personal bindings to be preferred, there is always override-global-map. >> > It isn't a catastrophe, of course, but we should recognize this as an >> > issue, especially if many of the bindings aren't needed. >> >> I am not sure what you mean by aren't needed. > > Ask Tim Cross: the claim that most of the 230 bindings I counted > aren't needed comes from him. He was referring to reading Org files without editing. You can argue the same for reading pretty much any other major-mode files. Most bindings will not be needed. >> There is no doubt that you do not need most of the bindings just to >> navigate Org files or do basic editing. You do not need to learn those >> other bindings either. > > Then why bind them by default? why not wait until I actually need that > functionality? If that's hard or impossible to detect automatically, > let the user say so. For example, I could envision a minor mode that > enables Org-Babel and binds the corresponding commands to keys. Org-babel bindings are needed as soon as you create a source block inside the Org file. Are you proposing to track changes in buffer and autoload babel as soon as a source block appears inside the buffer? I'd say that conventional approach is binding the relevant commands and letting Emacs to do autoloading once those commands are called. Would it help if we hide the babel-related stuff under dedicated prefix map? Best, Ihor