org-export raises stringp nil error

org-export raises stringp nil error

[Lele Gaifax]

Hi all,

first of all, apologies if this is not the right place for the
following...

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
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

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 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

[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

[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

[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: 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

[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

[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

[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

[Achim Gratz]

[please keep on emacs.devel]

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

Please enlighten me as to what this experiment was and when it happened
so I can read up on it.  This is a sincere request, I have no desire to
repeat a past mistake.

Note that I haven't said anything about what is core and what is not,
that issue is orthogonal to how Emacs' structures its software
repositories.  Off the cuff I'd say we'd end up with roughly the same
set of "core" packages than today, then grow from there.

What I am talking about is reducing the interdependencies between
projects on wildly different release schedules for the purpose of making
the integration easier.  That requires effort on both sides, but I posit
that there is a net gain — if there is agreement on how to do this and
an easily followed set of rules that describes the procedures.

> Good luck (you will need it)!

This is engineering, not gaming (although I wouldn't mind a bit of luck
once in a while).



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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: org-export raises stringp nil error

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Fri, 08 Mar 2013 21:09:36 +0100
> 
> Eli Zaretskii writes:
> >> 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".
> 
> Please enlighten me as to what this experiment was and when it happened
> so I can read up on it.  This is a sincere request, I have no desire to
> repeat a past mistake.

I meant XEmacs.  I'll ask Stephen to describe that and suggest any
conclusions from that experience, including those which contradict my
personal conclusions.

> Note that I haven't said anything about what is core and what is not,
> that issue is orthogonal to how Emacs' structures its software
> repositories.  Off the cuff I'd say we'd end up with roughly the same
> set of "core" packages than today, then grow from there.

I don't understand what that means.  There's no "core" packages today,
the entire Emacs repository is handled as one monolith piece of
software.  The fact that some parts of it are copies of upstream
repositories maintained by others elsewhere is not relevant to the
issues I have with separating them from Emacs.

> What I am talking about is reducing the interdependencies between
> projects on wildly different release schedules for the purpose of making
> the integration easier.  That requires effort on both sides, but I posit
> that there is a net gain — if there is agreement on how to do this and
> an easily followed set of rules that describes the procedures.

Your optimism in this matter is enviable, but my gray hair doesn't let
me share it.  I don't believe in any net gain here.  I don't know why
is that so, perhaps because complexity tends to disrupt any hope of
reaching an "agreement on how to do this" and having "an easily
followed set of rules that describes the procedures".  Heck, we
couldn't even agree on the VCS to use, remember?

> > Good luck (you will need it)!
> 
> This is engineering, not gaming (although I wouldn't mind a bit of luck
> once in a while).

If you don't believe in luck in software engineering, just stick
around for a while.

Re: org-export raises stringp nil error

[Achim Gratz]

Eli Zaretskii writes:
> I meant XEmacs.  I'll ask Stephen to describe that and suggest any
> conclusions from that experience, including those which contradict my
> personal conclusions.

Thank you.

> I don't understand what that means.  There's no "core" packages today,
> the entire Emacs repository is handled as one monolith piece of
> software.  The fact that some parts of it are copies of upstream
> repositories maintained by others elsewhere is not relevant to the
> issues I have with separating them from Emacs.

If you made some directories subprojects (in Git parlance; bizarr
probably also has something that is almost, but not entirely unlike it),
your Emacs checkout would look exactly the same as today.  What would
change is that if you fixed a bug in e.g. Org, you would fix it in the
Emacs branch of the Org repository and then commit the subproject within
Emacs pointing to the new head that contains the fix.

Now, properly making these replaceable with newer (or maybe even older)
ELPA packages obviously requires some extra steps away from the status
quo, but again these have nothing to do with "which repo does that
directory come from".

> Your optimism in this matter is enviable, but my gray hair doesn't let
> me share it.

It has been a while that someone called me an optimist, so thank you.
Also, I have enough gray hair of my own, so you don't need to share it.
:-)

> I don't believe in any net gain here.  I don't know why is that so,
> perhaps because complexity tends to disrupt any hope of reaching an
> "agreement on how to do this" and having "an easily followed set of
> rules that describes the procedures".  Heck, we couldn't even agree on
> the VCS to use, remember?

I'll concede you this point.  No, I don't expect any new arrangement to
be friction-less, but maybe a less so than the current one.


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

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sat, 09 Mar 2013 12:07:50 +0100
> 
> If you made some directories subprojects (in Git parlance; bizarr
> probably also has something that is almost, but not entirely unlike it),
> your Emacs checkout would look exactly the same as today.  What would
> change is that if you fixed a bug in e.g. Org, you would fix it in the
> Emacs branch of the Org repository and then commit the subproject within
> Emacs pointing to the new head that contains the fix.

That will work, but only if the same VCS is used by all the projects.

Re: org-export raises stringp nil error

[Stephen J. Turnbull]

Achim Gratz writes:

 > If you made some directories subprojects (in Git parlance; bizarr
 > probably also has something that is almost, but not entirely unlike it),

IIRC, it doesn't, unfortunately.  (Mercurial does, but not Bazaar.)

Re: org-export raises stringp nil error

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > > 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".

[...]

 > I meant XEmacs.  I'll ask Stephen to describe that and suggest any
 > conclusions from that experience, including those which contradict my
 > personal conclusions.

You've spent too much time listening to David Kastrup, and not really
understanding what he was saying, I think.  Splitting XEmacs into core
and packages was a success, and still is.[1][2]  Nobody ever suggests
going back in general, although there are often suggestions that very
specific functionality be moved back into core.  Occasionally package
maintainers drop out because they don't like constraints of the XEmacs
distribution framework, and we can't find a volunteer to take over for
them.  Still, people are much more interested in adding functionality
or moving implementation from C to Lisp than in refactoring the
packages.

One interesting fact, however, is that the single most-requested
feature for the packages is a single tarball containing both the core
sources and the current SUMOs.  About what somebody suggested, moving
most applications like Gnus and CEDET into GNU ELPA, and distributing
some approximation to ELPA's head version with Emacs.

 > Your optimism in this matter is enviable, but my gray hair doesn't let
 > me share it.  I don't believe in any net gain here.

That's probably because the gains would not be shared equally.  Quite
likely core development would suffer a bit.  (1) Especially if the
ELPA packages are distributed with Emacs, releases would take more
effort.  (2) Probably a volunteer maintainer for the ELPA will be
needed.  (3) Changes to APIs that are currently treated as "internal"
will get more pushback, especially as packages that are currently deep
in "3rd party" territory join ELPA, and get more exposure and
popularity, but their maintainers can't afford to keep up with Emacs
changes.  (4) A few developers who now have to hang out on emacs-devel
to find out whether they're allowed commit won't bother.  These
effects are going to be second-order, though, because package
maintainers will still need to come to emacs-devel to get new features
they need.

The packages, OTOH, have little to lose, and they will enjoy their
freedom to release on their own schedule.  Thing is, there are a lot
of packages, and only one core.  For the whole community it would be a
gain, a significant one, I think.


Footnotes: 
[1]  In large part thanks to Norbert Koch, who handles package
releases for us.

[2]  XEmacs' big problems are political (people who work on Emacsen
tend to be on the "F" side of "FLOSS" rather than the "O" side), and
that we had to spend a huge amount of effort trying to maintain GNU
compatibility, but on the other hand our features didn't much attract
most third party developers because they couldn't use them on Emacs
... and once Emacs *did* get them, it chose to provide them with
incompatible APIs.  We never managed to come up with a real killer
feature such that Emacs users and developers *had* to use XEmacs; for
the majority of XEmacs users and contributors it was only marginally
better than Emacs.  Enough to get many to switch in its heyday (of
course the long release drought of the early 1990s had a lot to do
with that), though.

So, yes, if the fork were an "experiment", in that sense it is
failing.  The market wants Emacs (for good and sufficient reason), not
XEmacs.  But XEmacs has its fans (also for good reason).

Re: org-export raises stringp nil error

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Achim Gratz <Stromeko@nexgo.de>,
>     emacs-devel@gnu.org
> Date: Sun, 10 Mar 2013 02:53:26 +0900
> 
> You've spent too much time listening to David Kastrup, and not really
> understanding what he was saying, I think.

No, I've read the relevant discussions (quite some time ago) and made
my own conclusions.

> So, yes, if the fork were an "experiment", in that sense it is
> failing.

I was only talking about the core and packages in XEmacs, not about
the fork.

Re: org-export raises stringp nil error

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > You've spent too much time listening to David Kastrup, and not really
 > > understanding what he was saying, I think.
 > 
 > No, I've read the relevant discussions (quite some time ago) and made
 > my own conclusions.

I'm not sure what discussions you think are relevant.  If they're not
the ones with David, which do you have in mind?

Once again, I have never seen any post like "if only it were easy to
merge the packages back into the core, we'd really should do that."

 > > So, yes, if the fork were an "experiment", in that sense it is
 > > failing.
 > 
 > I was only talking about the core and packages in XEmacs, not about
 > the fork.

If so, I have no idea why you came to the conclusion it's a failed
experiment.
  

Re: org-export raises stringp nil error

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Stromeko@nexgo.de,
>     emacs-devel@gnu.org
> Date: Sun, 10 Mar 2013 21:41:57 +0900
> 
> Eli Zaretskii writes:
> 
>  > > You've spent too much time listening to David Kastrup, and not really
>  > > understanding what he was saying, I think.
>  > 
>  > No, I've read the relevant discussions (quite some time ago) and made
>  > my own conclusions.
> 
> I'm not sure what discussions you think are relevant.  If they're not
> the ones with David, which do you have in mind?

I no longer remember, as it was long ago.  I'm sure people who are
interested can find them.  I vaguely remember that at least some of
them were on this list.

>  > > So, yes, if the fork were an "experiment", in that sense it is
>  > > failing.
>  > 
>  > I was only talking about the core and packages in XEmacs, not about
>  > the fork.
> 
> If so, I have no idea why you came to the conclusion it's a failed
> experiment.

Because many (most?) users want the whole deal.  As one Stephen
Turnbull says on this page:

  http://www.xemacs.org/Releases/Public-21.2/projects/sumo.html

and I quote: "The packages are popular, but the typical user of the
core tarball wants the kitchen sink."

Re: org-export raises stringp nil error

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > If so, I have no idea why you came to the conclusion it's a failed
 > > experiment.
 > 
 > Because many (most?) users want the whole deal.  As one Stephen
 > Turnbull says on this page:
 > 
 >   http://www.xemacs.org/Releases/Public-21.2/projects/sumo.html
 > 
 > and I quote: "The packages are popular, but the typical user of the
 > core tarball wants the kitchen sink."

Yeah, I already mentioned that in this thread, too.

It doesn't mean that separation of core and packages failed, because
there are *ongoing* advantages to a package system that can be updated
at one's convenience.  It means that *people who are installing XEmacs
for the first time* find the additional download inconvenient.[1]
After that, those who speak up (and some do even without having a bug
to report) say they enjoy the fact that they can update their favorite
packages without reinstalling the core.

In any case, it's easy enough to address conceptually by just
including a reasonably fresh sumo tarball in the core tarball.  It
hasn't been done because beta testers generally don't care (they use
Mercurial, anyway), the stability constraints on 21.4 are severe, and
in any case most distros provide a good installation for those who
just want an editor that works.


Footnotes: 
[1]  That page was also written at a time when we still followed the
old Emacs convention of Lisp under $prefix/lib, while the FLOSS world,
including popular distros, was moving to $prefix/share for FHS
conformance.  This resulted in a fair amount of confusion about where
to find the packages for new users, especially those moving from
distro-provided packages to building from source and SUMO.

Re: org-export raises stringp nil error

[Bastien]

Hi Stephen,

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> The packages, OTOH, have little to lose, and they will enjoy their
> freedom to release on their own schedule.

Just a note on this: being part of Emacs does not put any constraint
on Org's release schedule.

When the last Org version cannot be part of Emacs (e.g. because of
a feature freeze), we just need to maintain a dedicated branch for
changes that will end up in Emacs.  But we can release Org major
versions when we want.

Of course, when the Org release is far ahead of the Org version that
comes with Emacs, users want to use the last stable version and update 
through GNU ELPA or by installing Org separately.  And the incentive
for maintainers to update Org within Emacs frequently decreases...

But this has no real impact on Org's schedule I think.

2 cts,

-- 
 Bastien

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

[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

[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

[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: [O] 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: [O] 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: [O] 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: [O] 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: [O] 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: [O] 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: [O] 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: [O] 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: [O] 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

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

[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: "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

[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]

> 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

[Bastien]

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

-- 
 Bastien

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

[Xue Fuqiao]

On 03/08/2013 02:19 AM, Lele Gaifax wrote:

> first of all, apologies if this is not the right place for the
> following...

Post it to bug-gnu-emacs when this is with Org's from Emacs, to 
emacs-orgmode otherwise.

> 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 :fo
 r-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?

I have the same problom on rev-111964.  And there already seems to be 
some reports:
http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00028.html
http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00179.html

I think it is a bug on Org.

> [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

BTW the Debian bug tracker[1] is the prime place to report bugs in emacs 
packages.

[1] http://www.debian.org/Bugs/
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao