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: Mon, 06 Jun 2022 23:57:55 +1000 Message-ID: <87bkv527p5.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40210"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.26; emacs 28.1.50 Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 06 16:28:44 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 1nyDil-000ABo-ON for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 16:28:43 +0200 Original-Received: from localhost ([::1]:48204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyDik-0006gN-Fu for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 10:28:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46986) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyDcJ-0008Cv-Qx for emacs-devel@gnu.org; Mon, 06 Jun 2022 10:22:03 -0400 Original-Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:41503) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nyDcF-0005sB-60 for emacs-devel@gnu.org; Mon, 06 Jun 2022 10:22:03 -0400 Original-Received: by mail-pl1-x634.google.com with SMTP id s14so12217681plk.8 for ; Mon, 06 Jun 2022 07:21:58 -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=QlcfpiKP5vvpzn+LW+esls9JYGLYQEOpUFl0Aqj6B2Q=; b=D2eKZHFrAhxe1l3SiAB04Av1IXhrTkMEUEc8woPGyoSGT7mYDwwVPh6mLNGcyZh4s9 9mcp5i18Quk3hrBNS0qdW9UgoFPgod3jQ/k7fYajQlPFQgyNeSO+161FMbIavsMGLaRs xKQ07vmLvtOM9UMK/MWpAvmmbYBNf3mOui4c69p28wZjG5HneMpo23K1Cgxl/CnrUaNf Cx11JNbZ6ZCcGzSNGbVuMbwtOhwi15khS5n3huX7podoZkPUe7+tJyhR5BHsj8EMUNmk zzyc/KFxi7QRAcHbDbKBJxKptpQltRbwHqg5YloByAdEY0wTQSHdVm0Pa6pIN5Ad3Een x4/w== 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=QlcfpiKP5vvpzn+LW+esls9JYGLYQEOpUFl0Aqj6B2Q=; b=4lnKkmopuIkOKv47lpqgW4AgCMuu0WBu7fM+fLmdp+E5S5X2ZmfLXrSxE5n/OXiVT2 EKDZtTrl0UF2bFkAcOxMhuer4wtOEMcKaruzyZqAdTrGylyuyrJU9kSPELwlBbWl6vb5 am5nnDOK5flJSwYb4MxS2a6wGK+KxcUnl8Eh7h8Xn8R+Aid3HJyAYJ564NUQm3RYhHOn Z+ZNgFQfjTxjsvkqm1pmo0WMoSzSwide62zza2y7YGw3ANm8RxzjOqovp+bAkb1S0RRf gPT4Xj3MCepYivnns0KEjNO3yfJM82GNDFItaUGERh+8xTDyl23pmjs/9bPJzQ0++oUa 6NjA== X-Gm-Message-State: AOAM530Jlw7BV8dqm+lDX5yoVBPjf/jK+A5OpqKXm7S2fk1Kf3rvItj1 Gncu+W5ilBnJe8wPhlrn/mH2z8fUCDI= X-Google-Smtp-Source: ABdhPJyN0pdu/jJ7GJR7X6gWaeqlLEhjEoWuvuj5LwgSLGeQjF9XOKieMAju3UuX3BSLAfhQzDQc6w== X-Received: by 2002:a17:903:2308:b0:167:6bfe:a800 with SMTP id d8-20020a170903230800b001676bfea800mr10195042plh.100.1654525317542; Mon, 06 Jun 2022 07:21:57 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-5d8f-7b1e-3301-0fed.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:5d8f:7b1e:3301:fed]) by smtp.gmail.com with ESMTPSA id p24-20020a170903249800b00161455d8029sm10449813plw.12.2022.06.06.07.21.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 07:21:57 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::634; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x634.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:290800 Archived-At: Alan Mackenzie writes: > Hello, Tim. > > On Mon, Jun 06, 2022 at 10:19:38 +1000, Tim Cross wrote: > >> Michael Albinus writes: > > >> > I have no problem if there are structured README.org or README.md >> > files in parallel. But a README file should be plain text. > > I agree with this. > >> I've seen this mentioned multiple times in this thread and it doesn't >> make sense to me. > >> Org files *are* plain text. This is one of (perhaps the biggest) selling >> points for org mode. They don't use any form of 'binary' data and can be >> read just fine in any text editor or just using cat/less/more whatever. > > We're reduced to arguing about the meaning of "plain text". The way I > see it, plain text means to be read as is by the user. In that sense, > the formats you mention below, xml, html, etc. are _not_ plain text - > they're designed for machine processing. A typical spam email in HTML > has the human readable pieces swamped by the machine readable pieces. I > think you're arguing that this isn't the case with org mode files, though > Philip Kaludercic pointed out an org file where this wasn't the case. > Philip's example is an extreme case and not representative of normal README.org files. >> They may look a little *ugly*, especially with respect to URLs, but are >> still quite readable - a lot more readable than other plain text formats >> such as xml or html or json etc. > > And their performance in standard programs like grep, wc, etc. is that > much worse than plain text. No, I disagree with this completely. Org mode markup is very simple and rarely has any impact with regards to grep, ag or any other 'shell' tool It is precisely why I consider it to be a plain text format - all of these standard plain trext processing tools work in the main just as well as they do on any ASCII file. Again, org mode is not like XML or HTML or other formats which do make such processing difficult. > >> I also find arguments based around org being complex and difficult to >> learn to be somewhat overstated. > > 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 yhou 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). >> Org is powerful and very configurable, .... > > That contradicts your previous statement to some extent. Any program > which is very configurable _needs_ to be configured. > ABsolute nonsense. Just because you can configure somethig doesn't automatically mean you have to configure it. Emacs is extremely configurable, but you can use it jsut fine without doing any configuration at all. >> .... which means there can be a lot to learn if you want to leverage >> off all it has to offer. > > I don't want to do this. I want to avoid org mode being loaded into my > Emacs; it fouls up my key bindings to a significant extent. Particularly > if I just want to read a 50 line README. > Other posts have already explained this is NOT what is being proposed and that it would not affect your key bindings in the slightest. All that is being propsoed here is that a read only buffer will use org mode to format/display the content. Very simple and not the monster you insist. >> However, like emacs, the basics are very simple and easy to learn. > > I don't agree that the basics of Emacs are simple and easy to learn at > all. That's a strong reason why other editors have become popular. Why > should I have to spend time learning a super-complicated mode just to > read a 50 line README? > Well, basically, you don't. That has already bene explained and does not need to be reitterated here. However, to be clear, all that is being proposed is that org formatting is applied to the contgents of this read-only buffer. There will not be huge numbers of unwanted/unexptrected key bindings and there won't be a huge number of other changes. You will likely have some additional key bindings which may make navigating larger README files easier and that is about it. All that is really being proposed here is org font locking and outline mode navigation. All very simple really. >> While I'm not arguing that org should be forced upon everyone .... > > If a README file is README.org, then org mode is forced upon anybody > wishing to read it in Emacs. This is why README files should be plain > text. > >> .... and I would agree we need to keep potential load time issues in >> mind, there seems to be lots in this thread over stating the issues and >> jumping to extremes. > > I think org mode is an extreme, with its 784 key bindings which seem to > violate written and unwritten conventions. That 750 key bindings is an extreme over statement and not what is being proposed. Yet again, people jumping to extremes based on ignorance and paranoia. Spend the time to go through the key bindings listed in the org manual and you will soon realise that the majority of those bindings only come into effect in specialised mdoes - none of which are relevant to a READM.org ile (for example, all the key bindings relating to agenda mode). I find it odd that someone can on one hand argue so hard against using a mode based on the complexity and vast nubmer of key bindings and at the same time admit they have never spent the time to learn the mode. This seems like an arguument based on fear and uncertainty about something you don't know rather thaa one based on fact. Perhaps look more closely at what was actually being proposed (which was not a full org mode situation) and spend enough time to at least udnerstand the basics before condemnation. > >> All that seems to really be under consideration is to enable rendering >> of *org files in help buffers using org font locking and perhaps >> enabling folding, which could be very beneficial for large readme files >> and would not matter for small ones. I also suspect this is something >> which could be disabled with a simple variable setting for those who >> really don't like it. > > "It" could best be avoided by having plain text README files.