[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] org mode moves to GNU emacs core
From: |
Uwe Brauer |
Subject: |
Re: [O] org mode moves to GNU emacs core |
Date: |
Mon, 03 Jul 2017 14:21:05 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
>>> "qTim" == qTim Cross <address@hidden> 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
Message not available
Message not available