From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Convert README.org to plain text README while installing package Date: Fri, 17 Jun 2022 13:55:41 +0800 Message-ID: <87v8szrfz6.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27872"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 17 07:56:41 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 1o24yF-00072R-Rt for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 07:56:39 +0200 Original-Received: from localhost ([::1]:50712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o24yE-0005np-C3 for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 01:56:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o24wJ-0004sN-Pl for emacs-devel@gnu.org; Fri, 17 Jun 2022 01:54:39 -0400 Original-Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]:44943) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o24wH-00054X-AQ; Fri, 17 Jun 2022 01:54:39 -0400 Original-Received: by mail-pl1-x630.google.com with SMTP id h1so3018170plf.11; Thu, 16 Jun 2022 22:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Q5uCObPNj14i4VaoHwEM53R+9JYaCpqYqDlqja4Alzw=; b=ZmY5HnVS0TQRloDAopsYJmndzRe2MBt1uKZ7AIct6LD/ZYvfF24GZICG6KxtzUB2wT Kc/fWqMNTxRJERYnbWgZ1Ja2UtMRQwM7RnPFffLC/3h4nNn8jQcOHJayz7HayrYBbcLh DQQkjuVuPRiJ5iclOHHE0Bb2W64qi++CfAjD8nx05/l7uP9qWN5G2fyUVgD7/XMfDdlY GckzyNy/iCuuqY08QwD1v5FkJTGaiUlXUNKJkwIOUSNWvSO0Goz56aDw5LHEsE6DbZFq CY4czpRanwkkbH3Z3DzHiwo/tNRtHkRlI9+Y1D06180UNKYJco5Nl94gqCZ7nWi8PWFV 1g9w== 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:in-reply-to:references:date :message-id:mime-version; bh=Q5uCObPNj14i4VaoHwEM53R+9JYaCpqYqDlqja4Alzw=; b=2Trgk8zG7XlMNZsQvZnY/47kqewi6jJ9h1z7Iybp6B1Dia5iZm38knPfn2B1/2hi3H g6LF4XEg7Vd11F1lnfhcNG+ho1gVe11wK8TYi31y92Un/6yTUf8hCtO74cK1yiouyByf swfdeLGTtcnwGMpoQJ/WpZtjxawwb1hhLDD4VLdxDTPTMPHdplroIV1Cpu+GS0hi/ZS8 /KwHaIE0YC8Lr/UtncubgJ2XyEgD89OILQD7LpCDyZ2+5UIMXEMUwhKR6L0P2KPSBIAr DVukw9+tv/GEcVE82jzDjB73R2eDuNKguyeKe0n+ng302jNuuoZnNvSa7ddf+4ImVL3e v0Jg== X-Gm-Message-State: AJIora/JiIczH+RBq9FpWbDQXg6YvcWtBVbdlbVU7wFtJ2Xx74PGpwf5 v9eMjAcdQkLKkZoWndkQPDWlneYp3Y0i5tzG X-Google-Smtp-Source: AGRyM1tQg0+/ynO8KLZzKEa2K+HH3bPiXVqNxekPolphb7DttZa4zfO5SYpfy1/3LjArm/79BxutUg== X-Received: by 2002:a17:902:f708:b0:153:839f:bf2c with SMTP id h8-20020a170902f70800b00153839fbf2cmr8231352plo.113.1655445274169; Thu, 16 Jun 2022 22:54:34 -0700 (PDT) Original-Received: from localhost ([66.154.105.4]) by smtp.gmail.com with ESMTPSA id l4-20020a170903120400b001638a171558sm2619707plh.202.2022.06.16.22.54.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jun 2022 22:54:33 -0700 (PDT) In-Reply-To: <83czfart19.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::630; envelope-from=yantar92@gmail.com; helo=mail-pl1-x630.google.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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:291268 Archived-At: Eli Zaretskii writes: >> Not exactly. We have to keep backwards compatibility and keep in mind >> external packages. So, syntax changes in Org must be avoided unless >> strictly necessary. And they should be backwards compatible even if the >> changes are necessary. > > This is a tangent, entirely unrelated to what I said. My point was > that, unlike TeX source, which can only be submitted to TeX, and > therefore must follow TeX syntax and is written by people who are > familiar with TeX, Org is being advertised as a mode for editing > mostly-plain text. And in plain text, what Org decided to take as an > indication of a table could very well be something else, because the > user just typed plain text, and was oblivious to its meaning in Org. > > 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. Org mode is not just a major mode, it is a markup language. org-mode in Emacs is a mode for editing documents written using Org markup. The markup is fixed with tables being a part of it. Altering the markup rules is not currently supported for technical reasons (specific Org markup is not parameterized in various places in the code-base; though efforts to modulate everything, including some markup semantics, are ongoing). Note that Org markup has facilities to escape text constructs using verbatim/code or #+begin_quote/#+begin_example constructs. >> 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. >> I am not sure what is the problem here. One can just not start lines >> with | or put zero-width space if starting lines from | is absolutely >> necessary. > > Imagine a user who has no idea that a space and a | at the beginning > of a line means it's an Org table, and thus won't realize that this > magically changes how commands behave in that chunk of text. That is > the problem that was in my mind when I said that the special > table-related behavior should be better controllable and perhaps off > by default. Fontification will hint about different semantic meaning. FYI, I can blame comment-dwim for having the same problem - if user does not know about comment syntax, comment-dwim will magically change its meaning in different chunks of text. The same goes for open-line when there is fill-prefix or even not-easily-visible 'left-margin text property. >> > Relying on a user option for something that can need frequent >> > adjustment is not the best UX. defcustom is only a good solution when >> > it expresses a more-or-less constant user preference that change only >> > very rarely. If I may need to change the value before invoking a >> > command, that's inconvenient. >> >> I am not sure why you need a frequent adjustment of org-special-ctrl-o. > > If some instances of the same sequence of characters are indeed meant > to be a table, and other instances in the same file aren't, or if I > need to edit a file where they have this meaning and soon after a file > where they don't, I'd need to flip the option on and off very often. I'd say that you should not use Org on files that do not use Org syntax. If you do what to do it, you should not be surprised that the same mode behaves the same way despite you having different idea in mind. More practically, you can always use file-local variables. Or, if you think that flipping between some Emacs-global default behavior and major-mode-specific behavior is frequent or important use-case, why would you not introduce global Emacs functionality or at least convention to do exactly this? I do not understand why this very general problem is blamed on Org specifically and not on other major modes. >> > Maybe because most Org users are frequent Org users and always know >> > what they want well enough? As mentioned, I have other kind of users >> > in mind. >> >> I understand, but we have to consider the needs to majority of users, >> right? > > Majority of Org users or majority of Emacs users? > > 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? >> > Adding keybindings is a solution to a problem. I'm saying that >> > alternatives to that solution were not seriously explored fro those >> > unbundled packages. >> >> How can you tell it with confidence? > > I can, because I'm talking about what the Emacs core developers did > (or, rather, did not do). If you somehow interpreted that to allude > to the developers of the respective packages, that was not the intent. > > IOW, I'm saying that when you compare the ELPA packages to Org in > these aspects, the comparison is not really valid, because Org gets > much more attention from the core developers than the ELPA packages, > especially since there's a tendency to use Org in more situations. I get your point. However, I do not see a good solution here. Suggestions are welcome. (I'd prefer if the discussion about the principles of key binding / editing design were in a separate thread, CCing both emacs-devel and Org mode ML). This thread is raising so many issues of various levels of criticality, generality, and validity that it is very hard to stay on topic. Best, Ihor