[gmane.emacs.devel, gmane.emacs.gnus.general, gmane.emacs.sxemacs.devel] Moving Gnus development to Emacs?
7:01 p.m.
I've recently taken over gnus maintainence for XEmacs, so will have to
read this again and digest a bit. . .
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:37 a.m.
Hi Uwe,
>>>> Uwe Brauer writes:
In case not everybody has noticed.
Thanks for bringing it to the attention of the xemacs list. Not everybody
reads the gnus list.
So we have on this list heard that the last Tramp version with xemacs support
has been pushed to the packages. Now Gnus is discussing removing xemacs
support. Not decided yet I think but still not unlikely. I know bbdb is
already there. And what about all those packages we have not synced for
years!? And all the new packages we would like to have!?
This is one of the things the "at a crossroad" issue is about I think.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:49 a.m.
Mats Lidell writes:
So we have on this list heard that the last Tramp version with
xemacs support has been pushed to the packages. Now Gnus is
discussing removing xemacs support.
It's sort of irrelevant to the current discussion, but Gnus has never
supported XEmacs all that well IMO, mostly due to the extents (which
can be trained to DTRT about copying headers) vs. overlays + text
properties issue. But this is exactly where upstream removing
compatibility code will hurt.
OTOH, TRAMP doesn't have that problem; for TRAMP it's simply the magic
file handler features that XEmacs lacks, it's not a question of
adapting different APIs or working around different behavior. AFAIK,
with the exception of the UI issue that for XEmacs the GNU-Emacs-style
TRAMP syntax conflicts with EFS, we can probably mostly just use TRAMP
if we introduce the needed features. And Michael promised that our
alternate syntax will be kept.
Not decided yet I think but still not unlikely. I know bbdb is
already there. And what about all those packages we have not synced
for years!? And all the new packages we would like to have!?
We've already discussed that, really. Projects "dropping suport"
doesn't change anything qualitatively, it just makes it more likely
that people will switch soon.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:29 a.m.
>> "Mats" == Mats Lidell <matsl(a)xemacs.org>
writes:
Hi Uwe,
>>>>> Uwe Brauer writes:
> In case not everybody has noticed.
Thanks for bringing it to the attention of the xemacs list. Not
everybody
reads the gnus list.
So we have on this list heard that the last Tramp version with xemacs
support
has been pushed to the packages. Now Gnus is discussing removing xemacs
support. Not decided yet I think but still not unlikely. I know bbdb is
already there. And what about all those packages we have not synced for
years!? And all the new packages we would like to have!?
And to poke my finger a bit more into it. There are these packages (like
auctex) which have been synchronized quite a while ago, but still dwell
in pre-release.....
This is one of the things the "at a crossroad" issue is
about I think.
Yours
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:33 a.m.
>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Mats Lidell writes:
> So we have on this list heard that the last Tramp version with
> xemacs support has been pushed to the packages. Now Gnus is
> discussing removing xemacs support.
It's sort of irrelevant to the current discussion, but Gnus has
never
supported XEmacs all that well IMO, mostly due to the extents (which
can be trained to DTRT about copying headers) vs. overlays + text
properties issue. But this is exactly where upstream removing
compatibility code will hurt.
[...]
Well I beg to differ: gnus has worked all these years reasonable well in
the sense that:
- it compiled without much trouble (which cannot be said say of org
mode, which, after compiling, spits out a impressive list of
unknown functions.
- I cannot see much of a difference feature wise when I use it with
Xemacs versus when I use it with GNU emacs (which cannot be said
for example for auctex, which has quite a list of features which
are *not* implemented for Xemacs). But maybe I don't use enough
of the function of the never ending list of features gnus offers.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:14 a.m.
Uwe Brauer writes:
And to poke my finger a bit more into it.
Please stop. Finger-poking is exactly what it is. It isn't going to
help.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3029
days inactive
3032
days old
6 comments
4 participants
participants (4)
-
Henry S. Thompson -
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Uwe Brauer