[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: org-export raises stringp nil error

From: Dmitry Gutov
Subject: Re: org-export raises stringp nil error
Date: Sat, 09 Mar 2013 01:00:14 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

On 08.03.2013 18:06, Eli Zaretskii wrote:
From: Dmitry Gutov <address@hidden>
Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
address@hidden,  address@hidden
Date: Fri, 08 Mar 2013 15:18:19 +0400

I like the idea of stripping big bundled packages (like org, gnus,
cedet, maybe even tramp, if that's possible).

That would certainly mean more problems for users to set them up with
a particular version of Emacs, because there's no longer a clear way
of getting the version of package X that correspond to Emacs version

There won't be such correspondence.

And therein lies the problem.

AFAIK, all 4 packages I mentioned above maintain backward compatible
codebases, so it's not like they depend on the latest Emacs.

When I install a package, I usually want its latest *stable* version
that is compatible with the Emacs version I run.  As great as

Well, you're not getting it now. If you're using Emacs 23, you get the old version of Org that was bundled with it, and not some newer one that is still compatible with it (that would be the current stable release, I imagine).

compatibility stuff is, I trust testing more, as I need to do
something each day that doesn't involve debugging Emacs and my other

Easier access to newer versions for users means a bigger testing pool.
Yes, the combination of "latest org + latest Emacs" may end up getting tested less, but that might be an acceptable tradeoff.

Also, since org-mode or gnus won't update without explicit action from you, working with/on Emacs trunk may become more stable, because it will mean less moving parts.

Also think about various package managers for GNU/Linux distros, which
need to specify on what version of Emacs package X depends.

They already do, at least for some packages:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]