Re: [O] Org release 8.2.5g (minor release from maint)
Hi Richard, thanks for your detailed account on The Debian Way. Richard Lawrence 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)
Hi Richard, Richard Lawrence writes: > Bastien writes: > >> Eric Schulte 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)
Hi Bastien, Bastien 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)
Eric Schulte 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)
Richard Lawrence writes: > Bastien writes: > >> Eric Schulte 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)
Bastien writes: > Eric Schulte 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)
Hi Eric and Nick, Eric Schulte 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)
Nick Dokos writes: > Eric Abrahamsen 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)
Eric Abrahamsen 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)
Eric Schulte writes: > Nick Dokos writes: > >> Achim Gratz 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)
Nick Dokos writes: > Achim Gratz 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)
Achim Gratz 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)
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)
Hi Eric,
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?
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)
Achim Gratz 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)
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)
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 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
Re: [O] Org release 8.2.5g (minor release from maint)
Bastien 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: [O] Org release 8.2.5g (minor release from maint)
Achim Gratz 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)
Bastien 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)
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)
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)
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
[O] Org release 8.2.5g (minor release from maint)
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
