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