From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: "Why is emacs so square?" Date: Wed, 22 Apr 2020 22:36:55 -0400 Message-ID: References: <863691n4xl.wl-me@enzu.ru> <86blno9yle.wl-me@enzu.ru> <87d0845msg.fsf@yahoo.com> <87h7xgjasw.fsf@yahoo.com> <875zdwjais.fsf@yahoo.com> <6a198677-41b6-4dbd-39d0-2b01550d53cf@yandex.ru> <32f6a2ce-e30f-059f-dcd4-233d666a10a1@yandex.ru> <87r1whiape.fsf@fastmail.fm> <87blnjopd0.fsf@nicolasgoaziou.fr> <83v9lregx0.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="93389"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, mail@nicolasgoaziou.fr, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 23 04:37:32 2020 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 1jRRk4-000OC8-Dp for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Apr 2020 04:37:32 +0200 Original-Received: from localhost ([::1]:60948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRRk3-0005Lp-Hi for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Apr 2020 22:37:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56418) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRRjV-0004ir-Ds for emacs-devel@gnu.org; Wed, 22 Apr 2020 22:36:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39136) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRRjU-0005Q4-V0; Wed, 22 Apr 2020 22:36:56 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jRRjT-0007GA-Ob; Wed, 22 Apr 2020 22:36:55 -0400 In-Reply-To: <83v9lregx0.fsf@gnu.org> (message from Eli Zaretskii on Wed, 22 Apr 2020 17:25:31 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:247558 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I have learned a lot more about Org mode from your message than I was able ever to learn before. Thank you. > This is not what a chapter about using a word processor should look > like. It should begin with an introduction to word-processing with > Org, an overview of what's possible and what isn't; it should go on to > explaining how to start a document, how to write a heading and a > sub-heading, how to insert references, links, footnotes, and other > objects; it should then explain how to produce a TOC and an index, and > finally point me to another chapter that explains how to export my > document in a variety of formats. That plan for a manual for the word-processing feature makes sense. It appears that what people call "Org mode" is a collection of diverse features, and what they have in common is use of a certain format of the text. Is that right? I have to question the practice of treating these diverse features conceptually as a single mode. Although I still don't know what those features are, if one of them is a word processor and the others are not, they are too different to make sense conceptually that way. It would make more sense to call them various different modes. That they all use a certain way of formatting the text may not be important to mention. If it is useful to have a name for that, I suggest the name "Org format". Each of these modes could say it uses "Org format", or perhaps a variation of that. > > As a consequence, it probably makes little sense to separate such > > "facilities"---the term would need to be properly defined in the current > > context, tho---, because each of them implies full support for the whole > > Org syntax. Maybe that is how things are now, but is there a reason why things SHOULD be done this way? Does each of these features need to support "the whole Org syntax"? It could be that the simple way of implementing them is by sharing code that implements "the whole Org syntax". If so, I won't argue against sharing that code. But it may not be useful to TALK about the fact that each one implements "the whole Org syntax". And it is possilble that it is better to share only part of that code, not all. In other words, if we don't let the concept of "Org mode" shape our thinking, we might thing of these features differently. > I hope I explained at least what is my view of how Org should evolve > (in addition to the routine development that adds new features) -- it > should try to present a less monolith-like appearance towards new > users, and allow them to master just a part of its capabilities, the > part that they are interested in. Hear, hear! > HTH and TIA Hold Turnip Head and Turn It Around? ;-} -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)