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: Mon, 6 Jun 2022 11:33:14 +0000 Message-ID: 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; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19095"; 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 Mon Jun 06 13:34:23 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 1nyB02-0004kQ-NH for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 13:34:22 +0200 Original-Received: from localhost ([::1]:50424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyB01-0002EP-J1 for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 07:34:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38350) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyAz2-0001X8-RT for emacs-devel@gnu.org; Mon, 06 Jun 2022 07:33:20 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:46784 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nyAz0-00013P-Ds for emacs-devel@gnu.org; Mon, 06 Jun 2022 07:33:20 -0400 Original-Received: (qmail 23051 invoked by uid 3782); 6 Jun 2022 11:33:15 -0000 Original-Received: from acm.muc.de (p4fe15747.dip0.t-ipconnect.de [79.225.87.71]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 06 Jun 2022 13:33:15 +0200 Original-Received: (qmail 3770 invoked by uid 1000); 6 Jun 2022 11:33:14 -0000 Content-Disposition: inline In-Reply-To: <87o7z61v59.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:290782 Archived-At: 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. > 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. > 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? > Org is powerful and very configurable, .... That contradicts your previous statement to some extent. Any program which is very configurable _needs_ to be configured. > .... 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. > 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? > 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. > 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. -- Alan Mackenzie (Nuremberg, Germany).