8:23 p.m.
Having not followed the politics in years, I don't know whether this is still
considered heresy, but I have to ask:
Isn't it about time that XEmacs supported the Perl/Python/Javascript regexp syntax?
The world has moved on.
Even if church dogma dictates that we still double-slashify all our parens in Lisp code,
Perl's simpler syntax could still be supported for interactive commands.
It's mostly the extra backslashing and lack of \s that drives me crazy on a daily
basis.
I suppose a bound variable around re-search-forward, to indicate the parsing style, would
be the way to go. That, or a separate function for new-style, like PHP does.
--
Jamie Zawinski http://www.jwz.org/ http://www.dnalounge.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:11 a.m.
On 12/30/2010 3:23 PM, Jamie Zawinski wrote:
Having not followed the politics in years, I don't know whether
this is still considered heresy, but I have to ask:
Isn't it about time that XEmacs supported the Perl/Python/Javascript regexp syntax?
The world has moved on.
Even if church dogma dictates that we still double-slashify all our parens in Lisp code,
Perl's simpler syntax could still be supported for interactive commands.
It's mostly the extra backslashing and lack of \s that drives me crazy on a daily
basis.
I guess this would fit the largest part of your requirement?
# Raw strings.
SXEmacs has Python-style raw strings. It greatly reduces "backslashitis"
when writing those hairy regexps. :-)
* Normal regexp: "\\(?:^\\|[^\\]\\)\\(?:\\\\\\\\\\)*\\(\\\\[＠A-Za-z]+\\)"
* Raw string regexp: #r"\(?:^\|[^\]\)\(?:\)*\(\\[＠A-Za-z]+\)"
XEmacs 21.5 now has raw strings.
--
Nelson Ferreira
Pubkey: http://triatlantico.org/njsf.asc
(9DFE 82A7 C689 BAEE EC25 A8E8 3C64 1789 7420 ED20)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:21 a.m.
Jamie Zawinski <jwz(a)jwz.org> writes:
I suppose a bound variable around re-search-forward, to indicate the
parsing style, would be the way to go. That, or a separate function
for new-style, like PHP does.
Or, perhaps, a new reader syntax for the new-style regexps. Like:
(re-search-forward #"(\s+)" nil t)
Or #/(\s+)/? #/"(\s+)"? Anyway, the low-level regexp functions could
do the dispatch on the object type instead of introducing new
functions.
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:28 a.m.
On Jan 2, 2011, at 8:21 PM, Lars Magne Ingebrigtsen wrote:
(re-search-forward #"(\s+)" nil t)
Yes, I really like this.
Maybe also
(re-search-forward #("line 1"
"line 2"))
to avoid having to do
(re-search-forward (concat #"line 1"
#"line 2"))
--
Jamie Zawinski http://www.jwz.org/ http://www.dnalounge.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:35 a.m.
On 1/2/2011 11:21 PM, Lars Magne Ingebrigtsen wrote:
Jamie Zawinski <jwz(a)jwz.org> writes:
> I suppose a bound variable around re-search-forward, to indicate the
> parsing style, would be the way to go. That, or a separate function
> for new-style, like PHP does.
Or, perhaps, a new reader syntax for the new-style regexps. Like:
(re-search-forward #"(\s+)" nil t)
Or #/(\s+)/? #/"(\s+)"? Anyway, the low-level regexp functions could
do the dispatch on the object type instead of introducing new
functions.
XEmacs 21.5b28 ported that syntax from SXEmacs in 2007 ;)
--
Nelson Ferreira
Pubkey: http://triatlantico.org/njsf.asc
(9DFE 82A7 C689 BAEE EC25 A8E8 3C64 1789 7420 ED20)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:54 a.m.
Jamie Zawinski writes:
Isn't it about time that XEmacs supported the
Perl/Python/Javascript regexp syntax? The world has moved on.
XEmacs should, yes.
Even if church dogma dictates that we still double-slashify all our
parens in Lisp code, Perl's simpler syntax could still be supported
for interactive commands.
I don't see why supporting alternative regexp syntax in code should be
a problem. We already support things like raw strings that the Church
of Cambridge does not.
The problem right now is finding somebody to do the work.
The other question is should we try to support pcre + Emacs
extensions, or just use the simpler syntax.
It's mostly the extra backslashing and lack of \s that drives me
crazy on a daily basis.
Interactively we already support single-slash input. Recent XEmacs
21.5 supports a raw string syntax. #r"stri\ng" for example is lexed
as a string with a single backslash and no line breaks. The
equivalent to "\s" in Emacs syntax is "\s-".
I imagine you know all that already; what I'm interested in here is
precisely what your requirement is. Less typing? Avoiding confusion
in the muscle memory?
I suppose a bound variable around re-search-forward, to indicate
the parsing style, would be the way to go. That, or a separate
function for new-style, like PHP does.
Bound variables can be a PITA deep in a function, and re-search-* are
used in a lot of code. I think separate functions, with a Ben-style
"behavior" for switching the keybindings, is the best implementation.
Or there could be a user customization, with re-search-* becoming
internal and the keys bound to re-search-*-command which consults the
option to determine which function to call.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:28 a.m.
The other question is should we try to support pcre + Emacs
extensions, or just use the simpler syntax.
What Emacs extensions do you mean?
Interactively we already support single-slash input. Recent XEmacs
21.5 supports a raw string syntax. #r"stri\ng" for example is lexed
as a string with a single backslash and no line breaks. The
equivalent to "\s" in Emacs syntax is "\s-".
I had forgotten that #r existed. I really should use that more...
I imagine you know all that already; what I'm interested in here
is
precisely what your requirement is. Less typing? Avoiding confusion
in the muscle memory?
These days I tend to deal with regexps much more often in perl, javascript and php, so
when I'm back in Emacs-land, doing a query-replace or a keyboard macro or something, I
have to switch mental gears, and do a lot more typing on the Emacs side of things. And I
never remember what the Emacs equivalents of \d and \s are, so I end up typing those out
in even longer forms, like
[ SPC C-q TAB C-q C-j ]
which I type all the time, but it's still pretty hard to touch-type right the first
time! (One of my biggest frustrations is when I'm composing a keyboard macro, and all
the C-q contortions when typing a regexp cause me to do something that rings the bell and
aborts the whole macro.)
It also sure would be nice if copying a regexp from some random piece of perl code and
pasting it into emacs-lisp code just worked, and vice versa. Many times I've tried to
re-use old work and had to spend a while converting it manually, which is very
error-prone.
Also, the perl "x" syntax (allowing inline whitespace and comments) is really
nice. You can fake most of that in emacs by splitting a regexp into multiple lines and
using concat, but the more concise syntax would be better.
Random thought: what if the #r syntax allowed arbitrary delimiters like sed's
"s" does, so that #r"foo\bar" was equivalent to #r/foo\bar/ and
#r＠foo\bar＠ ? That would also allow trailing regexp flags like #r/foo/i and #r/foo \s+
bar/x.
Bound variables can be a PITA deep in a function, and re-search-* are
used in a lot of code.
True. case-fold-search is an analogous precedent, but that doesn't necessarily make
it a good idea.
--
Jamie Zawinski http://www.jwz.org/ http://www.dnalounge.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:41 a.m.
Lars Magne Ingebrigtsen writes:
Jamie Zawinski <jwz(a)jwz.org> writes:
> I suppose a bound variable around re-search-forward, to indicate the
> parsing style, would be the way to go. That, or a separate function
> for new-style, like PHP does.
Or, perhaps, a new reader syntax for the new-style regexps. Like:
(re-search-forward #"(\s+)" nil t)
-1.
These are just strings that happen to be in regexp syntax, that we
then feed to a regexp engine. It would be really ugly to do
CHECK_STRING_OR_ALTERNATE_REGEXP_SYNTAX(object);
everywhere, and it would break old code that does CHECK_STRING. We
could redefine CHECK_STRING, I suppose, but ... no, this is too hacky.
Besides, what do we do when we decide to introduce Unicode-conforming
regexps or XML regexps? More syntax, more object types?
AFAICS, Jamie's basic request for more elegant input can be satisfied
with a straightforward (though the corner cases are likely to be
tedious) string translation, which emulates PCRE syntax, and adds some
new operators to handle Emacs extensions like matching charsets and
Mule character classes.
I wouldn't be surprised if the needed functions already exist in
somebody's "regexp explorer" library.
Then you can write
(re-search-forward (pcre-to-emacs-re #r"\bstr(i|o)ng\b") ...)
to get the effect of
(re-search-forward "\\bstr\\(i\\|o\\)ng\\b" ...)
and
(defun re-search-forward-command (regexp)
(interactive "s")
(when re-search-commands-use-pcre
(setq regexp (pcre-to-emacs-re regexp)))
(re-search-forward regexp))
or
(defun re-search-forward-command (regexp)
(interactive "s")
(re-search-forward (cond ((eq re-search-command-syntax 'pcre)
(pcre-to-emacs-re regexp))
;; add new syntaxes here
((null re-search-command-syntax)
regexp)
(t (error 'invalid-state
"not a known regexp syntax"
re-search-command-syntax)))))
Finally, pcre-to-emacs-re can be a compiler macro that pretranslates
the regexp, so that there's no run-time cost for literal regexps in
compiled code. As long as you don't build up regexps in a non-
syntactic way, you can do this for computed regexps, too.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:43 a.m.
Stephen J. Turnbull writes:
Interactively we already support single-slash input. Recent XEmacs
21.5 supports a raw string syntax. #r"stri\ng" for example is lexed
as a string with a single backslash and no line breaks.
Oops, that may not be correct for our syntax. But you get the idea.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:40 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Then you can write
(re-search-forward (pcre-to-emacs-re #r"\bstr(i|o)ng\b") ...)
That sounded strangely familiar... Look what I found in my ~/lisp
directory!
:-)
It obviously never went anywhere. I seem to remember finding the whole
thing rather cumbersome to work with. Of course, I didn't have the nice
#r"" thing to work with at the time...
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:47 a.m.
Lars Magne Ingebrigtsen writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Then you can write
>
> (re-search-forward (pcre-to-emacs-re #r"\bstr(i|o)ng\b") ...)
That sounded strangely familiar... Look what I found in my ~/lisp
directory!
Hrm. Seems to have been stripped by Mailman. Could you resend as one
of the following types?
text/plain
application/octet-stream
text/x-patch
application/x-patch
text/emacs-lisp
(Note: application/emacs-lisp is not permitted; that way lies Internet
Exploiter.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:54 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> That sounded strangely familiar... Look what I found in my
~/lisp
> directory!
Hrm. Seems to have been stripped by Mailman. Could you resend as one
of the following types?
text/plain
Ok, here goes:
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:48 p.m.
Nelson Ferreira <nelson.ferreira(a)ieee.org> writes:
> (re-search-forward #"(\s+)" nil t)
>
> Or #/(\s+)/? #/"(\s+)"? Anyway, the low-level regexp functions could
> do the dispatch on the object type instead of introducing new
> functions.
XEmacs 21.5b28 ported that syntax from SXEmacs in 2007 ;)
:-)
What are the plans for XEmacs (in general) with new releases? Is XEmacs
21.5 going to be the new "released" version at some point? And are you
going to import stuff en masse (like url.el and friends) from Emacs
after you've gotten the GPLv3 stuff done?
--
(domestic pets only, the antidote for overdose, milk.)
larsi(a)gnus.org * Lars Magne Ingebrigtsen
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:56 a.m.
New subject: XEmacs release plans [was: regexps]
Lars Magne Ingebrigtsen writes:
What are the plans for XEmacs (in general) with new releases? Is
XEmacs
21.5 going to be the new "released" version at some point?
Yes. It's not clear to me when; I'm not happy with several of the
features currently in development (most particularly the lack of
proper customization support for fontconfig and Xft; and the stalled
update of the GTK+ port to GTK+ v2 (!!)). But if the consensus of the
developers is to release and be damned, I'll go along (and I'm pretty
sure we'll be damned but that's life in the big city for you ;-).
And are you going to import stuff en masse (like url.el and
friends) from Emacs after you've gotten the GPLv3 stuff done?
"Stuff", yes. comint-related "stuff", gdb/gud.el, and jit-lock are
highest priority, IMO (nb, that's a +1, not a BDFL pronouncement --
XEmacs doesn't have a BDFL). url.el, probably pretty low priority, as
I suppose we'll probably settle on curl (I have a native binding for
*nix, and SXEmacs has kindly provided a port of their FFI
implementation which includes an FFI-based binding) and/or neon (I
have a native binding for *nix) for web services for the near future.
If a port of url.el would make your life easier, specifically for
developing Gnus, I'm not sure how many of the heavy Gnus users remain
in XEmacs proper. Steve Youngs (of course), and I believe Nelson and
maybe Norbert Koch, are Gnusers over on the SXEmacs side. Since we
share packages still, and url.el is in a package (w3, but if needed it
could be split out easily enough), you might lobby those guys to
better effect. Of course you can lobby us, too, but I don't know how
much interest there will be with all the other things we need/want to
do. Then again, maybe Steve B. will come back, he keeps making
noises....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:18 a.m.
New subject: XEmacs release plans
Stephen J. Turnbull wrote:
If a port of url.el would make your life easier, specifically for
developing Gnus, I'm not sure how many of the heavy Gnus users remain
in XEmacs proper.
I'm here, at least theoretically...
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:34 p.m.
New subject: XEmacs release plans [was: regexps]
On 1/4/11, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Lars Magne Ingebrigtsen writes:
do. Then again, maybe Steve B. will come back, he keeps making
noises....
Stranger things have happened.
(A belated Merry Christmas and Happy New Year to everyone).
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:24 a.m.
New subject: XEmacs release plans
Didier Verna <didier(a)xemacs.org> writes:
Stephen J. Turnbull wrote:
> If a port of url.el would make your life easier, specifically for
> developing Gnus, I'm not sure how many of the heavy Gnus users remain
> in XEmacs proper.
I'm here, at least theoretically...
Me, too. Very heavy.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:30 a.m.
New subject: XEmacs release plans
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
Michael> Me, too. Very heavy.
What would Emacsen be without Gnus? Count me in!
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:40 a.m.
New subject: XEmacs release plans
Mats Lidell <matsl(a)xemacs.org> wrote:
>>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
Michael> Me, too. Very heavy.
What would Emacsen be without Gnus? Count me in!
A software without a proper test suite :-)
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:14 p.m.
New subject: XEmacs release plans
Didier Verna writes:
Mats Lidell <matsl(a)xemacs.org> wrote:
>>>>>> Michael Sperber <sperber(a)deinprogramm.de> writes:
> Michael> Me, too. Very heavy.
>
> What would Emacsen be without Gnus? Count me in!
A software without a proper test suite :-)
Hey, stop upstaging! Don't bogart *my* line!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:08 p.m.
New subject: gnus [was: Re: XEmacs release plans]
Me, too. Very heavy.
I consider myself a pretty serious Gnus user, but probably not in the
league of some of those who've followed up..
Could one of you heavy Gnus users advise me on getting better mail
performance? I was thinking of switching from nnfolder to nnmaildir
but was a little concerned about having the splitting performance be
worse based on the comparison page in the info manual's comments
regarding nnml splitting performance and similarities of that backend
to nnmaildir. Which backend do you guys use? And how do I move my
existing mail to a new backend?
thanks,
Greg
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:45 p.m.
New subject: gnus [was: Re: XEmacs release plans]
On Wed, Jan 5, 2011 at 5:08 PM, Greg Klanderman <gak(a)klanderman.net> wrote:
> Me, too. Very heavy.
I consider myself a pretty serious Gnus user, but probably not in the
league of some of those who've followed up..
Could one of you heavy Gnus users advise me on getting better mail
performance? I was thinking of switching from nnfolder to nnmaildir
but was a little concerned about having the splitting performance be
worse based on the comparison page in the info manual's comments
regarding nnml splitting performance and similarities of that backend
to nnmaildir. Which backend do you guys use? And how do I move my
existing mail to a new backend?
I don't use anything other than nnimap with server-side splitting, but as I
recall 'B m' will move email even between groups on different backends.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:04 p.m.
New subject: gnus
Greg Klanderman <gak(a)klanderman.net> writes:
Could one of you heavy Gnus users advise me on getting better mail
performance? I was thinking of switching from nnfolder to nnmaildir
but was a little concerned about having the splitting performance be
worse based on the comparison page in the info manual's comments
regarding nnml splitting performance and similarities of that backend
to nnmaildir. Which backend do you guys use? And how do I move my
existing mail to a new backend?
I wrote the manual's comparison section, originally as a Usenet posting
that Lars edited into the manual, and I use nnml. It has always
performed quite adequately for me, and I like nnml's "nearly nnspool"
nature a great deal. Message-per-file splitting has never seemed all
that problematic. And once mail has been split to files in groups,
performance is as high as you can get.
`B m' moves mail around. It still won't be pretty if you have Gbytes of
mail to move. Experiment with `B c' to copy messages somewhere
temporary (deletable) before you commit to wholesale `B m' movement.
--karl,
hacking (then-)GNUS since 1988
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:48 p.m.
New subject: gnus [was: Re: XEmacs release plans]
On Wed, 05 Jan 2011 11:08:30 -0500, Greg wrote:
Could one of you heavy Gnus users advise me on getting better mail
performance?
(I don't know if I am a heavy user, but I am a long time user; anyway:)
I use nnml for my email, and that works nicely for me.
nnimap has been improved a lot recently in the development version of
Gnus, so if you need IMAP, that might be a way to go.
Many people use IMAP so they can access the same email (folders etc)
from different clients/computers. I just ssh to my desktop-machine and
read email that way, so I prefer nnml to nnimap.
I was thinking of switching from nnfolder to nnmaildir but was a
little concerned about having the splitting performance be worse based
on the comparison page in the info manual's comments regarding nnml
splitting performance and similarities of that backend to nnmaildir.
I haven't had any performance issues with splitting and nnml - could you
elaborate a little on what you fear?
Which backend do you guys use? And how do I move my existing mail to
a
new backend?
Moving is quite easy - mark the emails with # and use B m to move them
to another mail group. If you have got a lot of email it will take a
while, but I guess it is a one-time thing.
Best regards,
--
"Accept the mystery!" Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:10 a.m.
New subject: gnus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greg Klanderman writes:
Could one of you heavy Gnus users advise me on getting better mail
performance? I was thinking of switching from nnfolder to nnmaildir
but was a little concerned about having the splitting performance be
worse based on the comparison page in the info manual's comments
regarding nnml splitting performance and similarities of that backend
to nnmaildir. Which backend do you guys use? And how do I move my
existing mail to a new backend?
Does 200--400 messages a day count as heavy? I use nnml, with
approx. 200 different groups and a 120-line nnmail-split-fancy, and
I've never noticed any performance problems. . .
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFNJaNBkjnJixAXWBoRAh0VAJ94Kk8dKbrEJwNuYMWkZVplM569kQCdFV1K
Ac5AwxiF08pMACOrBQVYhP0=
=Yqpy
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4853
days inactive
4860
days old
24 comments
13 participants
participants (13)
-
Adam Sjøgren -
Didier Verna -
Greg Klanderman -
Henry S. Thompson -
Jamie Zawinski -
Karl Kleinpaste -
Lars Magne Ingebrigtsen -
Michael Sperber -
Nelson Ferreira -
Robert Pluim -
SL Baur -
Stephen J. Turnbull -
The XEmacs Package Smoketest