Org release 8.2.5g (minor release from maint)

Org release 8.2.5g (minor release from maint)

[Bastien]

Hi all,

I released Org 8.2.5g, which fixes several bugs.

  http://orgmode.org

Please heavily test this release and report important bugs.

Then we will release Org 8.2.6 and sync it with Emacs trunk,
so that Emacs 24.4 contains a very stable version.

Thanks!

-- 
 Bastien

Re: Org release 8.2.5g (minor release from maint)

[Achim Gratz]

Bastien writes:
> Hi all,
>
> I released Org 8.2.5g, which fixes several bugs.
>
>   http://orgmode.org
>
> Please heavily test this release and report important bugs.

The tag for release_8.2.5e is on the wrong branch (you tagged the merge
instead of the last commit in maint (that would be 0a8fe04a9d).

Commit 6c0992939d introduces a cl-used-at-runtime bug (subseq is a
defun, not a macro).  The construct might be replaceable by

(car pre-info) (cadr pre-info)

in the first instance and

(nthcdr 3 pre-info)

in the second or the cdr of the second element of pre-info might
directly get the new value spliced in depending on whether the original
value is used someplace else.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Org release 8.2.5g (minor release from maint)

[Bastien]

Hi Achim,

Thanks for reporting these problems.

Since you have commit access and the fixes seem non problematic,
I'd say feel free to fix them directly--reporting them if still
useful of course, it helps us not repeating them :)

Thanks,

-- 
 Bastien

Re: Org release 8.2.5g (minor release from maint)

[Bastien]

Bastien <bzg@gnu.org> writes:

> I'd say feel free to fix them directly--reporting them if still
> useful of course, it helps us not repeating them :)

s/if/is !

-- 
 Bastien

Re: Org release 8.2.5g (minor release from maint)

[Achim Gratz]

Bastien writes:
> Since you have commit access and the fixes seem non problematic,
> I'd say feel free to fix them directly--reporting them if still
> useful of course, it helps us not repeating them :)

I didn't fix these for two reasons:

1) I didn't touch the tag because I couldn't sign it.

