From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Mon, 27 Jun 2022 16:44:48 +0000 Message-ID: <875ykmxdhb.fsf@posteo.net> References: <87leuca7v7.fsf@disroot.org> <87h74ztshe.fsf@gmx.de> <871qw31ois.fsf@yahoo.com> <8735gj4ceo.fsf@gnu.org> <87sfojz63r.fsf@yahoo.com> <87h74z5nio.fsf@localhost> <87ilpf45mo.fsf@disroot.org> <87pmjnumzg.fsf@posteo.net> <877d5ut6z6.fsf@posteo.net> <87o7yink44.fsf@posteo.net> <87letjzppl.fsf@posteo.net> <87letjinbr.fsf@posteo.net> <87h746xw07.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38056"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Akib Azmain Turja , Ihor Radchenko , Po Lu , Tassilo Horn , Michael Albinus , Alan Mackenzie , Stefan Kangas , Emacs developers To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 27 18:47:19 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 1o5rtP-0009g4-8I for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 18:47:19 +0200 Original-Received: from localhost ([::1]:35070 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o5rtO-0002yx-04 for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 12:47:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5rrB-0000wX-1R for emacs-devel@gnu.org; Mon, 27 Jun 2022 12:45:01 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:45365) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5rr3-0006ux-R5 for emacs-devel@gnu.org; Mon, 27 Jun 2022 12:45:00 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C155E24010B for ; Mon, 27 Jun 2022 18:44:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1656348291; bh=xbNccFWfzHvUFgHi1V1YyvN2dSCpfBAJIMM5n/ebQ2c=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=bh2fqGUPD3WtXn+eya7EneGzeQo3nzShVyO98cHOkzRn90aHEt58bQy6qqPagugat EivvFxSGtBv9S5FxNCIfF8fXj7DxHbQs0bN6fKD5DGDvRJlK8x/4csfx5AfmO7NgOl ZTnil/j49hJqRLl7G12IxYnEwblEXgtJv0XwlQDfpHxym7D/WWHI1qweIoo7ffz0nn A9Y/yGWv3NKfSiTUHJL2gHRpz7xvWF7/JtwMpQ8n2eG7OoxzC5vx9NodriRs2ROP/g cAa2Zdc2M4/mvritDHdLqugqqE5+u6O/t9/7jD3enMW4dE5WVtAD1o5DiATwZr5QuY cepfncECGMBbA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4LWtqj4J3zz6tpH; Mon, 27 Jun 2022 18:44:49 +0200 (CEST) X-Hashcash: 1:20:220627:emacs-devel@gnu.org::M+vJhZs3xVsNejdk:0000000000000000000000000000000000000000000GFD X-Hashcash: 1:20:220627:yantar92@gmail.com::HewLjInqn8UcQ1lo:00000000000000000000000000000000000000000000YO+ X-Hashcash: 1:20:220627:akib@disroot.org::HGXCnMCRMGswwxi/:00LKt X-Hashcash: 1:20:220627:tsdh@gnu.org::pm9yauvUkIikGsiE:000001NJV X-Hashcash: 1:20:220627:stefan@marxist.se::mkTLufU35/FPfLIM:000000000000000000000000000000000000000000001SP6 X-Hashcash: 1:20:220627:monnier@iro.umontreal.ca::rFldYfS1Ew0Er46A:00000000000000000000000000000000000002cOB X-Hashcash: 1:20:220627:yuri.v.khan@gmail.com::wt1kntyWKSOhHaq4:00000000000000000000000000000000000000002hPf X-Hashcash: 1:20:220627:michael.albinus@gmx.de::dfqHoGE/GYgXeT7C:00000000000000000000000000000000000000041Rg X-Hashcash: 1:20:220627:acm@muc.de::dY5SxZw+TeRYwoS8:00000006umm X-Hashcash: 1:20:220627:luangruo@yahoo.com::Bw/vAXqg43O8sXEp:0000000000000000000000000000000000000000000B3Tz Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: (Yuri Khan's message of "Mon, 27 Jun 2022 21:29:47 +0700") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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:291668 Archived-At: Yuri Khan writes: > On Mon, 27 Jun 2022 at 17:05, Philip Kaludercic wrot= e: > >> > Maybe throwing out the badges would be a good first step ;-) >> >> Then again, this ties into the README files that look better when >> rendered on GitHub/Lab, and where it is worth considering if *not* >> using them would be of more use. > > Badges do not have to be ugly in markdown source. Or, at least, they > can be much less ugly. > > Let=E2=80=99s dissect [Eglot=E2=80=99s README.md][1] just as an example (= only because > it has badges; otherwise, I think Eglot=E2=80=99s README.md is as non-ugl= y as > possible): > [...] > > [![Build status][build-badge]][build] > [![GNU ELPA][elpa-badge]][elpa] > [![MELPA][melpa-badge]][melpa] > > [build]: https://github.com/joaotavora/eglot/actions/workflows/test.y= ml > [elpa]: https://elpa.gnu.org/packages/eglot.html > [melpa]: https://melpa.org/#/eglot > > [build-badge]: > https://github.com/joaotavora/eglot/actions/workflows/test.yml/badge.svg > [elpa-badge]: https://elpa.gnu.org/packages/eglot.svg > [melpa-badge]: https://melpa.org/packages/eglot-badge.svg > > Now, only one line is longer than 80 characters. > > URLs specified this way can appear anywhere in the markdown source. > Eglot=E2=80=99s README actually uses this syntax for all other (non-badge) > hyperlinks and puts URLs at the bottom. I get the impression that this trades horizontally wasted space for vertically wasted space (setting aside that by reordering the URLs they don't have to appear in the middle of the document). The issue here is that in the plain-text buffer that C-h P provides, the badges are simply always redundant, so either they should somehow be handled by the *Help* buffer, removed from the buffer or (as I argue) we should not display the README that is usually targeted at a different audience, and instead recommend to write clean, brief, informative commentary sections in the main files.