From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Tue, 07 Jun 2022 08:46:37 +0200 Message-ID: <87czflas36.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> <87bkv527p5.fsf@gmail.com> <87k09ttiad.fsf@yahoo.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="36825"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Tim Cross , Alan Mackenzie , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 07 08:58:34 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 1nyTAf-0009Js-1H for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Jun 2022 08:58:33 +0200 Original-Received: from localhost ([::1]:33974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyTAd-0007ie-R3 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Jun 2022 02:58:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nySzD-00005w-AA for emacs-devel@gnu.org; Tue, 07 Jun 2022 02:46:44 -0400 Original-Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:38873) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nySzB-0003tN-JV for emacs-devel@gnu.org; Tue, 07 Jun 2022 02:46:43 -0400 Original-Received: by mail-wr1-x431.google.com with SMTP id q7so22694525wrg.5 for ; Mon, 06 Jun 2022 23:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=x6giAMlRg2raGG1nnbBC6WalEhew7dqzI38QP3NmsTo=; b=QrbemjWbk3vD8NJEaLD7bTfarIFZOmHS9641xMi8+7FrjamY569H2Z2iAZ/KLT+f8B WO8EJjui3d0+59mGPUfnmyYlBY//PD6ZL4Gs33f44DVXDs18k+b3kHbRegjpnZikBCY2 hYGmqGgt5wy4Vqczc7v2qULSgqCgldRhBKfszTC6XyYX2vOLEgrb8YFzJpnMWlWAasHL rZ78vVv12mMbKpx4j0p9KTmvwZVE90jJnoIFQQcJ78voIq4D5GX3qKHDOyXpsFvvh/L9 c37MwWJ1lo7FlABVtr2YQcMNiv4Xu9JMOoLHZ2HeYGQWukiJbvE1aSX2FwxXHoBdhrxo MWPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=x6giAMlRg2raGG1nnbBC6WalEhew7dqzI38QP3NmsTo=; b=k9HHHzKTcAqTjjuw4tWH0DemRorXLlPy1dQpt4x1ffYGThBaCsy5JGl8PmEr7lJl+P LyS9K2kkQieIsj6rol/dksjMBI5yjBibf4C56TDG4QIc/qpzBVBWpo5+lG/h1kAxgjst K6jg9aTu1TtMjG8IX//NEHlzb4Ub1EVH8Tog4YlPQemnsNfEWEU3OCWXUlGD/OFKm0Gi 0FcFUIgJmKmuatftr3ERFbi6f22o/xNNpBrMRSo13gIorluWa7sx/uL6KoaSY5p4hWZR wxTZb1Z6XsxNCidqqhcEwhW2TnsPL/FnBH1QUEgpineFro1xugre5AdOJp6BB+CZsr9+ NcNw== X-Gm-Message-State: AOAM533KVdpmUYJs6iE7F4dy6igwGgTcIOsjV5Zqr+MuBjqjb7xGXCNz 0CwF7bULvjxLuSeHwFZHLv7XTLH7S28= X-Google-Smtp-Source: ABdhPJytLKER0uEb/NttX0iqfys9Q37acklE1YYulT9PRjOxES+1/llXmdTvyKLFutfb/rVrf/WAlQ== X-Received: by 2002:a5d:6483:0:b0:20f:d046:6382 with SMTP id o3-20020a5d6483000000b0020fd0466382mr25642302wri.342.1654584399282; Mon, 06 Jun 2022 23:46:39 -0700 (PDT) Original-Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id a4-20020a5d5084000000b002102f2fac37sm17284698wrt.51.2022.06.06.23.46.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 23:46:38 -0700 (PDT) In-Reply-To: <87k09ttiad.fsf@yahoo.com> (Po Lu's message of "Tue, 07 Jun 2022 08:43:22 +0800") Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=kevin.legouguec@gmail.com; helo=mail-wr1-x431.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:290827 Archived-At: Po Lu writes: > Tim Cross writes: > >> 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. > > What's more odd is expecting someone to go through the entire Org manual > in order to write and edit README files. This thread has been a bit disheartening to read from the sidelines; as much as I empathize with wanting to keep Emacs accessible by avoiding code bloat and keeping cognitive load low, it is hard to know what to reply to statements such as this one. No one has ever had to "go through the entire Org manual in order to write and edit README files". Just like no one has ever had to read the Emacs manual cover-to-cover in order to do anything with it (they _can_, of course, but they don't _have to_). My first years with Org were spent using (1) TAB folding (2) outline navigation commands, and that's it. We already have *Help* commands which combine those features on the development branch: see C-h b with the recently added describe-bindings-outline user option. I don't see how enabling these section-folding and navigation features could hurt the accessibility of package READMEs written in a structured format. Alan rightly points out that Org overreaches with unhelpful key bindings, and the benchmarks posted earlier show that loading Org wholesale for displaying READMEs would be irksome; to me that merely suggests that whatever subset of Org features we find relevant for _consulting_ READMEs should be better modularized. So I would expect the discussion to focus on: (1) what this subset should be (e.g. should it include font-locking), (2) whether we want to add "escape hatches" for whoever struggles with those "rich" READMEs. E.g. a package-show-plain-readmes option, which could do any number of things depending on the underlying markup format. For Org specifically, it could pass the README through the (ill-named, and not limited to ASCII) org-ascii-export-as-ascii, which converts Org markup to something more appropriate for font-lock-less viewing (sections underlined with equals and hyphens; inline links moved to their own paragraphs). It might even make sense for (Non)GNU ELPA to automatically run that function on Org READMEs in order to ensure the "bare" variant is always instantly available to package users. Instead it feels like a lot of words are spent on (1) Org is bloated and complex: yes, agreed, (2) Package maintainers should give users the courtesy of maintaining two READMEs: no, I don't see a universe where that will fly. I hope at the end of all this, we can find some middle ground between maintainers who happen to find their productivity increased by using Org, and maintainers who cringe at every cycle their CPU spends on Org code. I believe this middle ground exists.