emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Org release 8.2.5g (minor release from maint)
@ 2014-01-21 13:50 Bastien
  2014-01-21 19:16 ` Achim Gratz
  0 siblings, 1 reply; 24+ messages in thread
From: Bastien @ 2014-01-21 13:50 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-21 13:50 Org release 8.2.5g (minor release from maint) Bastien
@ 2014-01-21 19:16 ` Achim Gratz
  2014-01-21 19:25   ` Bastien
                     ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Achim Gratz @ 2014-01-21 19:16 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-21 19:16 ` Achim Gratz
@ 2014-01-21 19:25   ` Bastien
  2014-01-21 19:30     ` Bastien
  2014-01-21 19:35     ` Achim Gratz
  2014-01-21 23:39   ` Bastien
  2014-01-25  7:58   ` Achim Gratz
  2 siblings, 2 replies; 24+ messages in thread
From: Bastien @ 2014-01-21 19:25 UTC (permalink / raw)
  To: Achim Gratz; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-21 19:25   ` Bastien
@ 2014-01-21 19:30     ` Bastien
  2014-01-21 19:35     ` Achim Gratz
  1 sibling, 0 replies; 24+ messages in thread
From: Bastien @ 2014-01-21 19:30 UTC (permalink / raw)
  To: Achim Gratz; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-21 19:25   ` Bastien
  2014-01-21 19:30     ` Bastien
@ 2014-01-21 19:35     ` Achim Gratz
  1 sibling, 0 replies; 24+ messages in thread
From: Achim Gratz @ 2014-01-21 19:35 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-21 19:16 ` Achim Gratz
  2014-01-21 19:25   ` Bastien
@ 2014-01-21 23:39   ` Bastien
  2014-01-22  7:52     ` Achim Gratz
  2014-01-25  7:58   ` Achim Gratz
  2 siblings, 1 reply; 24+ messages in thread
From: Bastien @ 2014-01-21 23:39 UTC (permalink / raw)
  To: Achim Gratz; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-21 23:39   ` Bastien
@ 2014-01-22  7:52     ` Achim Gratz
  0 siblings, 0 replies; 24+ messages in thread
From: Achim Gratz @ 2014-01-22  7:52 UTC (permalink / raw)
  To: emacs-orgmode

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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-21 19:16 ` Achim Gratz
  2014-01-21 19:25   ` Bastien
  2014-01-21 23:39   ` Bastien
@ 2014-01-25  7:58   ` Achim Gratz
  2014-02-26 19:25     ` Achim Gratz
  2014-02-26 23:23     ` Eric Schulte
  2 siblings, 2 replies; 24+ messages in thread
From: Achim Gratz @ 2014-01-25  7:58 UTC (permalink / raw)
  To: emacs-orgmode; +Cc: Eric Schulte

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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-25  7:58   ` Achim Gratz
@ 2014-02-26 19:25     ` Achim Gratz
  2014-02-26 23:23     ` Eric Schulte
  1 sibling, 0 replies; 24+ messages in thread
From: Achim Gratz @ 2014-02-26 19:25 UTC (permalink / raw)
  To: emacs-orgmode; +Cc: Eric Schulte

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-01-25  7:58   ` Achim Gratz
  2014-02-26 19:25     ` Achim Gratz
@ 2014-02-26 23:23     ` Eric Schulte
  2014-03-01  8:06       ` Bastien
  2014-03-01  9:10       ` Achim Gratz
  1 sibling, 2 replies; 24+ messages in thread
From: Eric Schulte @ 2014-02-26 23:23 UTC (permalink / raw)
  To: Achim Gratz; +Cc: emacs-orgmode, 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-02-26 23:23     ` Eric Schulte
@ 2014-03-01  8:06       ` Bastien
  2014-03-01  9:10       ` Achim Gratz
  1 sibling, 0 replies; 24+ messages in thread
From: Bastien @ 2014-03-01  8:06 UTC (permalink / raw)
  To: Eric Schulte; +Cc: Achim Gratz, emacs-orgmode

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

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-02-26 23:23     ` Eric Schulte
  2014-03-01  8:06       ` Bastien
@ 2014-03-01  9:10       ` Achim Gratz
  2014-03-01 12:53         ` Nick Dokos
  1 sibling, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-03-01  9:10 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-01  9:10       ` Achim Gratz
@ 2014-03-01 12:53         ` Nick Dokos
  2014-03-03  3:03           ` Eric Schulte
  0 siblings, 1 reply; 24+ messages in thread
From: Nick Dokos @ 2014-03-01 12:53 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-01 12:53         ` Nick Dokos
@ 2014-03-03  3:03           ` Eric Schulte
  2014-03-05  1:56             ` Eric Abrahamsen
  0 siblings, 1 reply; 24+ messages in thread
From: Eric Schulte @ 2014-03-03  3:03 UTC (permalink / raw)
  To: Nick Dokos; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-03  3:03           ` Eric Schulte
