From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Thu, 09 Jun 2022 05:34:09 +1000 Message-ID: <87ilpaevi3.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33792"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.26; emacs 28.1.50 Cc: 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 Wed Jun 08 22:45:40 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 1nz2Yd-0008ZQ-KQ for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Jun 2022 22:45:39 +0200 Original-Received: from localhost ([::1]:41620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nz2Yb-0005Ta-U8 for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Jun 2022 16:45:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51872) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nz2Ws-00044A-IB for emacs-devel@gnu.org; Wed, 08 Jun 2022 16:43:52 -0400 Original-Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]:47096) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nz2Wp-0001Fg-NP; Wed, 08 Jun 2022 16:43:49 -0400 Original-Received: by mail-pf1-x434.google.com with SMTP id j6so19304938pfe.13; Wed, 08 Jun 2022 13:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=hSNY9oy/HgMDlbFfwAKfqXWDZAfkNPz3QfJOMcEJqEE=; b=DAs4ZOdpA/JijeljyKn7h7WXJd4fDqA/UZgMBq0YY1PRpWcPU+ZYmEfDrjGxe2UIXG 3mBN3mdivnrGR5dEhBELdtbHfGX7kjyOrW9FvDZCl3lViUra7+Ke0M2HyibD9P0rHG/M A3QeMYheO/NMobuy90SaL1rch1Ql2/CIOJpM61Q9vXi7IS+OW7zjMLiQu/Un1z75bxom 37vms/Em1HZ8g/OPLWMX1M1WpW2nR05dxF1Mi7R6meCwuAPFDfCZTn88m50ZmE9usQ9M Rbf7FIuZ62jX7/jpajsv8Yvi6W8DYBE7BBgO/otGwUKpD2Bx0qDl7IP0RFRwWdqsBCWc b0fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=hSNY9oy/HgMDlbFfwAKfqXWDZAfkNPz3QfJOMcEJqEE=; b=iJiCNyHRnwmqeZVzK3Pe+9mfg/CVAlvEbrVHNM7A9gQ5jBmOEwRYQsr5cgUZt8RSKc DCN5mb7Ji9F+8N+VlZ3TJ0+bu+EyVxumLhf3kk1MRzgmK6R5vsoSK1Vlt7Idm+hb6+kd 7LlyyXwkL+wl+E57GWsiEDMzC+xxwyfzw7S7Ecd/GbIHYF7FrI1KQ5Vd5Qamqez2gRwH aQU5yfXcGCqcoFS8U/10C52xz+1MvqGqXoPHQ+0ikjzsivRwRRB5BXnqJNxHp/4WovMq 9b/uRVkfBW/KjDpAqA7oEAuCn/4bolKzdYo8E3580hf6DQm3mu6dbivamvXzEpHUmrmJ Yy7A== X-Gm-Message-State: AOAM532ZBNA4848DJU1Dley/fpY6Dcpr0x3QfEUBLaAuaoVwJGsmRPQc /QMYRfg3kvG4a5pZR6HzSUXJqmNpviQ= X-Google-Smtp-Source: ABdhPJwGoBvYbGIQedVIJsw+vRdOpeTxh5YvmzkMOK/UJGkic+aLnD3KsRXQXCBXzwKu1P2oCE/vyw== X-Received: by 2002:a05:6a00:1805:b0:51c:1a6:2253 with SMTP id y5-20020a056a00180500b0051c01a62253mr21784563pfa.70.1654721025332; Wed, 08 Jun 2022 13:43:45 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-168a-02aa-14c7-49e4.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:168a:2aa:14c7:49e4]) by smtp.gmail.com with ESMTPSA id t190-20020a6381c7000000b003db7de758besm15703104pgd.5.2022.06.08.13.43.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 13:43:44 -0700 (PDT) In-reply-to: <83o7z47m7y.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::434; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x434.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_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:290954 Archived-At: Eli Zaretskii writes: >> From: Tim Cross >> Cc: acm@muc.de, emacs-devel@gnu.org >> Date: Tue, 07 Jun 2022 16:14:52 +1000 >> >> > I can tell you what I see with my very simple 1570-line Org file, >> > which just has some todo items organized in 4-level hierarchy: >> > >> > . ~100 keys that look "general Org" to me >> > . ~30 keys that Org remaps to its s own commands, like 'yank' and >> > 'backward-sentence' >> > . ~40 keys bound to org-babel-SOMETHING -- no idea why these are >> > bound by default, but they are there >> > . ~60 more keys that I'm not sure whether they are "basic" or not, >> > but they are all bound by default, just because I visited an Org >> > file >> > >> > So "just" 230 key bindings. And this is without any minor/add-on Org >> > mode/feature enabled, at least according to "C-h m". >> > >> > Do you see something different? Are you still saying that it's not a >> > lot, or that it's "based on ignorance and paranoia"? If so, please >> > point out where I'm ignorant and/or paranoiac, because I'd really like >> > to know. >> >> I think Alan's response has pretty much confirmed what I was saying. Alan has >> made it fairly clear that his real underlying concern is about a stealthy >> strategy to get org mode more intrinsically tied into Emacs and in the end, >> making it so critical to normal operation that everyone will be forced to learn >> org mode regardless. I don't necessarily agree with such an argument, but think >> having a debate around that would be more up-front and in some ways honest >> compared to what appear to be somewhat contrived alternative arguments about >> excessive key bindings and added complexity. My characterisation of this all >> being fear and paranoia may have been overstating things, but then again I'm not >> sure. There certainly does seem to be considerable fear involved. I don't know >> about paranoia, but I have not seen any evil plan to have org mode assimilate >> Emacs as if it was the Borg and I've seen no discussions on the org list about >> ways to get org more ingrained in Emacs or make Emacs more dependent on org. >> >> With respect to ignorance, Alan made it quite clear he has not spent >> the time or effort to learn org mode, so he is ignorant about its >> operation and lacks any real understanding of its operation. He has made >> assertions about the number of key bindings which are wildly over >> inflated and about required levels of complexity which simply would not >> be necessary with the org mode rendering of a read only buffer. In >> short, he has made a lot of assumptions about both the key bindings and >> complexity based on only a fairly cursory scan of the manual and very >> limited experience. >> >> All that appears to have occurred here is that someone noted that packages often >> had a readme.org file and wondered if this should be translated into just a >> plain readme file. Someone else suggested we could have package descriptions >> render the readme.org file using org and not require export into plain readme >> file and mentioned some possible advantages this could have wrt navigation, >> rendering of tables, links and images or inclusion of source code snippets, >> examples etc. >> >> >From this point, some somewhat extreme claims and arguments have been thrown in. >> One was Alan's claim that org would introduce 785 new key bindings, many of >> which not bounmd to C-c and which would presumably either pollute the key space >> or conflict with existing bindings. All I have done is point out this claim was >> inaccurate and overstated due to an overly simplistic analysis of what is in the >> key index of the org manual. >> >> it should be noted that if we were to add 'native' rendering of readme.org >> files, this would likely be done with an org minor mode rather than a full blown >> org mode as very little of the overall org functionality would be required in >> this situation. All that would be required is org rendering support and org >> support for navigation (folding/unfolding, following links and possibly >> list/table navigation). All the advanced org functionality relating to babel, >> noweb, todo and time management, agendas, etc have no relevance in this >> scenario. LIkewise, if this functionality was provided via a minor mode, it >> would also be possible for people to disable that mode and be left with just the >> readme.org file, which is just plain text and quite readable. >> >> Alan's claim was 785 additional key bindings, many of which not bound to C-c. > > The above is completely irrelevant to my questions. > >> Running Emacs wiht -q and opeing up an org file, I find the following >> >> - 236 org related key bindings - far less than 785 Of these, a number are >> - actually remapping of existing bindings, so not new ones. This leaves 208. > > ??? How is remapping "not new"? It takes some very common Emacs > commands and redirects them to different commands. E.g., 'open-line' > now does something quite different. This means the user should either > go learn what the Org commands do, or be prepared to be surprised. This are not new key bindings, they are redefinitions of existing key bindings to make them work in an org mode context in a wayu which is consistent with user expectations. They are not new in the sense of them being a key binding which did not exist prior to loading org mode. > >> I said that for a read only buffer, many of the org key bindings are not >> relevant as they relate to features which are not pertinent to a read only org >> buffer. Any bindings relating to babel, todo management, time management, >> agendas etc have no relevance when reading a readme.org file. > > Then why does Org define them in that case? > because standard org mode is not typically used in read only buffers. How org is defined now and how it would be defined/loaded when it comes to a specialised use case as discussed here are completely different. As I said in previous posts, I would expect that you would define an org minor mode which would only include the key bindings which would be appropriate for the use case of viewing a read-only org file. >> Really, the only >> key bindings of any relevance are navigation related bindings (including >> opening/closing folds, following links, etc). Removing all unnecessary org >> bindings leave us with just 77 new bindings. Of these remaining bindings, quite >> a few could also be removed, but I've left them in as I only wanted to remove >> those which would clearly be of no benefit in a read only buffer rendering of a >> readme.org file. In an org minor mode setup for rendering of readme.org (and >> possibly other read-only rendering of org files), I estimate at least another 30 >> bindings could be removed because they have no real benefit or are of only >> marginal benefit. Creating an org minor mode for this purpose which only >> introduced 20 or so new bindings would easily be possible. The key point is that >> claims of 785 new bindings arfe incorrect and misleading. Even being very >> conservative, we are really talking about 10% of the number being incorrectly claimed. >> if we introduced a minor mode for this, we are talking likely less than 20 or so. > > I'm sorry, but IMO this hand-waves away a real problem by ignoring the > problematic UX of suddenly having more than 200 keybindings defined > just because I visited a small file. I hoped you will present some > serious analysis of the issue, and perhaps even show me where I'm > wrong in my conclusions. Sadly, it sounds like all you wanted to do > is to prove that you are right, the facts notwithstanding. Sorry, but it seems you are the one trying to drag this off into a different argument about whether org mode is too large or defines too much or loads too much. As stated multiple times in my previous posts in this thread, should org mode be used in the context being discussed, you would define a new org minor mode whic only included the functionality and key bindings relevant for this use case. You would not just use a full org mode for this situation. > > You accuse Alan in extremism, but your own argumentation is another > example of a similar extremism -- just in the opposite direction. > I have never said that 200 key bindings wasn't a lot. All I've said is that 200 key bindings is a LOT less than the 784 being claimed. I went further to state that in a specialised read-only org mode, you would be able to reduce that number to around 50 or possibly even fewer. I also reject what was stated about the org mode key bindings polluting the global key space. I find no evidence of such pollution and in fact believe org mode is very good at not doing so. I find very few (if any) examples of org doing global key binding and in fact have to define new personal bindings when I want global access to org functionality (such as org capture or the org agenda). > This doesn't facilitate useful discussions of what I think is a real > problem. Any unbiased observer should agree that adding 200+ key > bindings when a small file is visited is a problem that needs to be > solved. Org is too large for such simple jobs, and should be > refactored to avoid loading everything under the sun when a README is > visited. And we should work towards solving it, not sweep it under > the carpet. > which is exactly why I was saying that should you want org rendering of small read only files, you would create an org minor mode which only loaded the functionality and key bindings that would be relevant in that context. It is only you who are assuming that a full org mode would be used in this context. Nobody has tried to sweep anything under the carpet. Right back in my very 1st post to this thread, I stated that should org be used to render content in things like a help buffer or package description whhich would presumably be a read only presentation, you would want an org minor mode which only loads the functionality, including appropriate key bindings which made sense in that context. This sentiment was also mirrored by others in the thread. . Questions about general org mode and whether it defines too many key bindings or too many features when loaded is a completely separate question. While there could be some important discussion which needs to happen in that context, it has little to do with what was being discussed here and even less relevance to what I was saying, whihc was that claiming opening an org file would define 784 new key bindings and would pollute the key space was an exaggeration and over statement of what happens when you open an org file. Even your own example confirmed this. As to whether defining 200 key bindings is too many - well I don't think you can possibly say either way without significantly more analysis. It also isn't at all given that adding 200 new key bindings in a new mode is of itself problematic. There could be very good reasons to add that many bindings. Besides, I'm not sure it even is a problem. Emacs has lots of key bindings - the vast majority of which I never use. I don't find this a problem and I'm not convinced just citing absolute binding numbers in itself is evidence of a problem.