From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Tue, 7 Jun 2022 16:02:00 +0000 Message-ID: References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8026"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 07 18:17: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 1nybt8-0001oN-Jl for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Jun 2022 18:17:02 +0200 Original-Received: from localhost ([::1]:57534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nybt7-0001dw-L0 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Jun 2022 12:17:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nybeg-0001zN-Dq for emacs-devel@gnu.org; Tue, 07 Jun 2022 12:02:06 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:36883 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nybed-0003cO-7M for emacs-devel@gnu.org; Tue, 07 Jun 2022 12:02:06 -0400 Original-Received: (qmail 11140 invoked by uid 3782); 7 Jun 2022 16:02:00 -0000 Original-Received: from acm.muc.de (p4fe15504.dip0.t-ipconnect.de [79.225.85.4]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 07 Jun 2022 18:02:00 +0200 Original-Received: (qmail 6168 invoked by uid 1000); 7 Jun 2022 16:02:00 -0000 Content-Disposition: inline In-Reply-To: <877d5t0yrn.fsf@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de 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, 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:290867 Archived-At: Hello, Tim. On Tue, Jun 07, 2022 at 16:14:52 +1000, Tim Cross wrote: > Eli Zaretskii writes: > >> From: Tim Cross > >> Cc: emacs-devel@gnu.org > >> Date: Mon, 06 Jun 2022 23:57:55 +1000 > >> > There are 784 key bindings in org mode. How can you say that this isn't > >> > complex and difficult to learn? > >> Very simply because the vast majority of those key bindings only come > >> into play when you use advanced features of org mode, such as the > >> agenda or table editing or noweb mode. If your just using basic org mode > >> features, very very few of those key bindings even come into play. Just > >> go throgh that list and remove any bindings relating to agenda mode, > >> table editing mode, source block modes, clock table mode, list editing > >> mode, etc and you end up with very few key bindings (all of which are > >> udner the C-c prefix, unlike your previous claim). > > How about if you do this exercise and walk us through the results? > > Visit an Org file, type "C-h b", then show us the list, and tell which > > bindings you think are "basic" and which are "advanced", and why you > > think so. > > 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. You've misread the situation. My objections to org mode are almost entirely due to its excessive complexity as measured by the number of key bindings. [ .... ] > 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. This is indeed the case. > He has made assertions about the number of key bindings which are > wildly over inflated ..... You have said this several times in your post without any justification. There are 784 entries in the key index in org.info. You're saying it's "wildly over inflated" to use this number, at least as a first estimate. Why are you making such a counter intuitive claim without any justification? Eli counted around 230 bindings from C-h m. It thus seems likely that on average, an org mode key sequence is used for 3½ distinct functions. This is not a good thing. > .... and about required levels of complexity which simply would not be > necessary with the org mode rendering of a read only buffer. You're not saying that loading a RO readme.org would somehow only load a small part of org mode, surely? > 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. And now you're trying to be patronising, but failing. ;-) Why do you make no attempt to explain why my assumptions are invalid? > 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. You have made an unfounded assertion of my inaccuracy. Are you suggesting, perhaps, that of these 784 entries in org.info's key index, the vast bulk are dummies? Some of these bindings (I don't think I used the word "many", but may have done) are not in the standard major mode space C-c C-. Some of these clash with existing bindings, examples of which I gave last night. > 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. In other words, an attempt would be made to fix the problems which I am drawing to people's attention. > 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. Actually it was 784, 28². Again, why is this number invalid? > 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. > 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. 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. You're describing what might be rather than what is. > The key point is that claims of 785 new bindings are incorrect and > misleading. I resent you continally repeating this unfounded assertion. There are 784 entries in org.info's key index. That is the current state. That is the truth. How can that be "incorrect"? Even if 750 of the 784 bindings somehow "don't come into play", they still exist, and are still problematic. Are you saying that only every tenth entry actually signifies an actual binding, or something like that? > 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. > Arguments regarding this being a 'slippery slope' or 'edge of the > wedge' in an org takeover are a completely different argument and there > may well be some concerns which may need to be considered. However, if > that is the real concern, then argue based on that rather than > exaggerated claims about excessive key bindings, key binding > polution/conflicts and excessive complexity. If it weren't for org mode's excessive key bindings and complexity, the "takeover scenario" would scarcely be a worry. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).