2) I'm not entirely certain if some of the side-effects that subseq
seems to have are in any way crucial to the behaviour that Eric was
implementing.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Org release 8.2.5g (minor release from maint)

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> The tag for release_8.2.5e is on the wrong branch (you tagged the merge
> instead of the last commit in maint (that would be 0a8fe04a9d).

Actually I don't understand: the release_8.2.5e tag appears on
e7ebe4163a, and 0a8fe04a9d is the merge commit.

http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=e7ebe4163a
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=0a8fe04a9d

What's wrong exactly?

> Commit 6c0992939d introduces a cl-used-at-runtime bug (subseq is a
> defun, not a macro).

I'll let Eric have a look at this one.

-- 
 Bastien

Re: Org release 8.2.5g (minor release from maint)

[Achim Gratz]

Bastien <bzg <at> gnu.org> writes:
> > The tag for release_8.2.5e is on the wrong branch (you tagged the merge
> > instead of the last commit in maint (that would be 0a8fe04a9d).
> 
> Actually I don't understand: the release_8.2.5e tag appears on
> e7ebe4163a, and 0a8fe04a9d is the merge commit.

You apparently moved the tag after I already had fetched it.

> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=e7ebe4163a
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=0a8fe04a9d
> 
> What's wrong exactly?

I have that tag on a different commit (8898c380ab).  Whenever you re-tag
anything in the master repo you need to say so, tag updates are not fetched
automatically.


Regards,
Achim.

Re: Org release 8.2.5g (minor release from maint)

[Achim Gratz]

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

Achim Gratz writes:
[…]
> in the second or the cdr of the second element of pre-info might
> directly get the new value spliced in depending on whether the original
> value is used someplace else.

Splicing seems slightly more elegant than list construction, but
pre-info needs to be preserved.  Eric, please review the attached patch,
I'm not certain about the current test coverage in that area.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ob-lob-do-not-use-cl-at-runtime.patch --]
[-- Type: text/x-patch, Size: 1550 bytes --]

From 024e05c4de3c7598448ee97b0f986562007d5186 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sat, 25 Jan 2014 08:53:33 +0100
Subject: [PATCH] ob-lob: do not use cl at runtime

* lisp/ob-lob.el (org-babel-lob-execute): Do not use defun subseq from
  cl at runtime.  Replace concatenation of sub-sequences by splicing
  the modified params list into a copy of info (pre-must info be
  preserved).
---
 lisp/ob-lob.el | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index c93198a..6480468 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -147,13 +147,14 @@ (defun org-babel-lob-execute (info)
 		      ;; Do *not* pre-process params for call line
 		      ;; hash evaluation, since for a call line :var
 		      ;; extension *is* execution.
-		      (let ((params (nth 2 pre-info)))
-			(append (subseq pre-info 0 2)
-				(list
-				 (cons
-				  (cons :c-var (cdr (assoc :var params)))
-				  (assq-delete-all :var (copy-tree params))))
-				(subseq pre-info 3))))))
+		      (let* ((params (nth 2 pre-info))
+			     (sha1-nth2 (list
+				    (cons
+				     (cons :c-var (cdr (assoc :var params)))
+				     (assq-delete-all :var (copy-tree params)))))
+			     (sha1-info (copy-tree pre-info)))
+			(prog1 sha1-info
+			  (setcar (cddr sha1-info) sha1-nth2))))))
 	 (old-hash (when cache-p (org-babel-current-result-hash pre-info)))
 	 (org-babel-current-src-block-location (point-marker)))
     (if (and cache-p (equal new-hash old-hash))
-- 
1.8.5.2


[-- Attachment #3: Type: text/plain, Size: 197 bytes --]



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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Org release 8.2.5g (minor release from maint)

[Achim Gratz]

Achim Gratz writes:
> Splicing seems slightly more elegant than list construction, but
> pre-info needs to be preserved.  Eric, please review the attached patch,
> I'm not certain about the current test coverage in that area.

I see that this bug remains unfixed.  Eric, could you please have a
look?


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Org release 8.2.5g (minor release from maint)

[Eric Schulte]

Achim Gratz <Stromeko@nexgo.de> writes:

> Achim Gratz writes:
> […]
>> in the second or the cdr of the second element of pre-info might
>> directly get the new value spliced in depending on whether the original
>> value is used someplace else.
>
> Splicing seems slightly more elegant than list construction, but
> pre-info needs to be preserved.  Eric, please review the attached patch,
> I'm not certain about the current test coverage in that area.
>

Oh, I did not realize `subseq' was part of the cl library.  Since it
seems subseq is a generally useful utility, would there be any appetite
for implementing an org-subseq function?

I look forward to the day when Org-mode can simply require cl-lib and
cease maintaining org- versions of common cl utilities.

Thanks,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: Org release 8.2.5g (minor release from maint)

[Bastien]

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

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Oh, I did not realize `subseq' was part of the cl library.  Since it
> seems subseq is a generally useful utility, would there be any appetite
> for implementing an org-subseq function?

There was already org-sublist, which I adapted to mimic the behavior
of subseq.

Can you try the attached patch and see if it works as advertized?

Thanks,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-subseq.patch --]
[-- Type: text/x-diff, Size: 2361 bytes --]

Changes in stash@{0}^2^..stash@{0}
3 files changed, 10 insertions(+), 9 deletions(-)
 lisp/ob-lob.el    |  4 ++--
 lisp/org-table.el |  4 ++--
 lisp/org.el       | 11 ++++++-----

	Modified   lisp/ob-lob.el
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index c93198a..210dbb4 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -148,12 +148,12 @@ if so then run the appropriate source block from the Library."
 		      ;; hash evaluation, since for a call line :var
 		      ;; extension *is* execution.
 		      (let ((params (nth 2 pre-info)))
-			(append (subseq pre-info 0 2)
+			(append (org-subseq pre-info 0 2)
 				(list
 				 (cons
 				  (cons :c-var (cdr (assoc :var params)))
 				  (assq-delete-all :var (copy-tree params))))
-				(subseq pre-info 3))))))
+				(org-subseq pre-info 3))))))
 	 (old-hash (when cache-p (org-babel-current-result-hash pre-info)))
 	 (org-babel-current-src-block-location (point-marker)))
     (if (and cache-p (equal new-hash old-hash))
	Modified   lisp/org-table.el
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 520ac8a..38a9171 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -2698,8 +2698,8 @@ not overwrite the stored one."
 		(replace-match
 		 (save-match-data
 		   (org-table-make-reference
-		    (org-sublist
-		     fields (string-to-number (match-string 1 form))
+		    (org-subseq
+		     fields (1- (string-to-number (match-string 1 form)))
 		     (string-to-number (match-string 2 form)))
 		    keep-empty numbers lispp))
 		 t t form)))
	Modified   lisp/org.el
