From mboxrd@z Thu Jan 1 00:00:00 1970 From: Uwe Brauer Subject: Re: org mode moves to GNU emacs core Date: Mon, 03 Jul 2017 14:21:05 +0000 Message-ID: <871spxr48e.fsf@mat.ucm.es> References: <87injf1asi.fsf@mat.ucm.es> <87r2xyvv1q.fsf@gnu.org> <87d19hrkbv.fsf@mat.ucm.es> <87zicl7uuy.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dS2E7-0005TZ-QF for emacs-orgmode@gnu.org; Mon, 03 Jul 2017 10:21:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dS2E4-0008Nw-LP for emacs-orgmode@gnu.org; Mon, 03 Jul 2017 10:21:23 -0400 Received: from [195.159.176.226] (port=52072 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dS2E4-0008Mq-Dv for emacs-orgmode@gnu.org; Mon, 03 Jul 2017 10:21:20 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dS2Dq-0001oe-Lk for emacs-orgmode@gnu.org; Mon, 03 Jul 2017 16:21:06 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org >>> "qTim" == qTim Cross writes: > Just to throw my 2 cents in. > 1. Problems with mixed versions. Currently, Emacs has org 8.x included > in the distribution. This is despite 9.x being out before the release of > 25.2. Something needs to be done to improve coordination and perhaps if > it was part of the core, this would be more likely. At any rate, the > current situation means you need to be very careful to ensure no org > feature is loaded before the ELPA package is loaded or you will get odd > behaviour and the symbol's value is void errors. > 2. If you just want to load the ELPA version of org (not > org-plus-contrib) it can be a real pain. You have to play around with > package lists to ensure you actually get the right one. This can be a > real hassle if you also use the use-package package as you will often > get the older version bundled with Emacs if you don't have your package > lists in the right order. > 3. I would really like to see two completely separate packages rather > than having org and org-plus-contrib. Currently, if you have packages > which have org as a dependency and you have loaded org-plus-contrib > rather than just org, you will end up with both. Not a big issue, unless > your on a slow link as now you will download updates for both org and > org-plus-contrib. (there is no 'cleverness' with ELPA dependency > specifications - you cannot specify alternative dependencies). But this critics could be applied to any emacs package and therefore to the package system itself. > A lot will depend on when org becomes part f core. The trick will be to > do it once development of org slows down. I've been using org for a long > time now and have noticed that the rate of new features being added has > slowed down. Much of the changes now is about improvement and refinement > of the code base. I would imagine that at some point, things will become > even more stable with fewer releases. This would be the point at which > it would make sense to bring into core. > The other advantage of being part of core is that updates and changes to > Emacs will be integrated into org much better. We won't see situations > where new versions of Emacs require a rush to update org. for the end > user, this should create a much more stable org environment. Well I update GNU emacs every 6 months it is not difficult but needs considerable longer to compile and install than org mode. > Then of course, there will always be the option to run org straight from > the git repository for those who really want the latest version. I find > that once you have the path added to load-path, running from the git > repo is not much more effort than installing the latest ELPA package. I don't see how that would possible once it is integrated in GNU emacs core, there will be no separate makefile or anything of that sort, but maybe I am missing something. Uwe