@ 2014-03-05  1:56             ` Eric Abrahamsen
  2014-03-05  3:20               ` Nick Dokos
  0 siblings, 1 reply; 24+ messages in thread
From: Eric Abrahamsen @ 2014-03-05  1:56 UTC (permalink / raw)
  To: emacs-orgmode

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!

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-05  1:56             ` Eric Abrahamsen
@ 2014-03-05  3:20               ` Nick Dokos
  2014-03-06 17:00                 ` Eric Schulte
  0 siblings, 1 reply; 24+ messages in thread
From: Nick Dokos @ 2014-03-05  3:20 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-05  3:20               ` Nick Dokos
@ 2014-03-06 17:00                 ` Eric Schulte
  2014-03-07  7:26                   ` Bastien
  0 siblings, 1 reply; 24+ messages in thread
From: Eric Schulte @ 2014-03-06 17:00 UTC (permalink / raw)
  To: Nick Dokos; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-06 17:00                 ` Eric Schulte
@ 2014-03-07  7:26                   ` Bastien
  2014-03-07 16:05                     ` Richard Lawrence
  0 siblings, 1 reply; 24+ messages in thread
From: Bastien @ 2014-03-07  7:26 UTC (permalink / raw)
  To: Eric Schulte; +Cc: Nick Dokos, emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-07  7:26                   ` Bastien
@ 2014-03-07 16:05                     ` Richard Lawrence
  2014-03-07 21:09                       ` Eric Schulte
  2014-03-13 14:55                       ` Bastien
  0 siblings, 2 replies; 24+ messages in thread
From: Richard Lawrence @ 2014-03-07 16:05 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-07 16:05                     ` Richard Lawrence
@ 2014-03-07 21:09                       ` Eric Schulte
  2014-03-08  4:05                         ` Richard Lawrence
  2014-03-13 14:55                       ` Bastien
  1 sibling, 1 reply; 24+ messages in thread
From: Eric Schulte @ 2014-03-07 21:09 UTC (permalink / raw)
  To: Richard Lawrence; +Cc: Bastien, emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-07 21:09                       ` Eric Schulte
@ 2014-03-08  4:05                         ` Richard Lawrence
  0 siblings, 0 replies; 24+ messages in thread
From: Richard Lawrence @ 2014-03-08  4:05 UTC (permalink / raw)
  To: Eric Schulte; +Cc: Bastien, emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-07 16:05                     ` Richard Lawrence
  2014-03-07 21:09                       ` Eric Schulte
@ 2014-03-13 14:55                       ` Bastien
  2014-03-13 16:28                         ` Richard Lawrence
  1 sibling, 1 reply; 24+ messages in thread
From: Bastien @ 2014-03-13 14:55 UTC (permalink / raw)
  To: Richard Lawrence; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-13 14:55                       ` Bastien
@ 2014-03-13 16:28                         ` Richard Lawrence
  2014-03-21  8:08                           ` Bastien
  0 siblings, 1 reply; 24+ messages in thread
From: Richard Lawrence @ 2014-03-13 16:28 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Org release 8.2.5g (minor release from maint)
  2014-03-13 16:28                         ` Richard Lawrence
@ 2014-03-21  8:08                           ` Bastien
  0 siblings, 0 replies; 24+ messages in thread
From: Bastien @ 2014-03-21  8:08 UTC (permalink / raw)
  To: Richard Lawrence; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2014-03-21  8:09 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-21 13:50 Org release 8.2.5g (minor release from maint) Bastien
2014-01-21 19:16 ` Achim Gratz
2014-01-21 19:25   ` Bastien
2014-01-21 19:30     ` Bastien
2014-01-21 19:35     ` Achim Gratz
2014-01-21 23:39   ` Bastien
2014-01-22  7:52     ` Achim Gratz
2014-01-25  7:58   ` Achim Gratz
2014-02-26 19:25     ` Achim Gratz
2014-02-26 23:23     ` Eric Schulte
2014-03-01  8:06       ` Bastien
2014-03-01  9:10       ` Achim Gratz
2014-03-01 12:53         ` Nick Dokos
2014-03-03  3:03           ` Eric Schulte
2014-03-05  1:56             ` Eric Abrahamsen
2014-03-05  3:20               ` Nick Dokos
2014-03-06 17:00                 ` Eric Schulte
2014-03-07  7:26                   ` Bastien
2014-03-07 16:05                     ` Richard Lawrence
2014-03-07 21:09                       ` Eric Schulte
2014-03-08  4:05                         ` Richard Lawrence
2014-03-13 14:55                       ` Bastien
2014-03-13 16:28                         ` Richard Lawrence
2014-03-21  8:08                           ` Bastien

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).