From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Fri, 17 Jun 2022 09:40:17 +0300 Message-ID: <83ilozpzce.fsf@gnu.org> References: <87leuca7v7.fsf@disroot.org> <87o7z61v59.fsf@gmail.com> <87bkv527p5.fsf@gmail.com> <835yld93w7.fsf@gnu.org> <877d5t0yrn.fsf@gmail.com> <83o7z47m7y.fsf@gnu.org> <8735gfs3is.fsf@localhost> <838rq75jhg.fsf@gnu.org> <87fskfqj97.fsf@localhost> <83zgin3zcm.fsf@gnu.org> <87fskei4fa.fsf@localhost> <831qvy41oj.fsf@gnu.org> <87tu8rq2l6.fsf@localhost> <83czffzo73.fsf@gnu.org> <87a6aiqnpc.fsf@localhost> <831qvuw98i.fsf@gnu.org> <87wndmp63n.fsf@localhost> <83sfoaurqk.fsf@gnu.org> <87tu8mv79u.fsf@localhost> <83czfart19.fsf@gnu.org> <87v8szrfz6.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9003"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 17 08:44:24 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 1o25iS-00028b-AW for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 08:44:24 +0200 Original-Received: from localhost ([::1]:49122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o25iQ-00015C-TC for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 02:44:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o25eZ-0007N0-A8 for emacs-devel@gnu.org; Fri, 17 Jun 2022 02:40:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57454) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o25eY-0008RC-Go; Fri, 17 Jun 2022 02:40:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jPzDz0zzvUX0fLRRnoC3QiQzstbydEHnx9Nt30dstDs=; b=OnV0qJ9H2sHt bjJw50trPSRh9CAJDftr5kEzgZdEwgxFoTTYISPc0dN6t4erembaNOiddIaKsRHVlWgdniLeI9Hk5 6+yfiF4ZYSTIT/w/E0tdzqeXh1F4CexEIEEpGBqN7pMcgwL5M5ovqxw9Kcm7uXn2ndb3hghEbudgW qQrLJVtl9ud7uPeOa4Umjqk2k87PMQfsmM2jRk3a3HvoY32lQED2j7rOX2gUcPcgKrO2t8PUO4ON3 Z0bHxxw5x21/GZJ9ogfYt4ywZJsssvrY3ruSSwNfTNVYUsBPuMsPfZEOKzH4/Cj3BnuFVMZR0KZDd YsoHPbvS4/kSigD0JM14wg==; Original-Received: from [87.69.77.57] (port=4660 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o25eX-0000bJ-Vf; Fri, 17 Jun 2022 02:40:22 -0400 In-Reply-To: <87v8szrfz6.fsf@localhost> (message from Ihor Radchenko on Fri, 17 Jun 2022 13:55:41 +0800) 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:291273 Archived-At: > From: Ihor Radchenko > Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org > Date: Fri, 17 Jun 2022 13:55:41 +0800 > > > So Org is _unlike_ TeX mode, in that the assumption that every > > environment or markup are only used where their Org meaning is > > intended -- that assumption is not necessarily true, while it is in > > TeX. > > I think we are mis-communicating. Most probably, see below. > >> Org tables are always preceded by ^[ \t]*| > > > > That's what I remembered, and that is exactly what bothers me in the > > context of this discussion: seemingly innocent text sequences are > > interpreted by Org in some very special way, and the user doesn't > > always have good means to disable that interpretation when it is not > > intended. > > I do not think that Org will support major user changes in Org syntax > any time soon or in future. At least, there is no intention to guarantee > such support. > > I am not sure why you consider using pre-defined markup constructs as > "innocent". It is problematic in any kind of markup language, be it Org, > markdown, texinfo, or anything else. Neither of the other markup modes is being proposed for viewing and editing documents that were not originally edited under those modes. By contrast, there's a fraction of Emacs contributors and developers who repeatedly suggest to use Org for documents that were not originally written in Org. A notable example (not the only one) is recent discussions of turning on Org when visiting NEWS files. If you think these ideas are problematic from the POV of Org developers, please voice this opinion whenever such proposals are brought up. Those proposals, and in general the proposals to use Org widely in unrelated contexts, is what I had in mind all the time in this discussion. Perhaps now you can better understand some of my comments and responses. For example, what is your opinion of using Org markup in email messages? There are a lot of examples of that, both here and on the bug tracker. People use Org markup and Org-style code blocks quite a lot, and reading that is always jarring to me. For some reason, people assume that I read my email in Org mode or some derivative of Org. > I'd say that you should not use Org on files that do not use Org syntax. See above: there are suggestions to do just that. People are proposing to use Org in many situations where Org was not originally used, and therefore the "usual" Org assumptions don't hold. > > If we want to promote Org to be used more widely and frequently, that > > would inevitably mean it will be used by Emacs users who use Org only > > infrequently, and those are the ones I'm thinking about. We should > > make it easier to use Org infrequently, by people who don't do > > everything in Org. > > I agree here. However, I am not sure how to achieve this. We can limit > Org functionality to lower the entry barrier for infrequent Org users, > yes. However, it will necessarily mean that most of frequent Org users > have to adjust their Org mode configurations - not good. > > Should we mark some of the Org commands disabled by default? Though it > would make sense to mark the whole groups of commands. Is it possible? > Is it also possible to disable commands only for users who never > customized Org? I don't know the answers. But I'd appreciate if these consequences and prerequisites of using Org in places where it wasn't used originally could be voiced when such suggestions are brought up, and by Org developers on top of that. I quite frequently opposition to such proposals is regarded as pure conservatism, so if there are valid technical reasons and problems to solve before such proposals can be considered practical, it would be good to have them part of those discussions. > This thread is raising so many issues of various levels of > criticality, generality, and validity that it is very hard to stay on > topic. Agreed. There should be a separate thread for each specific topic.