Re: [O] org-export raises stringp nil error
On Fri, 08 Mar 2013 11:29:23 -0500 Nick Dokos wrote: > Bastien wrote: > > Xue Fuqiao writes: > > > Sounds fine to me, because my Internet connection is very slow > > > (especially to Savannah). It is often a pain for me to perform a `bzr > > > pull', since it takes a long time. > > Well, that's more an argument for switching to hg or git > > for Emacs repo, not really for trimming out packages from > > Emacs core. > There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. But Emacs Dev don't have access to this repository or the repository on Savannah. I think what Bastien meant is switching the main repository. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] org-export raises stringp nil error
On 08.03.2013 18:06, Eli Zaretskii wrote: From: Dmitry Gutov Cc: l...@metapensiero.it, joa...@verona.se, emacs-de...@gnu.org, b...@gnu.org, emacs-orgmode@gnu.org, sdl@gmail.com 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 N.M. 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 tools. 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: http://packages.ubuntu.com/quantal/gnus http://packages.ubuntu.com/quantal/org-mode
Re: [O] org-export raises stringp nil error
Eli Zaretskii writes: > Not even that: the release candidate already reports its version as > 24.3, so all is needed is to rename the tarball and upload to > ftp.gnu.org. I stand corrected.
Re: [O] org-export raises stringp nil error
Eli Zaretskii writes: >> From: joa...@verona.se >> Date: Fri, 08 Mar 2013 10:15:07 +0100 >> Cc: b...@gnu.org, l...@metapensiero.it, emacs-orgmode@gnu.org, >> Leo Liu , emacs-de...@gnu.org >> >> - Emacs "trunk" could be stripped of all but the bare essentials to >> achieve bootstrap. >> - distribution tarballs could be made from trunk+elpa. >> >> Since I dont do releases for Emacs I dont get to have an opinion on the >> matter, but if pressed, I would say this idea has considerable merit. > > It also has at least one demerits: people who track the trunk will not > necessarily use the revisions of packages from elpa that will be > included in Emacs tarballs. That will probably mean longer and more > painful pretests, and some of the advantages of having a publicly > accessible development trunk will be lost. On the other hand, people using older-but-still-supported versions of Emacs will be able to help test the new versions of packages in ELPA. Considering the total Emacs userbase is huge, this could be a great benefit, and hey, if a problem in org-mode is found just before Emacs release, it would either be completely org-mode team's problem (if it's not bundled with Emacs), or Emacs could bundle the last stable version without the regression. As long as Org is in the same tree, doing this kind of trick is much harder.
Re: [O] org-export raises stringp nil error
Eli Zaretskii writes: >> From: Dmitry Gutov >> Cc: Eli Zaretskii , b...@gnu.org, l...@metapensiero.it, >> emacs-orgmode@gnu.org, Leo Liu , emacs-de...@gnu.org >> Date: Fri, 08 Mar 2013 13:25:16 +0400 >> >> joa...@verona.se writes: >> > Just a small reminder of the idea Stefan sometimes drops in these >> > discussions: >> > - Emacs "trunk" could be stripped of all but the bare essentials to >> > achieve bootstrap. >> >> 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 > N.M. There won't be such correspondence. AFAIK, all 4 packages I mentioned above maintain backward compatible codebases, so it's not like they depend on the latest Emacs. And if some do, package.el allows to specify the minimal Emacs version in the "Package-Requires" header. It just might use some improvement in the error message when this dependency is not satisfied. So, users of all versions of Emacs would use the same latest stable Gnus, Org and CEDET, as long as the packages maintain backward compatibility. That would create some pressure to upgrade old Emacs versions, though (as long as ELPA repositories only contain the latest versions of packages), but that's not necessarily a bad thing.
Re: [O] org-export raises stringp nil error
joa...@verona.se writes: > Just a small reminder of the idea Stefan sometimes drops in these > discussions: > - Emacs "trunk" could be stripped of all but the bare essentials to > achieve bootstrap. I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). > - distribution tarballs could be made from trunk+elpa. > > Since I dont do releases for Emacs I dont get to have an opinion on the > matter, but if pressed, I would say this idea has considerable merit. If distribution tarballs include code from elpa, then I imagine code freeze rules would also apply to elpa branch. So I don't see how this would be an improvement.
Re: [O] org-export raises stringp nil error
> From: Achim Gratz > Date: Fri, 08 Mar 2013 17:34:42 +0100 > Cc: emacs-orgmode@gnu.org > > In any case, doing the built-in packages this way (or something similar) > takes a lot of unecessary churn and merges out of the release process > and I would think that would be a clear advantage to everyone involved. I see that we have come a full circle, what with all this new blood pouring into Emacs development, and we are finally ready to repeat the failed experiment with dividing Emacs into "core" and "all the rest". Good luck (you will need it)!
Re: [O] org-export raises stringp nil error
Jambunathan K wrote: > > So two questions: > > > > o is the savannah repo http only? > > > > o and if so, it used to be the case that http was much slower than git - > > is that still the case? > > Bzr user here. May be try one of these? > > , https://savannah.gnu.org/git/?group=emacs > | Anonymous checkout: > | > | git clone git://git.savannah.gnu.org/emacs.git > ` This seems to work. Thanks! Nick
Re: [O] org-export raises stringp nil error
Nick Dokos writes: > Bastien wrote: > >> Jambunathan K writes: >> >> > Nick Dokos writes: >> > >> >> There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. >> > >> > This one is from savannah >> > >> > http://git.savannah.gnu.org/cgit/emacs.git >> >> Great minds think alike!! :) >> >> -- >> Bastien >> > > Thanks to both for pointing it out: I think I knew about it at some > point in the past and had some problems with it. > > So I just tried changing my git config to pull from there (I should > point out that I tried the git:// version of the URL) - I'm getting > > $ git pull > fatal: The remote end hung up unexpectedly > > So two questions: > > o is the savannah repo http only? > > o and if so, it used to be the case that http was much slower than git - > is that still the case? Bzr user here. May be try one of these? , https://savannah.gnu.org/git/?group=emacs | Anonymous checkout: | | git clone git://git.savannah.gnu.org/emacs.git ` , http://savannah.gnu.org/maintenance/UsingGit | URL-s summary: | | git://git.sv.gnu.org/myproject.git - git lightweight protocol (read-only access) | ssh://git.sv.gnu.org/srv/git/myproject.git - developer access using SSH | http://git.sv.gnu.org/r/myproject.git - slow dumb protocol, http-based, for use behind fascist firewalls | | Web browser: http://git.sv.gnu.org/gitweb/ | | If you use ssh-based access, please verify the host keys first at | SshAccess (git.sv.gnu.org is the same host as cvs.sv.gnu.org). | | Note: there is at most a 1/2h delay between Git activation in the web | front-end, and its creation on the system. Basic commands | | Checkout: | | git clone git://git.sv.gnu.org/project.git | | Firewall checkout: if you're behind a outgoing-traffic-filtering firewall, you can use Git's "dumb protocol" via HTTP - note that this is SLOWER, both for you and Savannah. Avoid if possible, and please tell your local sysadmin to allow outgoing git traffic (port 9418): | | git clone http://git.savannah.gnu.org/r/project.git | | Note: we enabled git-http-backend (a CGI script) to speed up HTTP cloning, but this is still not the recommended protocol. | | Project member checkout: if you want to be able to push your changes back into the repository on savannah: | | git clone lo...@git.sv.gnu.org:/srv/git/project.git | ` > Thanks, > Nick > > > --
Re: [O] org-export raises stringp nil error
Bastien wrote: > Jambunathan K writes: > > > Nick Dokos writes: > > > >> There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. > > > > This one is from savannah > > > > http://git.savannah.gnu.org/cgit/emacs.git > > Great minds think alike!! :) > > -- > Bastien > Thanks to both for pointing it out: I think I knew about it at some point in the past and had some problems with it. So I just tried changing my git config to pull from there (I should point out that I tried the git:// version of the URL) - I'm getting $ git pull fatal: The remote end hung up unexpectedly So two questions: o is the savannah repo http only? o and if so, it used to be the case that http was much slower than git - is that still the case? Thanks, Nick
Re: [O] org-export raises stringp nil error
Jambunathan K writes: > Nick Dokos writes: > >> There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. > > This one is from savannah > > http://git.savannah.gnu.org/cgit/emacs.git Great minds think alike!! :) -- Bastien
Re: [O] org-export raises stringp nil error
Hi Nick, Nick Dokos writes: > Bastien wrote: > >> Hi Xue, >> >> Xue Fuqiao writes: >> >> > Sounds fine to me, because my Internet connection is very slow >> > (especially to Savannah). It is often a pain for me to perform a `bzr >> > pull', since it takes a long time. >> >> Well, that's more an argument for switching to hg or git >> for Emacs repo, not really for trimming out packages from >> Emacs core. > > There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. FWIW, here is the one I'm using, from the Savannah server: http://git.savannah.gnu.org/cgit/emacs.git/ -- Bastien
Re: [O] org-export raises stringp nil error
Nick Dokos writes: > There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. This one is from savannah http://git.savannah.gnu.org/cgit/emacs.git --
Re: [O] org-export raises stringp nil error
Bastien wrote: > Hi Xue, > > Xue Fuqiao writes: > > > Sounds fine to me, because my Internet connection is very slow > > (especially to Savannah). It is often a pain for me to perform a `bzr > > pull', since it takes a long time. > > Well, that's more an argument for switching to hg or git > for Emacs repo, not really for trimming out packages from > Emacs core. There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. I've been using it with no problems (afaict) for some years now. It may not have today's updates until tomorrow, but if you upgrade emacs every couple of months as I do, it should serve well. Nick
Re: [O] org-export raises stringp nil error
Hi Xue, Xue Fuqiao writes: > Sounds fine to me, because my Internet connection is very slow > (especially to Savannah). It is often a pain for me to perform a `bzr > pull', since it takes a long time. Well, that's more an argument for switching to hg or git for Emacs repo, not really for trimming out packages from Emacs core. > And there is also another way: Add a command line argument named > `--slim', it can invoke Emacs with only the bare-minimum Emacs Lisp > libraries needed for quick editing. That's what the require mechanism is for: libraries are not loaded until you require/load them. -- Bastien
Re: [O] org-export raises stringp nil error
On Fri, 08 Mar 2013 10:15:07 +0100 joa...@verona.se wrote: > Just a small reminder of the idea Stefan sometimes drops in these > discussions: > - Emacs "trunk" could be stripped of all but the bare essentials to > achieve bootstrap. > - distribution tarballs could be made from trunk+elpa. > Since I dont do releases for Emacs I dont get to have an opinion on the > matter, but if pressed, I would say this idea has considerable merit. Sounds fine to me, because my Internet connection is very slow (especially to Savannah). It is often a pain for me to perform a `bzr pull', since it takes a long time. And there is also another way: Add a command line argument named `--slim', it can invoke Emacs with only the bare-minimum Emacs Lisp libraries needed for quick editing. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] org-export raises stringp nil error
> From: Dmitry Gutov > Cc: l...@metapensiero.it, joa...@verona.se, emacs-de...@gnu.org, > b...@gnu.org, emacs-orgmode@gnu.org, sdl@gmail.com > 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 > > N.M. > > 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 compatibility stuff is, I trust testing more, as I need to do something each day that doesn't involve debugging Emacs and my other tools. Also think about various package managers for GNU/Linux distros, which need to specify on what version of Emacs package X depends.
Re: [O] org-export raises stringp nil error
> From: Dmitry Gutov > Cc: Eli Zaretskii , b...@gnu.org, l...@metapensiero.it, > emacs-orgmode@gnu.org, Leo Liu , emacs-de...@gnu.org > Date: Fri, 08 Mar 2013 13:25:16 +0400 > > joa...@verona.se writes: > > Just a small reminder of the idea Stefan sometimes drops in these > > discussions: > > - Emacs "trunk" could be stripped of all but the bare essentials to > > achieve bootstrap. > > 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 N.M.
Re: [O] org-export raises stringp nil error
> From: joa...@verona.se > Date: Fri, 08 Mar 2013 10:15:07 +0100 > Cc: b...@gnu.org, l...@metapensiero.it, emacs-orgmode@gnu.org, > Leo Liu , emacs-de...@gnu.org > > - Emacs "trunk" could be stripped of all but the bare essentials to > achieve bootstrap. > - distribution tarballs could be made from trunk+elpa. > > Since I dont do releases for Emacs I dont get to have an opinion on the > matter, but if pressed, I would say this idea has considerable merit. It also has at least one demerits: people who track the trunk will not necessarily use the revisions of packages from elpa that will be included in Emacs tarballs. That will probably mean longer and more painful pretests, and some of the advantages of having a publicly accessible development trunk will be lost.
Re: [O] org-export raises stringp nil error
joa...@verona.se writes: > Just a small reminder of the idea Stefan sometimes drops in these > discussions: > - Emacs "trunk" could be stripped of all but the bare essentials to > achieve bootstrap. I don't know that I'd go so far as to include all of CC-mode, but more than once I've missed some of the stuff not included in core XEmacs. The bootstrapped Emacs should be a fully functional editor, hopefully with some features useful for editing Emacs' own sources.
Re: [O] org-export raises stringp nil error
joa...@verona.se writes: > Just a small reminder of the idea Stefan sometimes drops in these > discussions: > - Emacs "trunk" could be stripped of all but the bare essentials to > achieve bootstrap. > - distribution tarballs could be made from trunk+elpa. PS: This is similar to my plan of creating org-contrib.git as a spin off from org-mode.git. There would be two repositories and contrib/ would still be packaged in Org tarballs. org-mode.git would contain the "bare" Org, the one similar to the one in GNU ELPA, for later distribution within Emacs tarballs. -- Bastien
Re: [O] org-export raises stringp nil error
Hi Joakim, joa...@verona.se writes: > Just a small reminder of the idea Stefan sometimes drops in these > discussions: > - Emacs "trunk" could be stripped of all but the bare essentials to > achieve bootstrap. > - distribution tarballs could be made from trunk+elpa. > > Since I dont do releases for Emacs I dont get to have an opinion on the > matter, but if pressed, I would say this idea has considerable > merit. Thanks for reminding us of this idea, I clearly see the benefits. As long as Org is distributed in Emacs, I personally have no problem. -- Bastien
Re: [O] org-export raises stringp nil error
Eli Zaretskii writes: >> From: Leo Liu >> Date: Fri, 08 Mar 2013 15:16:57 +0800 >> Cc: emacs-de...@gnu.org, emacs-orgmode@gnu.org, >> Lele Gaifax >> >> Bundling [org-mode] in emacs doesn't help anybody. > > You never had to work for an organization whose network is closed to > outside world, did you? In those situations, using package.el to > seamlessly fetch unbundled packages is impossible, which makes > building a full and functional Emacs a pain if important packages are > left out of the bundle. > Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs "trunk" could be stripped of all but the bare essentials to achieve bootstrap. - distribution tarballs could be made from trunk+elpa. Since I dont do releases for Emacs I dont get to have an opinion on the matter, but if pressed, I would say this idea has considerable merit. -- Joakim Verona
Re: [O] org-export raises stringp nil error
Thanks all for the answers, quite educational to me (at least). -- Bastien
Re: [O] org-export raises stringp nil error
> From: "Stephen J. Turnbull" > Date: Fri, 08 Mar 2013 17:27:56 +0900 > Cc: Lele Gaifax , emacs-de...@gnu.org, > emacs-orgmode@gnu.org, Bastien > > [...] in a release candidate the release engineer proposes to make > exactly one change before release: remove "rc" from the version > string and then roll the tarballs and announce. Not even that: the release candidate already reports its version as 24.3, so all is needed is to rename the tarball and upload to ftp.gnu.org. Of course, now that some problems _have_ been found, a new tarball will be needed.
Re: [O] org-export raises stringp nil error
> Date: Fri, 08 Mar 2013 15:47:57 +0800 > From: Xue Fuqiao > Cc: Bastien , emacs-de...@gnu.org, emacs-orgmode@gnu.org, > Lele Gaifax > > On 03/08/2013 02:40 PM, Bastien wrote: > > I missed the distinction between "pretest" and "release candidate". > > What's the difference between "pretest" and "release candidate"? A release candidate builds a binary whose version is the same as the upcoming release (24.3 in this case, as opposed to 24.2.XX for the pretests), and will become the release (by just renaming the tarball) if no serious problems are discovered.
Re: [O] org-export raises stringp nil error
> From: Leo Liu > Date: Fri, 08 Mar 2013 15:16:57 +0800 > Cc: emacs-de...@gnu.org, emacs-orgmode@gnu.org, > Lele Gaifax > > Bundling [org-mode] in emacs doesn't help anybody. You never had to work for an organization whose network is closed to outside world, did you? In those situations, using package.el to seamlessly fetch unbundled packages is impossible, which makes building a full and functional Emacs a pain if important packages are left out of the bundle.
Re: [O] org-export raises stringp nil error
Xue Fuqiao writes: > On 03/08/2013 02:40 PM, Bastien wrote: > > I missed the distinction between "pretest" and "release candidate". > > What's the difference between "pretest" and "release candidate"? A release candidate may be considered to be a kind of pretest. The difference (as Glenn already implied) is that in a release candidate the release engineer proposes to make exactly one change before release: remove "rc" from the version string and then roll the tarballs and announce. Only if the release is unusable (new crash, data corruption, or security hole since last pretest) will it be patched before release. The way to think about this is that a release candidate is only there to save face for the release engineer. Ordinary bugs aren't his problem any more. ;-)
Re: [O] org-export raises stringp nil error
Bastien writes: > I find it hard to draw a clear line between regressions and bugs, > especially since Org 7.9.x versions are way behind the current Org > master branch. A regression is a feature that is missing, incomplete, or buggy in the current HEAD that was present, complete, and correct in some ancestor of HEAD that preceded the feature freeze. If it's difficult to identify regressions by that definition, you probably should not even try to work on the Emacs prerelease branch except by request of the release engineer. Some release engineers (not me ;-) may restrict "ancestor" to be the previous released version. All release engineers I know restrict HEAD and ancestor to versions of the project they manage. ;-)
Re: [O] org-export raises stringp nil error
On 03/08/2013 03:37 PM, Bastien wrote: I think org-mode is better in ELPA, a better distribution channel than the core for things like org-mode. Bundling it in emacs doesn't help anybody. I strongly think otherwise: Emacs needs a good outline and editing tool. outline.el is not usable enough and I can see no other Emacs tool than Org-mode for exporting to HTML/LaTeX/ODT easily. I agree. And I think some packages in GNU ELPA like AUCTeX and js2-mode should also be contained. The built-in modes for editing TeX related files and EMCAScript are not quite usable. I understand the temptation in terms of maintainance, but I think maintainance problems should not take priority over usefulness of the code. +1 -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] org-export raises stringp nil error
Xue Fuqiao writes: > On 03/08/2013 02:40 PM, Bastien wrote: >> I missed the distinction between "pretest" and "release candidate". > > What's the difference between "pretest" and "release candidate"? Doesn't > the latter belong to the former? The rc1/rc1.1 was released on the > "pretest" directory. Maybe this is just a difference of degree: only fix really-very-very- critical-regressions in rc, while fix bugs in pretest (and "rc" maybe is just the name for the last pretest releases, so a subset of them.) With two "maybe" I'm not helping very much, sorry. -- Bastien
Re: [O] org-export raises stringp nil error
On 03/08/2013 02:40 PM, Bastien wrote: I missed the distinction between "pretest" and "release candidate". What's the difference between "pretest" and "release candidate"? Doesn't the latter belong to the former? The rc1/rc1.1 was released on the "pretest" directory. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] org-export raises stringp nil error
On 2013-03-08 15:37 +0800, Bastien wrote: > I strongly think otherwise: Emacs needs a good outline and editing > tool. outline.el is not usable enough and I can see no other Emacs > tool than Org-mode for exporting to HTML/LaTeX/ODT easily. > > I understand the temptation in terms of maintainance, but I think > maintainance problems should not take priority over usefulness of > the code. I am not doubting maintainance cost or the usefulness of the code. It is about distribution of your code to the users. I think ELPA is the way to go. Leo
Re: [O] org-export raises stringp nil error
Leo Liu writes: > On 2013-03-08 14:40 +0800, Bastien wrote: >> I find it hard to draw a clear line between regressions and bugs, >> especially since Org 7.9.x versions are way behind the current Org >> master branch. > > I think org-mode is better in ELPA, a better distribution channel than > the core for things like org-mode. Bundling it in emacs doesn't help > anybody. I strongly think otherwise: Emacs needs a good outline and editing tool. outline.el is not usable enough and I can see no other Emacs tool than Org-mode for exporting to HTML/LaTeX/ODT easily. I understand the temptation in terms of maintainance, but I think maintainance problems should not take priority over usefulness of the code. -- Bastien
Re: [O] org-export raises stringp nil error
On 2013-03-08 14:40 +0800, Bastien wrote: > I find it hard to draw a clear line between regressions and bugs, > especially since Org 7.9.x versions are way behind the current Org > master branch. I think org-mode is better in ELPA, a better distribution channel than the core for things like org-mode. Bundling it in emacs doesn't help anybody. Leo
Re: [O] org-export raises stringp nil error
Glenn Morris writes: >> I assumed it was okay to fix bugs after the last pretest, is it so? > > No, it is not ok, and I don't know why you would think it is. I missed the distinction between "pretest" and "release candidate". > The reason for this policy is (obviously) to prevent inadvertently > introducing mistakes. This seems to be exactly what has bitten us in > this case, where your patch just reverts the change from > > http://lists.gnu.org/archive/html/emacs-diffs/2013-02/msg00058.html > > Was that fixing a regression? I doubt it. I find it hard to draw a clear line between regressions and bugs, especially since Org 7.9.x versions are way behind the current Org master branch. > Please apply the first patch as soon as possible. Done. > The second includes stuff like deleting comments, declaring functions, > and changing autoload for "org-autoload". No, you may not apply this. > > If there were any fixes in there for important regression bugs against > Emacs 24.2, please make a separate patch with just those items. Those are not critical regressions, so I won't apply them. -- Bastien
Re: [O] org-export raises stringp nil error
Bastien wrote: > Glenn Morris writes: > >> Assuming this is a recent regression, then if anyone from Org wants this >> fixed in Emacs 24.3, they should investigate this very quickly and >> suggest the _minimum_ change. > > The minimal fix is attached. > > The other attachment is the full patch I wanted to apply to merge > Org 7.9.4 into Emacs 24.3. The changes are all safe bugfixes. > > I assumed it was okay to fix bugs after the last pretest, is it so? No, it is not ok, and I don't know why you would think it is. "Release candidate" means "this IS the release unless something CRITICAL occurs". I hoped my various posts to this list had made this clear. It's also been the traditional policy of at least the more recent Emacs releases as far as I know. I should have been stricter in insisting that Org follow the same policy as everybody else during pretesting, in only installing regression bug fixes. I'm pretty sure this has not been happening, given the size and nature of the changes that keep landing. The reason for this policy is (obviously) to prevent inadvertently introducing mistakes. This seems to be exactly what has bitten us in this case, where your patch just reverts the change from http://lists.gnu.org/archive/html/emacs-diffs/2013-02/msg00058.html Was that fixing a regression? I doubt it. Please apply the first patch as soon as possible. The second includes stuff like deleting comments, declaring functions, and changing autoload for "org-autoload". No, you may not apply this. If there were any fixes in there for important regression bugs against Emacs 24.2, please make a separate patch with just those items.
Re: [O] org-export raises stringp nil error
Glenn Morris writes: > Assuming this is a recent regression, then if anyone from Org wants this > fixed in Emacs 24.3, they should investigate this very quickly and > suggest the _minimum_ change. The minimal fix is attached. The other attachment is the full patch I wanted to apply to merge Org 7.9.4 into Emacs 24.3. The changes are all safe bugfixes. I assumed it was okay to fix bugs after the last pretest, is it so? Let me know when is the best time for me to merge and I'll release and merge Org 7.9.4. Thanks, diff --git a/lisp/org/org-exp.el b/lisp/org/org-exp.el index 5ccaec3..63a0659 100644 --- a/lisp/org/org-exp.el +++ b/lisp/org/org-exp.el @@ -2113,8 +2110,7 @@ Also, store forced alignment information found in such lines." (put-text-property (match-beginning 0) (match-end 0) 'org-normalized-link t)) (goto-char (point-min)) (while (re-search-forward re-plain-link nil t) - (unless (or (get-text-property (match-beginning 0) 'org-normalized-link) - (assoc :tags (org-context))) + (unless (get-text-property (match-beginning 0) 'org-normalized-link) (goto-char (1- (match-end 0))) (org-if-unprotected-at (1+ (match-beginning 0)) (let* ((s (concat (match-string 1) Changes in master Modified lisp/org/org-agenda.el diff --git a/lisp/org/org-agenda.el b/lisp/org/org-agenda.el index 79217b6..48328d8 100644 --- a/lisp/org/org-agenda.el +++ b/lisp/org/org-agenda.el @@ -6987,6 +6987,8 @@ If the line does not have an effort defined, return nil." (defun org-agenda-filter-apply (filter type) "Set FILTER as the new agenda filter and apply it." + ;; Deactivate `org-agenda-entry-text-mode' when filtering + (if org-agenda-entry-text-mode (org-agenda-entry-text-mode)) (let (tags cat) (if (eq type 'tag) (setq org-agenda-tag-filter filter) @@ -7418,17 +7420,23 @@ so that the date SD will be in that range." (defun org-agenda-entry-text-mode (&optional arg) "Toggle entry text mode in an agenda buffer." (interactive "P") - (setq org-agenda-entry-text-mode (or (integerp arg) - (not org-agenda-entry-text-mode))) - (org-agenda-entry-text-hide) - (and org-agenda-entry-text-mode - (let ((org-agenda-entry-text-maxlines - (if (integerp arg) arg org-agenda-entry-text-maxlines))) - (org-agenda-entry-text-show))) - (org-agenda-set-mode-name) - (message "Entry text mode is %s. Maximum number of lines is %d" - (if org-agenda-entry-text-mode "on" "off") - (if (integerp arg) arg org-agenda-entry-text-maxlines))) + (if (or org-agenda-tag-filter + org-agenda-category-filter + org-agenda-top-category-filter) + (user-error "Can't show entry text in filtered views") +(setq org-agenda-entry-text-mode (or (integerp arg) + (not org-agenda-entry-text-mode))) +(org-agenda-entry-text-hide) +(and org-agenda-entry-text-mode + (let ((org-agenda-entry-text-maxlines + (if (integerp arg) arg org-agenda-entry-text-maxlines))) + (org-agenda-entry-text-show))) +(org-agenda-set-mode-name) +(message "Entry text mode is %s%s" + (if org-agenda-entry-text-mode "on" "off") + (if (not org-agenda-entry-text-mode) "" + (format " (maximum number of lines is %d)" + (if (integerp arg) arg org-agenda-entry-text-maxlines)) (defun org-agenda-clockreport-mode (&optional with-filter) "Toggle clocktable mode in an agenda buffer. Modified lisp/org/org-bibtex.el diff --git a/lisp/org/org-bibtex.el b/lisp/org/org-bibtex.el index 6ed6abc..704b204 100644 --- a/lisp/org/org-bibtex.el +++ b/lisp/org/org-bibtex.el @@ -120,6 +120,7 @@ (declare-function bibtex-generate-autokey "bibtex" ()) (declare-function bibtex-parse-entry "bibtex" (&optional content)) (declare-function bibtex-url "bibtex" (&optional pos no-browse)) +(declare-function longlines-mode "longlines" (&optional arg)) (declare-function org-babel-trim "ob" (string &optional regexp)) @@ -380,7 +381,7 @@ This variable is relevant only if `org-bibtex-export-tags-as-keywords' is t." (buf-name (format "*Bibtex Help %s*" name))) (with-output-to-temp-buffer buf-name (princ (cdr (assoc field org-bibtex-fields - (with-current-buffer buf-name (visual-line-mode 1)) + (with-current-buffer buf-name (longlines-mode t)) (org-fit-window-to-buffer (get-buffer-window buf-name)) ((lambda (result) (when (> (length result) 0) result)) (read-from-minibuffer (format "%s: " name)) Modified lisp/org/org-clock.el diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el index a536d02..b89e644 100644 --- a/lisp/org/org-clock.el +++ b/lisp/org/org-clock.el @@ -1524,7 +1524,15 @@ to, overriding the existing value of `org-clock-out-switch-to-state'." (force-mode-line-update) (message (concat "Clock stopped at %s after HH:MM = " org-time-clocksum-format "%s") te h m (if remove " => LINE REMOVED" "")) - (run-hooks 'org-clock-out-hook) + (let ((h org-clock-o
Re: [O] org-export raises stringp nil error
Assuming this is a recent regression, then if anyone from Org wants this
fixed in Emacs 24.3, they should investigate this very quickly and
suggest the _minimum_ change.
See also the possibly related, unanswered
http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00028.html
Lele Gaifax wrote:
> Using current emacs-snapshot[1], trying to export even the following
> very simple file:
>
> # -*- mode: org; coding: utf-8 -*-
>
> * hi
>
> http://www.gnu.org/
>
> to HTML results in this error:
>
> org-export-protect-sub-super: Wrong type argument: stringp, nil
>
> with the following traceback:
>
> string-match("\\([^]\\)\\([_^]\\)" nil)
> org-export-protect-sub-super(nil)
> org-export-normalize-links()
> org-export-preprocess-string(#("# -*- mode: org; coding: utf-8 -*-\n\n*
> hi\n\n http://www.gnu.org/\n"; 0 34 (fontified t font-lock-fontified t face
> font-lock-comment-face) 34 36 (fontified t) 36 38 (fontified t face
> org-level-1) 38 40 (fontified t face org-level-1) 40 44 (fontified t) 44 62
> (fontified t org-no-flyspell t mouse-face highlight face org-link keymap
> (keymap (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse)
> (mouse-2 . org-open-at-mouse))) 62 63 (fontified t org-no-flyspell t
> mouse-face highlight face org-link keymap (keymap (follow-link . mouse-face)
> (mouse-3 . org-find-file-at-mouse) (mouse-2 . org-open-at-mouse))
> rear-nonsticky (mouse-face highlight keymap invisible intangible help-echo
> org-linked-text htmlize-link)) 63 64 (fontified t)) :emph-multiline t
> :for-backend html :skip-before-1st-heading nil :drawers nil :todo-keywords t
> :tasks t :tags not-in-toc :priority nil :footnotes t :timestamps t
> :archived-trees headline :select-tags ("export") :exclude-tags ("noexport")
> :add-text nil :LaTeX-fragments t)
> org-export-as-html(nil)
> call-interactively(org-export-as-html)
> org-export(nil)
> call-interactively(org-export nil nil)
> command-execute(org-export)
>
> If this isn't already known/fixed, should I report it as a bug? And
> eventually, on Emacs itself or on org-mode?
>
> thanks in advance,
> bye, lele.
>
> [1] GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of
> 2013-03-04 on dex, modified by Debian
