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: Thu, 9 Jun 2022 19:48:00 +0000 Message-ID: References: <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> <87ilpaevi3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9238"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 09 21:51:12 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 1nzOBU-00027t-Ar for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Jun 2022 21:51:12 +0200 Original-Received: from localhost ([::1]:42788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzOBT-0004BA-91 for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Jun 2022 15:51:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzO8r-0001gW-3k for emacs-devel@gnu.org; Thu, 09 Jun 2022 15:48:29 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61226 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nzO8i-0001aj-DY for emacs-devel@gnu.org; Thu, 09 Jun 2022 15:48:27 -0400 Original-Received: (qmail 79297 invoked by uid 3782); 9 Jun 2022 19:48:01 -0000 Original-Received: from acm.muc.de (p4fe15658.dip0.t-ipconnect.de [79.225.86.88]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 09 Jun 2022 21:48:01 +0200 Original-Received: (qmail 5599 invoked by uid 1000); 9 Jun 2022 19:48:00 -0000 Content-Disposition: inline In-Reply-To: <87ilpaevi3.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=unavailable 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:290977 Archived-At: Hello, Tim. On Thu, Jun 09, 2022 at 05:34:09 +1000, Tim Cross wrote: > Eli Zaretskii writes: [ .... ] > >> Alan's claim was 785 additional key bindings, many of which not > >> bound to C-c. It wasn't a "claim" it was a statement of fact. These 784 bindings are DOCUMENTED in org.info. You attempted to explain it away by saying, at first vaguely, that not all of them "come into play". Only later did you make that meaningful by saying that not all of them get loaded at any time. Many of these binding are not bound to C-c C- or other major mode sequences. > > 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. 236 and 784 are both good approximations to infinity when it comes to key binding numbers. Even 236 is barely manageable for anybody wanting to learn the mode in the way I would. [ .... ] > > Then why does Org define them [lots of key bindings] 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. I think the use case is that of a small org file rather than a read-only one. For some value of "small". [ .... ] > > 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. That has been the main topic of this discussion for several rounds in the thread. I've found your responses very frustrating, feeling like you've been broad brushing precise topics with vagueness, and like I'm dealing with a politician rather than a hacker. In a typical thread in this mailing list, pin-point accuracy is rare, but participants attempt to answer what the other person means rather than the precise literal meaning of what was said (sometimes getting it wrong). I don't feel this has been happening in this part of this thread. > As stated multiple times in my previous posts in this thread, .... And overbearing with it. Why? > .... 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. The context being discussed is, I think, "small" org files rather than read-only ones, whatever small means here. I think we're all agreed that full org mode is inappropriate for these. > > 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. It's not a LOT less, both being unmanageably large. > 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 > .... I find plenty of evidence in org.info. > and in fact believe org mode is very good at not doing so. Go into org.info and count up all the "new" (as you have defined it above) bindings which don't begin C-c C- or other major mode sequences. There are more of these than the total number of bindings a typical mode has. Examples: * C-c /: Sparse Trees. * M-DOWN: Structure Editing. > 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. I think Eli has experienced this. He is not "assuming" it at all. > 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. Not at all. Without org mode's massive numbers of bindings (several hundred), the question of refactoring it wouldn't even have been an issue. > 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, which was that claiming > opening an org file would define 784 new key bindings .... That was not claimed. The thing remarked upon was that there are 784 key bindings in org mode. [ .... ] > 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. Problems with it have been identified in this thread. > 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. Maybe not, but the problems are there nonetheless. -- Alan Mackenzie (Nuremberg, Germany).