Re: org-export raises stringp nil error

Re: org-export raises stringp nil error

[Glenn Morris]

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

Re: org-export raises stringp nil error

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

Glenn Morris <rgm@gnu.org> 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,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-24.3-fix.patch --]
[-- Type: text/x-patch, Size: 700 bytes --]

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)

[-- Attachment #3: emacs-24.3-merge-org-7.9.4.patch --]
[-- Type: text/x-patch, Size: 8249 bytes --]

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))
 
 \f
@@ -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-out-hook))
+	    ;; If a closing note needs to be stored in the drawer
+	    ;; where clocks are stored, let's temporarily disable
+	    ;; `org-clock-remove-empty-clock-drawer'
+	    (if (and (equal org-clock-into-drawer org-log-into-drawer)
+		     (eq org-log-done 'note)
+		     org-clock-out-when-done)
+		(setq h (delq 'org-clock-remove-empty-clock-drawer h)))
+	    (mapc (lambda (f) (funcall f)) h))
 	  (unless (org-clocking-p)
 	    (org-clock-delete-current)))))))
 
	Modified   lisp/org/org-exp.el
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
@@ -50,12 +50,9 @@
 		  (&optional buffer-or-name norecord label))
 (declare-function org-unescape-code-in-region "org-src" (beg end))
 
-(autoload 'org-export-generic "org-export-generic" "Export using the generic exporter" t)
-
-(autoload 'org-export-as-odt "org-odt"
-  "Export the outline to a OpenDocument Text file." t)
-(autoload 'org-export-as-odt-and-open "org-odt"
-  "Export the outline to a OpenDocument Text file and open it." t)
+(org-autoload "org-odt" '(org-export-generic
+			  org-export-as-odt
+			  org-export-as-odt-and-open))
 
 (defgroup org-export nil
   "Options for exporting org-listings."
@@ -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)
	Modified   lisp/org/org-freemind.el
diff --git a/lisp/org/org-freemind.el b/lisp/org/org-freemind.el
index 3b1c686..6de5502 100644
--- a/lisp/org/org-freemind.el
+++ b/lisp/org/org-freemind.el
@@ -275,12 +275,6 @@ will also unescape &#nn;."
 			 )))
 		   org-str))))
 
-;; (let* ((str1 "a quote: \", an amp: &, lt: <; over 256: öåäÖÅÄ")
-;;        (str2 (org-freemind-escape-str-from-org str1))
-;;        (str3 (org-freemind-unescape-str-to-org str2)))
-;;     (unless (string= str1 str3)
-;;       (error "Error str3=%s" str3)))
-
 (defun org-freemind-convert-links-helper (matched)
   "Helper for `org-freemind-convert-links-from-org'.
 MATCHED is the link just matched."
@@ -1221,7 +1215,6 @@ PATH should be a list of steps, where each step has the form
 
 ;; Local variables:
 ;; generated-autoload-file: "org-loaddefs.el"
-;; coding: utf-8
 ;; End:
 
 ;;; org-freemind.el ends here
	Modified   lisp/org/org-mobile.el
