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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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,
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?
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,
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).
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)
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
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
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.
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
23 matches
Mail list logo
