From: Tim Cross <theophilusx@gmail.com>
To: Uwe Brauer <oub@mat.ucm.es>
Cc: emacs-orgmode@gnu.org
Subject: Re: org mode moves to GNU emacs core
Date: Tue, 04 Jul 2017 08:13:50 +1000 [thread overview]
Message-ID: <87h8ytxj6p.fsf@gmail.com> (raw)
In-Reply-To: <871spxr48e.fsf@mat.ucm.es>
Uwe Brauer writes:
>>>> "qTim" == qTim Cross <theophilusx@gmail.com> 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.
>
Yes. It is a weakness of the package system not org. However, while I
have quite a few packages installed, org is the only one where I have
two versions installed at once.
> > 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.
>
I use to do that - actually, probably even more frequently. I still run
from my own build rather than distribution versions because they are
even further behind (generally). However, these days, I just run the
most recent Emacs release i.e. now 25.2
> > 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.
>
There is going to have to be a way for people to maintain and build org
independently. When you are maintaining Emacs, you don't want to have to
re-build the whole system every time you create a change. What you tend
to find is there are multiple Makefiles with a top level Emacs makefile
which calls sub-level makefiles as part of the build. It may be
necessary to modify configure or add a new option to build outside the
emacs tree, but that shouldn't be too difficult.
I should emphasise that while I agree org would be good as part of
Emacs' core, I don't think this should occur until org change velocity
has stabilised to a point where change velocity is lower than it is
now. At that point, there will be much less need to be running the most
recent snapshot.
Maybe my experience is very different. However, I found a lot more
motivation to go from org 7.x to 8.x than I did from 8.x to 9.x. In
fact, the only visible changes in 9.x I've had to deal with have been
about compatibility changes and minor bugs I've had to update
for/fix. I could still be running 8.x. The only reason I've updated to
9.x is to avoid issues with some of the contrib packages that have/may
have been updated to work with 9.x
The other point to keep in mind is that this change won't happen
quickly. It will take some time before this can occur and we probably
need to start thinking/talking about it now so that when the right time
arrives, things can move forward.
--
Tim Cross
next prev parent reply other threads:[~2017-07-03 22:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 8:02 org mode moves to GNU emacs core Uwe Brauer
2017-06-29 8:50 ` Rasmus
2017-06-29 9:18 ` Uwe Brauer
2017-07-03 7:28 ` Bastien
2017-07-03 8:33 ` Uwe Brauer
2017-07-03 12:52 ` qTim Cross
2017-07-03 14:21 ` Uwe Brauer
2017-07-03 22:13 ` Tim Cross [this message]
[not found] ` <WM!dafdc952e01c9db7d6439bb691272a1ba664e1bae5ab4554e86ed6b7dfea8661d8bbaf476f3ba9dbb09c0c663c84ecc2!@mailhub-mx5.ncl.ac.uk>
2017-07-04 10:45 ` Phillip Lord
[not found] ` <WM!be0b82133cf58eecb5726e88694e8427b36d27c5719f4dbc8d7da9ca2db24765a0806a2a785dcaaf4a6d56d6bd773dc0!@mailhub-mx1.ncl.ac.uk>
2017-07-04 10:36 ` Phillip Lord
[not found] ` <f53ab9c6e9a440bbb5d939a425a97b62@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-07-03 8:52 ` Eric S Fraga
2017-07-03 9:20 ` Alan Schmitt
[not found] ` <WM!87da95345c53f08eaef15c5b7433fda36bb968c366f5815f7f948ed74d91e1259bbc88820ebbf91e3556ee6a4a3e9852!@mailhub-mx5.ncl.ac.uk>
2017-07-03 12:10 ` Phillip Lord
2017-07-03 12:40 ` Bastien Guerry
2017-07-03 15:23 ` Robert Horn
2017-07-04 8:01 ` Bastien Guerry
[not found] ` <WM!e5e8b591af401b295776634cbabb0d1b446d7bb568c1f8abadd4637a576ff78bf92ed6ccedeed082b016a3f6c9ad6c12!@mailhub-mx3.ncl.ac.uk>
2017-07-04 9:59 ` Phillip Lord
[not found] ` <6d3b27a9e0b245a49cffa029d13bbdb9@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-07-03 13:12 ` Eric S Fraga
2017-07-03 13:30 ` Adonay Felipe Nogueira
2017-07-03 16:52 ` Adonay Felipe Nogueira
2017-07-03 17:58 ` Nick Dokos
2017-07-03 19:38 ` Adonay Felipe Nogueira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8ytxj6p.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=oub@mat.ucm.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).