Jamie Zawinski <jwz(a)jwz.org&gt; writes: 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

On 1/2/2011 11:21 PM, Lars Magne Ingebrigtsen wrote: 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

Lars Magne Ingebrigtsen writes: 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 ;-). "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

Didier Verna <didier(a)xemacs.org&gt; writes: 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

Mats Lidell <matsl(a)xemacs.org&gt; wrote: 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

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

Greg Klanderman <gak(a)klanderman.net&gt; writes: 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Klanderman writes: 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] _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Lars Magne Ingebrigtsen writes: -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

Lars Magne Ingebrigtsen writes: 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

Jamie Zawinski writes: XEmacs should, yes. 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. 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? 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

Stephen J. Turnbull writes: 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