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: Thu, 09 Jun 2022 12:38:04 +0300 Message-ID: <831qvy41oj.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23425"; 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 Thu Jun 09 13:34:29 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 1nzGQn-0005qN-1y for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Jun 2022 13:34:29 +0200 Original-Received: from localhost ([::1]:54288 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzGQl-0001UM-VE for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Jun 2022 07:34:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzEcE-0007ab-SU for emacs-devel@gnu.org; Thu, 09 Jun 2022 05:38:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51126) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzEcD-0002LA-Mz; Thu, 09 Jun 2022 05:38:09 -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=ClSpk0lP+nxbcBIXowezzVJsCxQOCpGXXAz/1/LZChc=; b=iWPj9QhlPDyj nIvcU0O4PxWVPwV/rrxoqGGAOdeXwMt3Fsk2+raexBEXL+3N/oKycv14g8W+YdEPOvjFTDnOAMkAb SQSL8817A4QQs3FmZ1J/U5xe532cYfZLfc3P6QdELXTWhpwU3/VY0fOWvDG0sragSLJqKmrekg73l rYQtZa4IokDfd0nFoLyI88OSJbS+EBBtuUzmuvis2Z+nZLgNLyEM3QyEF3KaaDoEU/aFJg8LMkHB/ NSg6hJLPhVWEdkXXSfeT2/BWsU6ZW3IfJG4aas0UkCjlG5NGmMKa2g7HaDd4oaCz50ZIBP+yB6exs w60P7HTWg/m7EOhy2m24ag==; Original-Received: from [87.69.77.57] (port=1115 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 1nzEcD-0008Pw-5q; Thu, 09 Jun 2022 05:38:09 -0400 In-Reply-To: <87fskei4fa.fsf@localhost> (message from Ihor Radchenko on Thu, 09 Jun 2022 17:15:05 +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:290965 Archived-At: > From: Ihor Radchenko > Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org > Date: Thu, 09 Jun 2022 17:15:05 +0800 > > > 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. 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. > 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". > 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. > 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. > > 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. Modes for editing mostly human-readable text. > 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. > > And even those leave alone basic movement commands, like C-S- > > which Alan mentioned. > > C-S- is not a basic movement command. Of course, it is: it moves by paragraphs. > By default, it is activating > region. Without shift-select-mode, it is not bound to anything. But shift-select-mode is on by default. > > 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? That's one way. Another one is to have a minor mode that users could turn on when they need it (or turn it on by default in their init files if they need it a lot). > Would it help if we hide the babel-related stuff under dedicated prefix > map? Probably.