Re: [O] Org release 8.2.5g (minor release from maint)

2014-03-21 Thread Bastien
Hi Richard,

thanks for your detailed account on The Debian Way.

Richard Lawrence richard.lawre...@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



Re: [O] Org release 8.2.5g (minor release from maint)

2014-03-13 Thread Richard Lawrence
Hi Bastien,

Bastien b...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-13 Thread Bastien
Hi Richard,

Richard Lawrence richard.lawre...@berkeley.edu writes:

 Bastien b...@gnu.org writes:

 Eric Schulte schulte.e...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-07 Thread Richard Lawrence
Bastien b...@gnu.org writes:

 Eric Schulte schulte.e...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-07 Thread Eric Schulte
Richard Lawrence richard.lawre...@berkeley.edu writes:

 Bastien b...@gnu.org writes:

 Eric Schulte schulte.e...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-07 Thread Richard Lawrence
Eric Schulte schulte.e...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-06 Thread Eric Schulte
Nick Dokos ndo...@gmail.com writes:

 Eric Abrahamsen e...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-06 Thread Bastien
Hi Eric and Nick,

Eric Schulte schulte.e...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-04 Thread Eric Schulte
Nick Dokos ndo...@gmail.com writes:

 Achim Gratz strom...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-04 Thread Eric Abrahamsen
Eric Schulte schulte.e...@gmail.com writes:

 Nick Dokos ndo...@gmail.com writes:

 Achim Gratz strom...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-04 Thread Nick Dokos
Eric Abrahamsen e...@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: [O] Org release 8.2.5g (minor release from maint)

2014-03-01 Thread Bastien
Hi Eric,

Eric Schulte schulte.e...@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,

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


-- 
 Bastien


Re: [O] Org release 8.2.5g (minor release from maint)

2014-03-01 Thread 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: [O] Org release 8.2.5g (minor release from maint)

2014-03-01 Thread Nick Dokos
Achim Gratz strom...@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: [O] Org release 8.2.5g (minor release from maint)

2014-02-27 Thread Eric Schulte
Achim Gratz strom...@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: [O] Org release 8.2.5g (minor release from maint)

2014-02-26 Thread 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: [O] Org release 8.2.5g (minor release from maint)

2014-01-24 Thread Achim Gratz
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.

From 024e05c4de3c7598448ee97b0f986562007d5186 Mon Sep 17 00:00:00 2001
From: Achim Gratz strom...@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



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


[O] Org release 8.2.5g (minor release from maint)

2014-01-21 Thread 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: [O] Org release 8.2.5g (minor release from maint)

2014-01-21 Thread 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: [O] Org release 8.2.5g (minor release from maint)

2014-01-21 Thread 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: [O] Org release 8.2.5g (minor release from maint)

2014-01-21 Thread 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: [O] Org release 8.2.5g (minor release from maint)

2014-01-21 Thread Bastien
Bastien b...@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: [O] Org release 8.2.5g (minor release from maint)

2014-01-21 Thread Bastien
Achim Gratz strom...@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: [O] Org release 8.2.5g (minor release from maint)

2014-01-21 Thread 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.