diff --git a/lisp/org/org-mobile.el b/lisp/org/org-mobile.el
index 293d2a0..2d976dd 100644
--- a/lisp/org/org-mobile.el
+++ b/lisp/org/org-mobile.el
@@ -1063,6 +1063,9 @@ be returned that indicates what went wrong."
      ((eq what 'addheading)
       (if (org-on-heading-p) ; if false we are in top-level of file
 	  (progn
+	    ;; Workaround a `org-insert-heading-respect-content' bug
+	    ;; which prevents correct insertion when point is invisible
+	    (org-show-subtree)
 	    (end-of-line 1)
 	    (org-insert-heading-respect-content t)
 	    (org-demote))
	Modified   lisp/org/org-version.el
diff --git a/lisp/org/org-version.el b/lisp/org/org-version.el
index 4fa8653..ce2d50a 100644
--- a/lisp/org/org-version.el
+++ b/lisp/org/org-version.el
@@ -11,7 +11,7 @@
 (defun org-git-version ()
   "The Git version of org-mode.
   Inserted by installing org-mode or when a release is made."
-   (let ((org-git-version "release_7.9.3f-17-g7524ef"))
+   (let ((org-git-version "release_7.9.4"))
      org-git-version))
 ;;;###autoload
 (defvar org-odt-data-dir "/usr/share/emacs/etc/org"
	Modified   lisp/org/org.el
diff --git a/lisp/org/org.el b/lisp/org/org.el
index cc4c93f..13fb44d 100644
--- a/lisp/org/org.el
+++ b/lisp/org/org.el
@@ -4898,6 +4898,8 @@ The following commands are available:
   (org-set-local 'outline-regexp org-outline-regexp)
   (org-set-local 'outline-level 'org-outline-level)
   (setq bidi-paragraph-direction 'left-to-right)
+  ;; FIXME Circumvent a bug in outline.el (Emacs <24.4)
+  (set (make-local-variable 'paragraph-start) "\f\\|[ \t]*$\\|\\*+ ")
   (when (and org-ellipsis
              (fboundp 'set-display-table-slot) (boundp 'buffer-display-table)
 	     (fboundp 'make-glyph-code))


[-- Attachment #4: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: org-export raises stringp nil error

[Glenn Morris]

Bastien wrote:

> Glenn Morris <rgm@gnu.org> 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: org-export raises stringp nil error

[Bastien]

Glenn Morris <rgm@gnu.org> 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: org-export raises stringp nil error

[Leo Liu]

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: org-export raises stringp nil error

[Bastien]

Leo Liu <sdl.web@gmail.com> 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: org-export raises stringp nil error

[Leo Liu]

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: org-export raises stringp nil error

[Xue Fuqiao]

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: org-export raises stringp nil error

[Bastien]

Xue Fuqiao <xfq.free@gmail.com> 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: org-export raises stringp nil error

[Xue Fuqiao]

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: org-export raises stringp nil error

[Stephen J. Turnbull]

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: org-export raises stringp nil error

[Stephen J. Turnbull]

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: org-export raises stringp nil error

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Fri, 08 Mar 2013 15:16:57 +0800
> Cc: emacs-devel@gnu.org, emacs-orgmode@gnu.org,
> 	Lele Gaifax <lele@metapensiero.it>
> 
> 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: org-export raises stringp nil error

[Eli Zaretskii]

> Date: Fri, 08 Mar 2013 15:47:57 +0800
> From: Xue Fuqiao <xfq.free@gmail.com>
> Cc: Bastien <bzg@altern.org>, emacs-devel@gnu.org, emacs-orgmode@gnu.org,
> 	Lele Gaifax <lele@metapensiero.it>
> 
> 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: org-export raises stringp nil error

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 08 Mar 2013 17:27:56 +0900
> Cc: Lele Gaifax <lele@metapensiero.it>, emacs-devel@gnu.org,
> 	emacs-orgmode@gnu.org, Bastien <bzg@altern.org>
> 
> [...] 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: org-export raises stringp nil error

[Bastien]

Thanks all for the answers, quite educational to me (at least).

-- 
 Bastien

Re: org-export raises stringp nil error

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Leo Liu <sdl.web@gmail.com>
>> Date: Fri, 08 Mar 2013 15:16:57 +0800
>> Cc: emacs-devel@gnu.org, emacs-orgmode@gnu.org,
>> 	Lele Gaifax <lele@metapensiero.it>
>> 
>> 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: org-export raises stringp nil error

[Bastien]

Hi Joakim,

joakim@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: org-export raises stringp nil error

[Bastien]

joakim@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: org-export raises stringp nil error

[Dmitry Gutov]

joakim@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: org-export raises stringp nil error

[Stephen J. Turnbull]

joakim@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: org-export raises stringp nil error

[Stephen J. Turnbull]

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: org-export raises stringp nil error

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Fri, 08 Mar 2013 10:15:07 +0100
> Cc: bzg@gnu.org, lele@metapensiero.it, emacs-orgmode@gnu.org,
> 	Leo Liu <sdl.web@gmail.com>, emacs-devel@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: org-export raises stringp nil error

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: Eli Zaretskii <eliz@gnu.org>,  bzg@gnu.org,  lele@metapensiero.it,  emacs-orgmode@gnu.org,  Leo Liu <sdl.web@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 08 Mar 2013 13:25:16 +0400
> 
> joakim@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: org-export raises stringp nil error

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: joakim@verona.se
>> Date: Fri, 08 Mar 2013 10:15:07 +0100
>> Cc: bzg@gnu.org, lele@metapensiero.it, emacs-orgmode@gnu.org,
>> 	Leo Liu <sdl.web@gmail.com>, emacs-devel@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: org-export raises stringp nil error

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  bzg@gnu.org,  lele@metapensiero.it,  emacs-orgmode@gnu.org,  Leo Liu <sdl.web@gmail.com>,  emacs-devel@gnu.org
>> Date: Fri, 08 Mar 2013 13:25:16 +0400
>> 
>> joakim@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: org-export raises stringp nil error

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: lele@metapensiero.it,  joakim@verona.se,  emacs-devel@gnu.org,  bzg@gnu.org,  emacs-orgmode@gnu.org,  sdl.web@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: org-export raises stringp nil error

[Xue Fuqiao]

On Fri, 08 Mar 2013 10:15:07 +0100
joakim@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: org-export raises stringp nil error

[Bastien]

Hi Xue,

Xue Fuqiao <xfq.free@gmail.com> 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: org-export raises stringp nil error

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi Xue,
> 
> Xue Fuqiao <xfq.free@gmail.com> 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: org-export raises stringp nil error

[Achim Gratz]

Eli Zaretskii writes:
> 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.

As long as ELPA is in Git, that's absolutely no problem.  The exact
version of the package that's going into an Emacs release is tagged with
that version.  Emacs could even pull packages using these tags from ELPA
if the user first decided to install the latest version and then wants
to go back to the "built-in" package version.

And release branches would be the way to handle code freezes.

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: org-export raises stringp nil error

[Jambunathan K]

Nick Dokos <nicholas.dokos@hp.com> 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: org-export raises stringp nil error

[Bastien]

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> Bastien <bzg@altern.org> wrote:
>
>> Hi Xue,
>> 
>> Xue Fuqiao <xfq.free@gmail.com> 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: org-export raises stringp nil error

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Nick Dokos <nicholas.dokos@hp.com> 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: org-export raises stringp nil error

[Nick Dokos]

Bastien <bzg@gnu.org> wrote:

> Jambunathan K <kjambunathan@gmail.com> writes:
> 
> > Nick Dokos <nicholas.dokos@hp.com> 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: org-export raises stringp nil error

[Jambunathan K]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Bastien <bzg@gnu.org> wrote:
>
>> Jambunathan K <kjambunathan@gmail.com> writes:
>> 
>> > Nick Dokos <nicholas.dokos@hp.com> 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 login@git.sv.gnu.org:/srv/git/project.git
| 
`----

> Thanks,
> Nick
>
>
>

-- 

Re: org-export raises stringp nil error

[Nick Dokos]

Jambunathan K <kjambunathan@gmail.com> 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: org-export raises stringp nil error

[Achim Gratz]

Nick Dokos writes:
> o is the savannah repo http only? 

This is my configuration for the savannah Git mirror:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git://git.savannah.gnu.org/emacs.git

So no, I don't think it is HTTP only, not for me anyway.  :-)

> o and if so, it used to be the case that http was much slower than git -
>   is that still the case?

Yes, mainly because it needs to pull more information to get to the same
result and get a new connection for each step along the way, which also
determines how much it is "much slower".  But that's mostly a problem
for the server side unless you are on a metered service or have a
_really_ slow connection.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: org-export raises stringp nil error

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> 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: org-export raises stringp nil error

[Dmitry Gutov]

On 08.03.2013 18:06, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Cc: lele@metapensiero.it,  joakim@verona.se,  emacs-devel@gnu.org,  bzg@gnu.org,  emacs-orgmode@gnu.org,  sdl.web@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: org-export raises stringp nil error

[Xue Fuqiao]

On Fri, 08 Mar 2013 11:29:23 -0500
Nick Dokos <nicholas.dokos@hp.com> wrote:

> Bastien <bzg@altern.org> wrote:
> > Xue Fuqiao <xfq.free@gmail.com> 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