From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: Differences between Org-Mode and Hyperbole Date: Sat, 02 Jul 2016 11:13:50 +0200 Organization: Linux Private Site Message-ID: <87poqwpfld.fsf@Rainer.invalid> References: <87h9cdmj6t.fsf@delle7240.chemeng.ucl.ac.uk> <5775A512.4020803@gmail.com> <8337ntvm2d.fsf@gnu.org> <5776B89F.60704@gmail.com> <83k2h5tbtv.fsf@gnu.org> <5776E1F4.3020709@gmail.com> <83eg7ctt90.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1467450891 19111 80.91.229.3 (2 Jul 2016 09:14:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jul 2016 09:14:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 02 11:14:42 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bJH0b-0001kO-0j for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2016 11:14:41 +0200 Original-Received: from localhost ([::1]:37492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJH0Z-0001yo-S3 for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2016 05:14:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJGzz-0001yX-PM for emacs-devel@gnu.org; Sat, 02 Jul 2016 05:14:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJGzv-0004PK-IQ for emacs-devel@gnu.org; Sat, 02 Jul 2016 05:14:02 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:54628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJGzv-0004PA-7e for emacs-devel@gnu.org; Sat, 02 Jul 2016 05:13:59 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bJGzs-0001Gh-Gq for emacs-devel@gnu.org; Sat, 02 Jul 2016 11:13:56 +0200 Original-Received: from p54b478af.dip0.t-ipconnect.de ([84.180.120.175]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Jul 2016 11:13:56 +0200 Original-Received: from Stromeko by p54b478af.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Jul 2016 11:13:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 98 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p54b478af.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:J/pURGPZXNkICRlOXVP4YBYacJk= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205081 Archived-At: Eli Zaretskii writes: > It [Org] includes several features that are very loosely coupled. The coupling of these features is via Org the document format, not Org the major mode. This document format used to be whatever Org chose to interpret some piece of text as, but is now more formally specified and the implemented as a parser (org-element) in elisp. There are probably still parts of Org that work directly on the text, but they're on the way out. > E.g., what does spreadsheet-like table have to do with > outline-structured notes? That people writing an outline expect the ability to include tables without needing to get out of the document they're editing? That it's vastly easier to maintain these tables when you can do the calculations right there? BTW, org-table uses Calc and there's enough of an API to use it from outside Org if you wanted to. In fact, if anybody really wants to separate out something from Org, then the spreadsheet is a pretty obvious candidate. Keeping a separate spreadsheet working from within Org will be a non-trivial exercise, though. > What does the ability to embed source code in several programming > languages has to do with diary features? See above. Again, these are provided by Org because that's what users expect to do from within their Org documents. It doesn't prescribe implementation within Org. > Sure, we can come up with use cases where it makes sense to use these > features together in the same file, but I think use cases where they > are unrelated are much more abundant. Cases of using a computer that do not involve the Emacs are also abundant, I hope you agree that this as not an argument against Emacs. […] > Once again, this is explicitly NOT about the user POV. It is beyond > any argument that Org is a very successful package, as far as its > users are concerned. So let's not bring this issue into this > discussion, it is not relevant here. Then why do keep mentioning use cases and features, which are inherently user-centric? It should tell you something that you are unable to keep the discussion going without resorting to user issues and indeed I think you shouldn't be trying. Emacs is about users getting things done first and about Emacs developers spending their time efficiently second. > Btw, it might be relevant to point out that quite a few features > originally provided by Gnus were over the years refactored into > separate Emacs packages, and are nowadays available in general-purpose > subdirectories, like lisp/net, lisp/mail, and others. Perhaps the > most prominent example is Message mode, which was several years ago > made the default Emacs mail composing mode. This tendency continues > with Gnus to this day. My interpretation of that is that Gnus, too, > had/has some features included that shouldn't have been there in the > first place _as_part_of_Gnus_. Hindsight is 20/20. I could claim plausibly enough that separating message out from GNUS from the outset would have stalled development of both Gnus and message. But in fact both these interpretations are unprovable and of questionable utility to the future of different packages already in Emacs like Org or new ones coming in like Hyperbole. […] > As I said already several times, there's no "digging" here. This is a > discussion about design principles of large Emacs packages. I've yet to see that discussion starting. Emacs would need a way to specify API, indicate various degrees to indicate whether they are internal or external or how stable they can expected to be and backwards compatibility to the public API of at least the immediately prior major API version before the componentization of Emacs as alluded to in this thread can take off on a larger scale. > Well, here's where we disagree. Tight integration of unrelated > features is not a good thing, IMO, since it makes learning each one > harder, and it makes maintenance more vulnerable to a loss of a single > central individual who knows all the ins and outs. More user POV, which you said was irrelevant. Just because one file has an "org-" prefix doesn't necessarily mean "tight integration" in the design principles sense either. I personally don't use the agenda for instance and the fact that org-agenda.el exists is irrelevant to my daily work. Org doesn't care much either, it could just as well import some Emacs facility in that same place if one was existing. Despite allusions to the contrary, org-agenda also doesn't replace existing Emacs facilities, most of it is customization and UI, but the bulk work is done via calendar. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html