3:48 p.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
I just noticed that the dired documentation appears to be way out of
date; for example, it does not cover the mark "m" command. I looked at
FSF Emacs 20.5, and it seems that the relevant documentation was
written in 1994, so I'm a bit surprised that you haven't got it yet.
This is a problem I've noticed more than once in XEmacs: that the main
info files appear to be horribly out of date in several cases. Would
it not be possible to sync them with FSF Emacs's latest versions? I
can't imagine that the changes would be very great (although I'm sure
that it's a bit more than s/Emacs/XEmacs/!).
I'm very keen to have this fixed, so I'd be happy to do it myself with
a bit of guidance.
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux msrc-v-reubth.europe.corp.microsoft.com 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT
2001 i686 unknown
./configure '--prefix=/home/rrt' '--with-mule'
XEmacs 21.4.4 "Artificial Intelligence" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /home/rrt/xemacs-21.4.4
Installation prefix: /home/rrt
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wshadow -Wsign-compare
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for dynamic shared object modules.
Installed XEmacs Packages:
-------------------------
((zenirc :version 1.11 :type regular)
(xslt-process :version 1.04 :type regular)
(xemacs-devel :version 1.37 :type single-file)
(xemacs-base :version 1.55 :type regular)
(w3 :version 1.2 :type regular)
(view-process :version 1.11 :type regular)
(vc :version 1.28 :type regular)
(time :version 1.11 :type regular)
(textools :version 1.12 :type regular)
(text-modes :version 1.32 :type single-file)
(texinfo :version 1.2 :type regular)
(supercite :version 1.17 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.21 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(slider :version 1.13 :type regular)
(sh-script :version 1.13 :type regular)
(sgml :version 1.08 :type regular)
(scheme :version 1.11 :type regular)
(reftex :version 1.23 :type regular)
(psgml :version 1.23 :type regular)
(prog-modes
:version
1
.4
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.55 :type regular)
(pc :version 1.2 :type single-file)
(os-utils :version 1.25 :type single-file)
(net-utils :version 1.2 :type single-file)
(misc-games :version 1.15 :type single-file)
(mine :version 1.14 :type regular)
(mailcrypt :version 2.09 :type regular)
(mail-lib :version 1.39 :type regular)
(jde :version 1.27 :type regular)
(ispell :version 1.23 :type regular)
(ilisp :version 1.19 :type regular)
(igrep :version 1.08 :type regular)
(hm--html-menus :version 1.16 :type regular)
(gnus :version 1.56 :type regular)
(gnats :version 1.12 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.09 :type single-file)
(frame-icon :version 1.09 :type regular)
(footnote :version 1.13 :type regular)
(eudc :version 1.33 :type regular)
(eterm :version 1.13 :type regular)
(eshell :version 1.01 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.08 :type single-file)
(eieio :version 1.01 :type regular)
(eicq :version 1.05 :type regular)
(efs :version 1.26 :type regular)
(edit-utils :version 1.65 :type single-file)
(ediff :version 1.31 :type regular)
(edebug :version 1.14 :type regular)
(dired :version 1.11 :type regular)
(debug :version 1.14 :type regular)
(cookie :version 1.13 :type regular)
(cc-mode :version 1.25 :type regular)
(calendar :version 1.16 :type regular)
(calc :version 1.17 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.02 :type regular)
(bbdb :version 1.13 :type regular)
(auctex :version 1.25 :type regular)
(mule-base :version 1.39 :type regular)
(lookup :version 1.08 :type regular)
(leim :version 1.17 :type regular)
(egg-its :version 1.26 :type regular)
(edict :version 1.12 :type regular))
Features:
--------
(rect url-misc browse-url igrep gnus-picon sort smiley annotations
gnus-cite gnus-async gnus-score score-mode gnus-ml gnus-msg gnus-art
mm-uu mm-view gnus-sum nndraft nnmh gnus-cache gnus-group gnus-undo
nnmail mail-source format-spec nntp nnoo gnus-start gnus-range
gnus-spec gnus-int gnus-win supercite regi xemacsbug metamail feedmail
starttls smtpmail time-stamp rmail-mini rmail mail-extr
highlight-headers imap gnus gnus-ems gnus-xmas message messagexmas mml
mm-decode mm-encode mail-parse rfc2045 rfc2231 mail-abbrevs mailheader
eudc-vars bbdb qmtp mm-bodies uudecode rfc2047 gnus-util nnheader
nnheaderxm ietf-drums time-date parse-time qp mm-util mail-prsvr
mailcap smime shell comint compile env dired-faces dired-xemacs dired
eldoc elp smtp sasl sasl-anonymous sasl-login sasl-plain w3-style
ethio-util w3-hot url-file url-cache w3-xemac w3-xemacs w3-toolbar
xbm-button xpm-button w3-forms images url-http url-cookie urlauth
mel-q-ccl mime-w3 w3 w3-menu url-news url-gw w3-script w3-jscript
w3-elisp w3-java cus-edit cus-load w3-emulate w3-auto w3-parse url mm
w3-display w3-mouse w3-imap w3-widget w3-vars w3-keyword w3-cus
url-parse url-vars css mule-sysdp w3-cfg w3-sysdp view-less view
hyper-apropos info wl-score elmo-localdir mime-setup mail-mime-setup
semi-setup mime-image wl-mime mmelmo-imap4 mmelmo mmbuffer mmgeneric
mime-parse mime-play filename mime-edit eword-encode pgg-parse pccl
pccl-20 advice advice-preload pgg-def signature mail-utils mime-view
mime-conf calist semi-def mime wl-demo wl-draft elmo-pop3 elmo-net
luna wl-template sendmail wl-address wl-thread wl-summary wl-refile
wl-message wl-highlight elmo-multi wl-folder wl wl-xmas wl-util pp
wl-vars wl-version elmo2 elmo-database elmo-dop elmo-msgdb elmo-cache
emu invisible inv-xemacs elmo-util utf7 eword-decode mel mime-def
alist mcharset mcs-20 mcs-xm mcs-xmu poem poem-xm pces pces-xfc
pces-20 broken pces-xm pcustom std11 elmo-date timezone path-util
elmo-vars poe-xemacs timer overlay poe elmo-version pym static
apel-ver product efs-cu font disp-table blink-cursor permanent-buffers
lazy-shot font-lock avoid paren blink-paren tex-site cc-styles cc-vars
wid-edit cus-face cc-defs filladapt ansi-color socks jka-compr vc ring
vc-hooks mwheel edmacro iswitchb gnuserv zenirc-autoloads
xslt-process-autoloads xemacs-devel-autoloads xemacs-base-autoloads
w3-autoloads view-process-autoloads vc-autoloads time-autoloads
textools-autoloads text-modes-autoloads texinfo-autoloads
supercite-autoloads strokes-autoloads speedbar-autoloads
sounds-wav-autoloads sounds-au-autoloads slider-autoloads
sh-script-autoloads sgml-autoloads scheme-autoloads reftex-autoloads
psgml-autoloads prog-modes-autoloads pcomplete-autoloads
pcl-cvs-autoloads pc-autoloads os-utils-autoloads net-utils-autoloads
misc-games-autoloads mine-autoloads mailcrypt-autoloads
mail-lib-autoloads jde-autoloads ispell-autoloads ilisp-autoloads
igrep-autoloads hm--html-menus-autoloads gnus-autoloads
gnats-autoloads games-autoloads fsf-compat-autoloads
frame-icon-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
eshell-autoloads emerge-autoloads elib-autoloads eieio-autoloads
eicq-autoloads efs-autoloads edit-utils-autoloads ediff-autoloads
edebug-autoloads dired-autoloads debug-autoloads cookie-autoloads
cc-mode-autoloads calendar-autoloads calc-autoloads
c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads
mule-base-autoloads lookup-autoloads leim-autoloads egg-its-autoloads
edict-autoloads wl-autoloads semi-autoloads flim-autoloads
apel-autoloads lisp-autoloads loadhist auto-show fontl-hooks
x-iso8859-1 slovenian czech romanian ccl mule-help code-cmds
gutter-items menubar-items x-menubar mode-motion mouse itimer
auto-save lisp-mode easymenu iso8859-1 page buff-menu lib-complete
cus-file derived frame text-props obsolete cus-start custom widget
cl-extra mini-cl cl cl-19 packages backquote very-early-lisp
file-coding mule lucid-scrollbars cut-buffer lucid-menubars x
c-balloon-help tty-frames tty toolbar native-sound scrollbar
unix-processes multicast network-streams subprocesses modules
menu-accelerator-support menubar berkeley-db md5 xemacs xim gutter
tiff png gif jpeg xpm xbm lisp-float-type linux devices window-system
base64)
Recent keystrokes:
-----------------
d d d n SPC SPC n n n n n RET n n button2 button2up
down down button5 button5up button5 button5up button4
button4up button4 button4up button4 button4up button1
button1up button2 button2up button2 button2up button1
button1up button1 button1up button2 button2up button2
button2up button2 button2up button2 button2up button1
button1up down down down left left left left left left
RET RET RET RET RET RET RET C-x k RET button1 button1up
button1 button1up n n RET d d d d d d d d d d d d d
RET q up RET RET button1 button1up button1 button1up
n n q misc-user
Recent messages (most recent first):
-----------------------------------
Wrote /home/rrt/Mail/draft/1
(New file)
Checking environment...done
Checking environment...
Updating addresses...done
Updating addresses...
Initializing ...
Saving /home/rrt/.newsrc.eld...done
Wrote /home/rrt/.newsrc.eld
Saving /home/rrt/.newsrc.eld...
Wrote /home/rrt/.newsrc
No more unread newsgroups
No more unread articles (Type n to exit comp.sys.psion.announce)
Generating summary...done
Generating summary...
Fetching headers for comp.sys.psion.announce...done
Fetching headers for comp.sys.psion.announce...
Retrieving newsgroup: comp.sys.psion.announce...
No more unread newsgroups
No more articles
5:24 a.m.
>>>> "rrt" == rrt <rrt(a)sc3d.org> writes:
rrt> I just noticed that the dired documentation appears to be way
rrt> out of date [...].
Dired is externally maintained, and there should be a separate dired
topic under packages. I'm cc'ing dired-bugs(a)xemacs.org, which
redirects reports to the Dired maintainer. I suspect Michael would be
very happy to receive a contribution of a split-out and up-to-date
Info manual for Dired.
[Mike: the rest is not directly relevant to Dired, except that it
looks like you may have a volunteer to do exactly that. :) ]
rrt> This is a problem I've noticed more than once in XEmacs: that
rrt> the main info files appear to be horribly out of date in
rrt> several cases. Would it not be possible to sync them with FSF
rrt> Emacs's latest versions?
Yes, it's possible. We do our best, but documentation is relatively
low priority to most of our volunteers. I'd like to change that, but
volunteers are volunteers. We don't have _any_ paid staff (AFAIK),
unlike the FSF. You are very welcome to do the synchs and submit
patches.
rrt> I can't imagine that the changes would be very great
rrt> (although I'm sure that it's a bit more than
rrt> s/Emacs/XEmacs/!).
Try it. It's harder than you think to do it well. It's not clear to
me that doing it halfway, and then fixing what's broke, is a good
strategy, either. There's likely to be a fair amount of breakage.
The FSF regularly makes API and semantic changes. We don't find out
about them until after release because it is apparently FSF policy to
deny XEmacs developers access to the FSF developer lists for the
purpose of synchronization. rms considers it "industrial espionage."
Nor does the FSF make any visible attempt to avoid collision with
XEmacs extensions to the API. Finally, due to the package system, it
is extremely common that our package is newer than that of the FSF
(eg, Gnus---a very special case---was 2.5 years older in FSF 20.x than
in our package system the last time I checked). Not to mention that
the FSF assumes a free hand to modify the packages to fit in better
with FSF UIs and APIs.
This means that although there may be few changes from FSF reality to
XEmacs reality, _every single proposed doc synch_ must be vetted to
ensure that it doesn't introduce an error. I wish we had volunteers
to do this, too, but I can't quite bring myself to berate the
volunteers we do have for not doing more of it. It's painstaking, not
very exciting work. Our best developers do it for their own changes,
and some even go the extra mile and work on other developers' docs.
But we're spread too thin to do it very quickly.
Even the documentation I'm working on personally is _new_
documentation. Arguably we should get what we have up-to-date first,
but I happen to disagree. I'm working on "process" documents in the
hope that explaining how we do things will encourage people to submit
more fixes and enhancements, including to docs
rrt> I'm very keen to have this fixed, so I'd be happy to do it
rrt> myself with a bit of guidance.
1. Read the info files on Texinfo: C-h i m info RET m creating RET.
2. Skim the standards documents, C-h i m standards RET. Note that our
coding practices differ from the GNU standard in a few ways, but the
standards are mostly accurate. Coding standards are generally not
applicable to user documentation, but some code does leak through
into the user documentation and it should be done correctly.
If you decide to work on the Lispref or Internals documents, you
should also read the first 9 chapters of the Internals manual.
3. I don't know what our policy on texinfo mode is (ie, there isn't
one), but I know that many of our texi files do not comply with its
conventions. You're welcome to improve conformance.
4. Compare changes against docstrings, which are typically more
up-to-date than the Info documentation. Eg, C-h m in Dired mode
presumably _does_ document the "m" command.
5. Test all changes to make sure that XEmacs actually behaves as
documented.
6. The style (ie, usage of face-changing directives, etc) in the
XEmacs Texinfo sources is as unreliable as the content. I don't
have good examples to point to offhand, so you might want to follow
the FSF docs you're synching to. However, at this point we are
trying to support both texinfo.el and makeinfo 1.68 (IIRC), so some
of the more modern "logical" directives (eg, the ＠env{} form)
should be avoided. (This policy is due to the fact that native
Windows builds do not have an easy source of up-to-date GNU
utilities; we are considering changing it, but for the moment that
is the policy.)
7. Submit patches to xemacs-patches(a)xemacs.org, or in the case of
packaged Lisp libraries like Dired, to the maintainer. We have
convenience aliases ＠xemacs.org for each package.
The preferred format for patches is unified CVS diff against the trunk
(cvs diff -u), but any form of context diff is acceptable. Diffs
without context will probably be returned for revision to unified
format.
Please include a ChangeLog entry (the ChangeLog for the texi sources
is in the ./man subdirectory). Use the format Use the format of M-x
add-change-log-entry. The ChangeLog entry can be submitted as plain
text or as a zero-context unified diff (diff -U 0).
You may wish to browse http://list-archive.xemacs.org/xemacs-patches/
for samples. Ben Wing, Martin Buchholz, Didier Verna, and Adrian
Aichner are known for producing excellent patches. Also, in the
xemacs-devel Lisp package there is a library patcher.el which is
useful for generating patches from CVS diffs, and will even set up the
ChangeLog entries for you.
--
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."
12:51 a.m.
rrt> I can't imagine that the changes would be very great
rrt> (although I'm sure that it's a bit more than
rrt> s/Emacs/XEmacs/!).
Try it. It's harder than you think to do it well. It's not clear to
me that doing it halfway, and then fixing what's broke, is a good
strategy, either. There's likely to be a fair amount of breakage.
The FSF regularly makes API and semantic changes. We don't find out
about them until after release because it is apparently FSF policy to
deny XEmacs developers access to the FSF developer lists for the
purpose of synchronization. rms considers it "industrial espionage."
He really is stupid sometimes, not to mention inconsistent; is this
open source or what?
This means that although there may be few changes from FSF reality
to
XEmacs reality, _every single proposed doc synch_ must be vetted to
ensure that it doesn't introduce an error.
I think I have a plausible approach to this, and that is to focus on
bits of documentation I have found lacking. These have mostly been at
the user-interface level and in fairly core bits of the system: the
two in question have been dired and the way that major mode is chosen
(I wanted to find out how to set a major mode based on the #! line in
a script; the relevant bit was at the bottom of a page in the FSF docs
and simply missing from XEmacs, but it worked fine).
This way, I wouldn't be trying to do too much, but would still be
working on problems which have bitten me, and hence probably bite
others. Also, I suspect it's easier to get into this than coding (at
least for me; I'm a doc-head as much as a code-head!), so is an easier
way for me to contribute to the project.
Even the documentation I'm working on personally is _new_
documentation. Arguably we should get what we have up-to-date first,
but I happen to disagree.
Of course it depends on the docs in question. But when I see core docs
seven years out of date it makes me think that something's gone wrong
somewhere. I know, I can always (and especially with (X)Emacs) read
the code, even in quite high-level ways like M-x apropos, but this is
too hit and miss, and shouldn't be necessary, even if it is rather
cool, and often quicker for someone familiar with XEmacs (as I learn
Emacs, I find it easier to guess what to apropos for).
up-to-date than the Info documentation. Eg, C-h m in Dired mode
presumably _does_ document the "m" command.
Well, "h" does (which is where C-h m directs you).
the FSF docs you're synching to. However, at this point we
are
trying to support both texinfo.el and makeinfo 1.68 (IIRC), so some
of the more modern "logical" directives (eg, the ＠env{} form)
should be avoided.
Urgh. I am a fan of logical mark-up. Never mind!
Thanks for the guidance above; I hope that's copied from or goes into
one of your process documents! Probably the latter; once or twice I've
found myself writing advice like that and then realised I really ought
to be writing a process doc...and actually did.
At the moment most of my XEmacs bandwith is going into getting my
environment fully functional, as I've just switched from Pine to
Wanderlust, and slrn to Gnus. Funnily, despite trying it several times
because I knew I ought to, I never got my head around Emacs, and was
using NEdit until forced to use FSF Emacs under Windows, because it
was the only decent editor available. This was while working at
Microsoft. Okay, Microsoft Research. What a weird place finally to see
the light of the OTE...
3:57 p.m.
>>>> "rrt" == rrt <rrt(a)sc3d.org> writes:
rrt> This bug report will be sent to the XEmacs Development Team,
rrt> not to your local site managers!!
rrt> Please write in English, because the XEmacs maintainers do not have
rrt> translators to read other languages for them.
rrt> Please describe as succinctly as possible:
rrt> - What happened.
rrt> - What you thought should have happened.
rrt> - Precisely what you were doing at the time.
rrt> Please also include any C or lisp back-traces that you may have.
rrt> ================================================================
rrt> Dear Bug Team!
rrt> I just noticed that the dired documentation appears to be way out of
rrt> date;
There *is* no Dired documentation, so it's hard for it to be out of
date. I don't see how the documentation for FSF Emacs 20.5 Dired,
which is an entirely different program from our Dired, should apply.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
3:57 p.m.
> purpose of synchronization. rms considers it "industrial
espionage."
He really is stupid sometimes, not to mention inconsistent; is this
open source or what?
While I don't necessarily agree with the closedness of Emacs development,
I don't think it's an inconsistency in RMS's position: he doesn't care
about Open Source Software. Only about Free Software.
Note that the political underpinnings of the two philosophies are
pretty much completely opposed.
Stefan
4:09 p.m.
There *is* no Dired documentation,
M-x info xemacs<RET>m dired<RET> (XEmacs 21.4.4) looks like dired docs
to me.
I don't see how the documentation for FSF Emacs 20.5 Dired,
which is an entirely different program from our Dired, should apply.
The docs I mentioned above seem to be right. They also seem to be
pretty much a strict subset of the dired docs for FSF Emacs 20.5
dired. All the bits I wanted (which were admittedly fairly basic)
worked fine.
Anyway, I've agreed to try merging some of the docs into the XEmacs
tree, testing of course to make sure of the accuracy of what I'm
doing. Hopefully I'll be able to look at that quite soon now.
4:18 p.m.
>>>> "rrt" == rrt <rrt(a)sc3d.org> writes:
> There *is* no Dired documentation,
rrt> M-x info xemacs<RET>m dired<RET> (XEmacs 21.4.4) looks like dired
docs
rrt> to me.
You have a point there. Gosh, all these years and I never noticed
this stuff! (And nobody ever complained, either.)
Anyway: as I said, these docs were written for an entirely different
program. Any similarity with the current Dired is (well, not
entirely, but pretty much) coincidental.
> I don't see how the documentation for FSF Emacs 20.5 Dired,
> which is an entirely different program from our Dired, should apply.
rrt> The docs I mentioned above seem to be right. They also seem to be
rrt> pretty much a strict subset of the dired docs for FSF Emacs 20.5
rrt> dired. All the bits I wanted (which were admittedly fairly basic)
rrt> worked fine.
rrt> Anyway, I've agreed to try merging some of the docs into the XEmacs
rrt> tree, testing of course to make sure of the accuracy of what I'm
rrt> doing. Hopefully I'll be able to look at that quite soon now.
That's great news. Please note that the place to put this is not the
XEmacs documentation, but instead the Dired distribution, as Dired is
not part of the XEmacs core. I'll be glad to help, and I'd be happy
to put any documentation you send me into the distro.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
6:26 p.m.
>>>> "Stefan" == Stefan Monnier
<monnier+lists.xemacs.beta/news/(a)RUM.cs.yale.edu> writes:
>> purpose of synchronization. rms considers it
"industrial espionage."
> He really is stupid sometimes, not to mention inconsistent; is this
> open source or what?
Stefan> While I don't necessarily agree with the closedness of
Stefan> Emacs development, I don't think it's an inconsistency in
Stefan> RMS's position: he doesn't care about Open Source
Stefan> Software. Only about Free Software. Note that the
Stefan> political underpinnings of the two philosophies are pretty
Stefan> much completely opposed.
Hi Stefan, would you have any pointers to non-lawyer resources
contrasting Free- with Open-Source Software?
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
7:43 p.m.
You have a point there. Gosh, all these years and I never noticed
this stuff! (And nobody ever complained, either.)
! I have a tendency to complain about documentation. For me it's not
enough to find out how to do it...
That's great news. Please note that the place to put this is not
the
XEmacs documentation, but instead the Dired distribution, as Dired is
not part of the XEmacs core. I'll be glad to help, and I'd be happy
to put any documentation you send me into the distro.
Thanks; I've already had quite detailed guidance on this, which I'll
be attempting to follow once I've titivated Wanderlust to my fancy
(i.e. that's the XEmacs activity which is absorbing all my spare
cycles ATM).
8289
days inactive
8292
days old
8 comments
5 participants
participants (5)
-
Adrian Aichner -
Michael Sperber -
Reuben Thomas -
Stefan Monnier -
Stephen J. Turnbull