diff --git a/lisp/org.el b/lisp/org.el
index 41fb22c..32f27b1 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -22059,12 +22059,13 @@ so values can contain further %-escapes if they are define later in TABLE."
 	  (setq string (replace-match sref t t string)))))
     string))
 
-(defun org-sublist (list start end)
+;; This reimplements subseq from cl-subseq
+(defun org-subseq (list start &optional end)
   "Return a section of LIST, from START to END.
-Counting starts at 1."
-  (let (rtn (c start))
-    (setq list (nthcdr (1- start) list))
-    (while (and list (<= c end))
+END is optional and counting starts at 0."
+  (let ((c start) (end (or end (length list))) rtn)
+    (setq list (nthcdr start list))
+    (while (and list (< c end))
       (push (pop list) rtn)
       (setq c (1+ c)))
     (nreverse rtn)))


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


-- 
 Bastien

Re: Org release 8.2.5g (minor release from maint)

[Achim Gratz]

Eric Schulte writes:
> Oh, I did not realize `subseq' was part of the cl library.  Since it
> seems subseq is a generally useful utility, would there be any appetite
> for implementing an org-subseq function?

No, please.  Besides, copying the info structure twice to splice in one
changed element seems wasteful with or without using sublist.

> I look forward to the day when Org-mode can simply require cl-lib and
> cease maintaining org- versions of common cl utilities.

WIth cl-lib in ELPA I don't really see what's the holdup there if you
want to go that route.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Org release 8.2.5g (minor release from maint)

[Nick Dokos]

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:

>> I look forward to the day when Org-mode can simply require cl-lib and
>> cease maintaining org- versions of common cl utilities.
>
> WIth cl-lib in ELPA I don't really see what's the holdup there if you
> want to go that route.

I have the impression that cl-lib is (was?) frowned upon by upstream for
packages that are included in the emacs distribution. But it's only
a vague recollection at this point: am I wrong? am I thinking of
something else common-lispish?

-- 
Nick

Re: Org release 8.2.5g (minor release from maint)

[Eric Schulte]

Nick Dokos <ndokos@gmail.com> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Eric Schulte writes:
>
>>> I look forward to the day when Org-mode can simply require cl-lib and
>>> cease maintaining org- versions of common cl utilities.
>>
>> WIth cl-lib in ELPA I don't really see what's the holdup there if you
>> want to go that route.
>
> I have the impression that cl-lib is (was?) frowned upon by upstream for
> packages that are included in the emacs distribution. But it's only
> a vague recollection at this point: am I wrong? am I thinking of
> something else common-lispish?

I thought that the point of cl-lib was so that packages like Org-mode
and gnus would stop re-implementing pieces of the cl package.  I could
easily be wrong.

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: Org release 8.2.5g (minor release from maint)

[Eric Abrahamsen]

Eric Schulte <schulte.eric@gmail.com> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>
>>> Eric Schulte writes:
>>
>>>> I look forward to the day when Org-mode can simply require cl-lib and
>>>> cease maintaining org- versions of common cl utilities.
>>>
>>> WIth cl-lib in ELPA I don't really see what's the holdup there if you
>>> want to go that route.
>>
>> I have the impression that cl-lib is (was?) frowned upon by upstream for
>> packages that are included in the emacs distribution. But it's only
>> a vague recollection at this point: am I wrong? am I thinking of
>> something else common-lispish?
>
> I thought that the point of cl-lib was so that packages like Org-mode
> and gnus would stop re-implementing pieces of the cl package.  I could
> easily be wrong.

I remembered seeing something on emacs-devel about this, and just found
this statement from Stefan Monnier from a few days ago:


Note that the main motivation behind the move to cl-lib is so that it's
perfectly acceptable to use cl-lib functions (since they don't pollute
the global namespace any more).  So if you prefer to avoid cl-lib
functions, that's fine, but if you want to use them, that's perfectly
fine as well.


        Stefan

Interpret as you will!

Re: Org release 8.2.5g (minor release from maint)

[Nick Dokos]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>>> I have the impression that cl-lib is (was?) frowned upon by upstream for
>>> packages that are included in the emacs distribution. But it's only
>>> a vague recollection at this point: am I wrong? am I thinking of
>>> something else common-lispish?
>>
>> I thought that the point of cl-lib was so that packages like Org-mode
>> and gnus would stop re-implementing pieces of the cl package.  I could
>> easily be wrong.
>
> I remembered seeing something on emacs-devel about this, and just found
> this statement from Stefan Monnier from a few days ago:
>
>
> Note that the main motivation behind the move to cl-lib is so that it's
> perfectly acceptable to use cl-lib functions (since they don't pollute
> the global namespace any more).  So if you prefer to avoid cl-lib
> functions, that's fine, but if you want to use them, that's perfectly
> fine as well.
>
>
>         Stefan
>
> Interpret as you will!
>
>

Thanks for putting me right!

-- 
Nick

Re: Org release 8.2.5g (minor release from maint)

[Eric Schulte]

Nick Dokos <ndokos@gmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>>> I have the impression that cl-lib is (was?) frowned upon by upstream for
>>>> packages that are included in the emacs distribution. But it's only
>>>> a vague recollection at this point: am I wrong? am I thinking of
>>>> something else common-lispish?
>>>
>>> I thought that the point of cl-lib was so that packages like Org-mode
>>> and gnus would stop re-implementing pieces of the cl package.  I could
>>> easily be wrong.
>>
>> I remembered seeing something on emacs-devel about this, and just found
>> this statement from Stefan Monnier from a few days ago:
>>
>>
>> Note that the main motivation behind the move to cl-lib is so that it's
>> perfectly acceptable to use cl-lib functions (since they don't pollute
>> the global namespace any more).  So if you prefer to avoid cl-lib
>> functions, that's fine, but if you want to use them, that's perfectly
>> fine as well.
>>
>>
>>         Stefan
>>
>> Interpret as you will!
>>
>>
>
> Thanks for putting me right!

Great, so should Org-mode require cl-lib and stop supporting the
following functions?

- org-block
- org-count
- org-every
- org-find-if
- org-reduce
- org-remove-if
- org-remove-if-not
- org-return
- org-some
- org-sort
- org-sublist

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: Org release 8.2.5g (minor release from maint)

[Bastien]

Hi Eric and Nick,

Eric Schulte <schulte.eric@gmail.com> writes:

> Great, so should Org-mode require cl-lib and stop supporting the
> following functions?

I guess so.  But I'm unclear yet whether this removes compatibility
with older Emacsen.  I'll check this.

-- 
 Bastien

Re: Org release 8.2.5g (minor release from maint)

[Richard Lawrence]

Bastien <bzg@gnu.org> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Great, so should Org-mode require cl-lib and stop supporting the
>> following functions?
>
> I guess so.  But I'm unclear yet whether this removes compatibility
> with older Emacsen.  I'll check this.

I believe it does remove compatibility with anything pre-24.0.  At
least, there is no cl-lib in GNU Emacs 23.4.1, which is the version
currently in Debian stable.

I am one small voice, but as a user who prefers Debian stable but also
the maint branch of Org, I'd request that you avoid a hard dependency on
cl-lib for a while longer, maybe at least until Emacs 24 is the default
in major distro's package systems?

Best,
Richard

Re: Org release 8.2.5g (minor release from maint)

[Eric Schulte]

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>> Great, so should Org-mode require cl-lib and stop supporting the
>>> following functions?
>>
>> I guess so.  But I'm unclear yet whether this removes compatibility
>> with older Emacsen.  I'll check this.
>
> I believe it does remove compatibility with anything pre-24.0.  At
> least, there is no cl-lib in GNU Emacs 23.4.1, which is the version
> currently in Debian stable.
>

With cl-lib installable as a library through ELPA, would requiring it as
a dependency be acceptable?  I suppose Org-mode doesn't currently have
any dependencies, so it might not be worth adding one just to remove
some redundant functions.

>
> I am one small voice, but as a user who prefers Debian stable but also
> the maint branch of Org, I'd request that you avoid a hard dependency on
> cl-lib for a while longer, maybe at least until Emacs 24 is the default
> in major distro's package systems?
>

I agree it would be bad to lose compatibility of the master branch with
older Emacsen.

>
> Best,
> Richard
>

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: Org release 8.2.5g (minor release from maint)

[Richard Lawrence]

Eric Schulte <schulte.eric@gmail.com> writes:

> With cl-lib installable as a library through ELPA, would requiring it as
> a dependency be acceptable?  I suppose Org-mode doesn't currently have
> any dependencies, so it might not be worth adding one just to remove
> some redundant functions.

Well, there's no ELPA in Emacs pre-24.0 either, at least not built-in.
So a dependency on ELPA/package.el is not really any better than a
dependency on cl-lib for folks like me. 

Best,
Richard

Re: Org release 8.2.5g (minor release from maint)

[Bastien]

Hi Richard,

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>> Great, so should Org-mode require cl-lib and stop supporting the
>>> following functions?
>>
>> I guess so.  But I'm unclear yet whether this removes compatibility
>> with older Emacsen.  I'll check this.
>
> I believe it does remove compatibility with anything pre-24.0.  At
> least, there is no cl-lib in GNU Emacs 23.4.1, which is the version
> currently in Debian stable.

Any reason why Debian developers are not using 24.3 as the stable
version of Emacs?  It has been out for now one year.

Otherwise yes, let's try to stay as much backward-compatible as
possible.

-- 
 Bastien

Re: Org release 8.2.5g (minor release from maint)

[Richard Lawrence]

Hi Bastien,

Bastien <bzg@gnu.org> writes:

> Any reason why Debian developers are not using 24.3 as the stable
> version of Emacs?  It has been out for now one year.

Well, the way that the Debian stable release works is that they ship the
latest stable version of a package which is available at the time of
their pre-release "freeze".  After the freeze, packages only receive
updates for critical bugs and security fixes for the lifetime of the
release.

The current release (Debian Wheezy) was frozen on 2012-06-30 and
released 2013-05-04. I think Emacs 24 probably just barely missed the
Wheezy release, as 24.1 was released 2012-06-10.  My guess is that the
Debian maintainers either didn't consider 24.1 stable enough yet for
Wheezy, or they just weren't sure and didn't want to take the chance.

The next release (Jessie) is not yet frozen, and some post-24 Emacs will
certainly be included when it is.

Anyway, I don't think Org should be beholden to distributions' release
cycles in general.  Users like me who are happy with an older Emacs but
want a newer Org are probably a very small minority (but speak up if
you're out there!).  And for these users, it is probably only a minor
inconvenience to have to install cl-lib or a newer Emacs.  That is at
least true in my case.  If introducing a dependency on cl-lib right now
will be the best thing for Org, I have no real objections; if it can be
put off for a while without significant cost, that would be great, but
it isn't necessary.

Best,
Richard

Re: Org release 8.2.5g (minor release from maint)

[Bastien]

Hi Richard,

thanks for your detailed account on The Debian Way.

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> If introducing a dependency on cl-lib right now
> will be the best thing for Org, I have no real objections; if it can be
> put off for a while without significant cost, that would be great, but
> it isn't necessary.

I suggest we make this happen for Org 9.0.

The big version number will be scary enough to make people carefully
check backward compatibility issues.

We could even stick to this policy: no backward compatibility issue
between minor (i.e. X.X) versions.  I think it's close to what we've
been doing so far.

In the meantime, I suggest we add a comment on top of compatibility
functions that we might remove in Org 9.0.

Eric, could you do that based on the list you provided?

Thanks to both,

-- 
 Bastien