8:24 p.m.
I've been discussing with Kyle a problem with VM and
base64-encode-region. He had this to say:
,----
| Steve Youngs writes:
| > |--==> "KJ" == Kyle Jones <kyle_jones(a)wonderworks.com> writes:
| >
| > KJ> OK, so much for my fix. I'll make a new one in 6.91.
| >
| > OK. Is there anything that 6.90 users can do in the meantime as a
| > work around?
|
| Well, you folks could make your base64-encode-region compatible with
| the FSF Emacs version. You'll find that mailer writers will want
| the third arg anyway to do B-encoding.
`----
Could somebody please look into this.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
9:20 p.m.
Steve Youngs <youngs(a)xemacs.org> writes:
I've been discussing with Kyle a problem with VM and
base64-encode-region. He had this to say:
,----
| Steve Youngs writes:
| > |--==> "KJ" == Kyle Jones <kyle_jones(a)wonderworks.com>
writes:
| >
| > KJ> OK, so much for my fix. I'll make a new one in 6.91.
| >
| > OK. Is there anything that 6.90 users can do in the meantime as a
| > work around?
|
| Well, you folks could make your base64-encode-region compatible with
| the FSF Emacs version. You'll find that mailer writers will want
| the third arg anyway to do B-encoding.
`----
Could somebody please look into this.
XEmacs arguments are (start end no-line-break). FSF arguments (in
20.7.1) are the same. Where's the incompatibility?
10:56 p.m.
|--==> "Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
>| Well, you folks could make your base64-encode-region compatible
with
>| the FSF Emacs version. You'll find that mailer writers will want
>| the third arg anyway to do B-encoding.
Hrvoje> XEmacs arguments are (start end no-line-break). FSF arguments (in
Hrvoje> 20.7.1) are the same. Where's the incompatibility?
Hmm. Perhaps he was confusing the base64-encode-region in base64.el
that only has (start end).
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
2:05 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
Hrvoje> XEmacs arguments are (start end no-line-break). FSF
Hrvoje> arguments (in 20.7.1) are the same. Where's the
Hrvoje> incompatibility?
21.1 does not have base64 primitives.
SY> Hmm. Perhaps he was confusing the base64-encode-region in
SY> base64.el that only has (start end).
For future reference, hypothesizing that Kyle is confused is not a
good idea. Kyle is often indiosycratic and obstinate, but rarely
confused.
Kyle knows what the problem is, because I've discussed it with him.
He told me that he was simply going to turn off use of the built-in
(whether primitive, dumped, auto-, or or previously-loaded) in _all_
XEmacsen because of this. So I left it at that.
Evidently he has changed his mind.
By the way, his phrase "your base64-encode-region" is highly ironic.
_Kyle_ is the author of comm/w3/base64.el. (Note: that is not the
current version from upstream. I believe the upstream author has
retired it, but don't quote me on that.)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
10:05 a.m.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
Hrvoje> XEmacs arguments are (start end no-line-break). FSF
Hrvoje> arguments (in 20.7.1) are the same. Where's the
Hrvoje> incompatibility?
21.1 does not have base64 primitives.
So again, where's the incompatibility? Is base64.el distributed with
XEmacs 21.1? Do we add the feature there, or what?
10:31 a.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> So again, where's the incompatibility? Is base64.el
Hrvoje> distributed with XEmacs 21.1? Do we add the feature
Hrvoje> there, or what?
Well, it used to be in comm/w3/base64.el, but now it's in
libs/mail-lib/base64.el, in the packages.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
3:13 a.m.
Steve Youngs <youngs(a)xemacs.org> writes:
|--==> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
>>| Well, you folks could make your base64-encode-region compatible with
>>| the FSF Emacs version. You'll find that mailer writers will want
>>| the third arg anyway to do B-encoding.
Hrvoje> XEmacs arguments are (start end no-line-break). FSF arguments (in
Hrvoje> 20.7.1) are the same. Where's the incompatibility?
Hmm. Perhaps he was confusing the base64-encode-region in base64.el
that only has (start end).
FYI, the non-line-break argument has been added into base64.el of Gnus
5.8 for years. The copy is more compatible with builtin ones.
ShengHuo
--
(setq gnus-posting-styles
'((".*" (signature (format "(setq gnus-posting-styles
'%S)" gnus-posting-styles)))))
2:41 p.m.
|--==> "ZSH" == ShengHuo ZHU <zsh(a)cs.rochester.edu> writes:
ZSH> FYI, the non-line-break argument has been added into base64.el of Gnus
ZSH> 5.8 for years. The copy is more compatible with builtin ones.
Yep. We're going to sync our base64.el with yours.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
2:46 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> I've been discussing with Kyle a problem with VM and
SY> base64-encode-region.
I gather this is basically the same problem I reported (to vm-bug)
about VM 6.85 or so, that VM was picking up the presence of
base64-encode-region from libs/mail-lib/base64.el and using that in
preference to its internal Lisp implementation?
This should only be a problem with 21.1, as our 21.2 primitive is
call-compatible with the FSF. I assume Vin would prefer not to
backport the C code to 21.1, especially as we hope 21.1 will soon
become obsolete.
Since base64.el is Kyle's code anyway (but our version is wa-a-ay out
of date, mea maxima culpa, I knew about this but spaced out on
reporting it), I suggest we either
(1) synch up to the latest version, if Kyle still maintains it,
(2) grab VM's internal implementation, which I believe does exist
and is functionally equivalent to the FSF's code, and export
it as base64.el,
(3) borrow GNus's version (which probably exists), or
(4) port the FSF's lisp code (if it exists, maybe they have a
primitive?)
in order of preference. Since base64.el doesn't have a named
maintainer, you can do that on your own authority, Steve.
This is preferable to forcing Kyle to work around an XEmacs backward
incompatibility (unless you need to do that for other reasons, Kyle?),
since as Kyle pointed out mailer writers in general will want the
third argument.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
4:08 a.m.
Stephen J. Turnbull writes:
>>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> I've been discussing with Kyle a problem with VM and
SY> base64-encode-region.
I gather this is basically the same problem I reported (to vm-bug)
about VM 6.85 or so, that VM was picking up the presence of
base64-encode-region from libs/mail-lib/base64.el and using that in
preference to its internal Lisp implementation?
Yah. I patched VM to ignore the routine if it wasn't a subr, but
then routing was ported to C which broke VM again, which shows the
folly of my fix. I've made VM 6.91 call base64-encode-region with
two args if XEmacs balks at three args, so that should resolve the
matter.
Since base64.el is Kyle's code anyway
It is? I didn't know that. In any case don't worry about
VM being broken; I've resolved it.
10:18 a.m.
|--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
SJT> (1) synch up to the latest version, if Kyle still maintains it,
Preferable.
SJT> (2) grab VM's internal implementation, which I believe does exist
SJT> and is functionally equivalent to the FSF's code, and export
SJT> it as base64.el,
Too much like hard work. :-)
SJT> (3) borrow GNus's version (which probably exists), or
Easiest, and probably the way I'd go.
SJT> (4) port the FSF's lisp code (if it exists, maybe they have a
SJT> primitive?)
Last resort.
SJT> in order of preference. Since base64.el doesn't have a named
SJT> maintainer, you can do that on your own authority, Steve.
Well, because it's now part of the mail-lib package, it does have a
maintainer. This is Simon's baby.
Simon, could you please sync up base64.el with the one in Gnus'
contrib directory. Grab it from the Gnus CVS (I didn't put it in our
package to prevent a lisp shadow. Guess I got rid of the wrong one).
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
10 a.m.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
(1) synch up to the latest version, if Kyle still maintains it,
Where is it?
(2) grab VM's internal implementation, which I believe does
exist
and is functionally equivalent to the FSF's code, and export
it as base64.el,
It seem to be somewhat integrated with vm, so it looks like work
without any obvious advantage compared to:
(3) borrow GNus's version (which probably exists), or
Since base64.el is in mail-lib I did this, patch to xemacs-patches
coming up.
(4) port the FSF's lisp code (if it exists, maybe they have
a
primitive?)
Emacs doesn't have lisp code AFAIK. It's C only.
in order of preference.
I don't know about Kyle's updated version, but I don't think there's
anything the VM base64 code do that Gnus base64.el doesn't. Of
course, if there's an updated/maintained version of base64.el perhaps
we could update the copy in Gnus.
8896
days inactive
8904
days old
11 comments
6 participants
participants (6)
-
Hrvoje Niksic -
Kyle Jones -
ShengHuo ZHU -
Simon Josefsson -
Stephen J. Turnbull -
Steve Youngs