From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.devel Subject: Re: "Why is emacs so square?" Date: Fri, 24 Apr 2020 10:47:19 +0200 Message-ID: <87r1wdjmne.fsf@fastmail.fm> 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> <87sgguh9we.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="109822"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.1; emacs 27.0.91 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 24 10:48:47 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 1jRu0t-000STL-Oc for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Apr 2020 10:48:47 +0200 Original-Received: from localhost ([::1]:55184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRu0s-00067r-NC for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Apr 2020 04:48:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38816) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRtza-0004KN-Ug for emacs-devel@gnu.org; Fri, 24 Apr 2020 04:47:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRtza-00025r-3W for emacs-devel@gnu.org; Fri, 24 Apr 2020 04:47:26 -0400 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:55747) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jRtzZ-00024N-3Q for emacs-devel@gnu.org; Fri, 24 Apr 2020 04:47:25 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0E712E7E for ; Fri, 24 Apr 2020 04:47:21 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 24 Apr 2020 04:47:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= references:from:to:subject:in-reply-to:message-id:date :mime-version:content-type; s=fm3; bh=qGOfmdpt1ZN6+wyQnF3vFRAErE LNXI2eC+FUNjNh288=; b=vH7Hjggo84EIwBSP+VmoG70OLC5MjNEu2+Im8qiGRH LgO988Tm7oyCWojk1x4BaCmglE5uyLc6pQrH9JO52mYuq+l3eiAyCYbeGadYf7yj L3HgLrJYlPVPRDxqEdkozQD4IfSpYI9xW0+3TuA5qn2FHSViQoG5Run3Z5VwA0Zb kndb/V5SZT/0upT2qDfHb8xI8Js0K6Xf4pSfqV399+tvO4f9DUgrIt9RjK1oerXz Yjwx3NiVQrJG5eg4Pm6Wob451eQGB+Xn8djhCqnAhmvmkkM9AwNvWntFdE/F8vXm lu0EW83oBNiXXnPXiVQgM0YpiNlNERlJ5B+NDsTSjR7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qGOfmd pt1ZN6+wyQnF3vFRAErELNXI2eC+FUNjNh288=; b=nym3JbrcOWZWhr3KXg1cwm KPJK3VaJeMneK1ysY3Qv9qgq2lvX1rGU9S+e/rkAzS2ZG8BANTcRkjftBxA8YdBv Y7kr8pV0rHP0ngf+NbTaAhSXImqxWoFHLAL1VFNHeXo2WOUD6MvdhkSQ4QQMFTCm U3FnHPCU+xYAknVJVbn5fu5PluOE9gyJ7e3kxQXzrixQmU5SHKQxw6ffqYvqfW6q BLRsCGN7xnHpT4ZM7gB2/a8oZS23RfKjs44kih01XpNGL3qqJnHiVTg60OTq76vH PPJ9qwLrs8v3F5UWmXheAYPNkVFuDaCueQsQQPUL0EMSZN3NGfD5NVDfFqiynboA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedugddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfhgfhffvufgjkfffgggtsehttdertd dtredtnecuhfhrohhmpeflohhoshhtucfmrhgvmhgvrhhsuceojhhoohhsthhkrhgvmhgv rhhssehfrghsthhmrghilhdrfhhmqeenucffohhmrghinhepvgigrghmphhlvgdrohhrgh dpshihnhhtrgigrdhorhhgnecukfhppeelhedrledtrddvtddurdeivdenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhoshhtkhhrvghmvg hrshesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Original-Received: from Lenovo.fastmail.com (ip5f5ac93e.dynamic.kabel-deutschland.de [95.90.201.62]) by mail.messagingengine.com (Postfix) with ESMTPA id 28E333065D7F for ; Fri, 24 Apr 2020 04:47:21 -0400 (EDT) In-reply-to: Received-SPF: pass client-ip=64.147.123.21; envelope-from=joostkremers@fastmail.fm; helo=wout5-smtp.messagingengine.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/24 04:47:22 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.123.21 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:247673 Archived-At: On Fri, Apr 24 2020, Richard Stallman wrote: > [[[ 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. ]]] > > > Org's biggest strength > > is that the various features are tightly integrated. > > You may see that as an advantage, but I consider it a drawback. > The > "tight integration" of these different features is an obstacle > to > learning to use one of them, or even finding out about one of > them. No, it really isn't. It's just the way the current documentation is set up that makes this difficult. (I know, I agree, I've been there.) > Separate and integrated are not opposites. > It is possible for several features to be integrated, > in the sense that they work together _when you want that_, > and also separate, in the sense that we describe each one > separately > and you can learn about one without paying the slightest > attention > to the others. Again, that's all about documentation. > I can see that that integration is useful -- but _the fact that > it > applies only to "parts of Org mode"_ makes it also a a > limitation. > It is a drawback that _only_ the modes that are "part of Org > mode" can > integrate with these features -- and the rest of Emacs cannot do > so. > > Instead of dividing Emacs facilities and modes into the "Org > first-class modes" and the "Org second-class modes", we should > make > all modes equally able to integrate in these ways. That sounds good in theory, but I'm really not sure what that would mean in practice. (I'm not entirely sure that you do either. ;-) The reason Org's facilities can be so tightly integrated is because they all use the same Org syntax. Org files are just plain text files with a well-defined markup, after all. As for integrating with the rest of Emacs, any part of Emacs is free to make use of this syntax as well, Org in fact provides libraries to make this easier. For example, I maintain a package for managing .bib files. It integrates with Org in that the user can add notes to bib entries, which are kept in Org files, and the user can maintain a reading list, also as an Org file, which then integrates with the user's TODO list and calendar, if s/he so wishes. I started this package long before I ever heard of Org mode, but it was easy to add this functionality once I realised it would be useful to do so. So I believe the kind of integration you talk about is already possible, you just need to write the Elisp code to do it. In that way it doesn't differ from all the other facilities that Emacs provides: if I want to integrate Gnus and Eshell (whatever that would mean), I need to write Elisp code. This of course contrasts with the integration of the various facilities that Org provides, because that only requires knowledge of Org's syntax. But I believe that's OK and fully expected: the things Org can do are closely related and many people *need* them to integrate well with each other. So integrating them should be easy. On the other hand, what Gnus does has little to do with what Eshell does and scenarios where it would be useful to integrate them are probably rare. So it's OK that that's not so easy to do, as long as it's not impossible. > > > 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. > > > Actually, it's crucial to mention that. > > People who want to use a specific one of these facilities don't > need > to know that. Sure, but I don't think it's a big cognitive burden for them to know that. Pointing out this fact in a couple of crucial places wouldn't take more than a sentence or two, with a reference to a section where it's all explained in more detail. > It is useful for those users who want to use more > than one of these facilities together -- but that should be > an advanced topic. No, it shouldn't be billed as an advanced topic, for two reasons. First, it really isn't advanced at all: like I said, you really only need to know Org syntax in order to integrate these facilities, and you need to know Org syntax anyway to be able to use just one facility. Second, the tight integration is one of the reasons people are attracted to Org mode in the first place, so it's likely something people will look for in a manual early on. Anyway, I think this subthread is slowly getting out of hand. :-) I don't believe our positions are as far apart as the discussion might suggest. I do agree with you and Eli that it would be very helpful if the Org manual were structured along the lines Eli suggested. I envisage an introductory section that clearly states the different use cases of Org and directs the reader to separate sections for each of them, which should all be written from the point of view of a new user, i.e., they shouldn't assume familiarity with any of the other use cases. At the same time, the introduction should mention Org's integrative nature and point the reader to relevant section(s), without labelling these as "advanced". Whether and to what extent the Org code base should be modified, I'm not qualified to say, but given the limited resources, it isn't likely to happen anyway. Improving the documentation would be a much better investment of time. -- Joost Kremers Life has its moments