Hi, (Just checked out latest on MAIN) Configure problem. When running configure I get this: ---------------------------------------------------------------------- [...] creating ./config.status creating Makefile.in creating lib-src/Makefile.in creating lwlib/Makefile.in creating src/Makefile.in creating src/paths.h creating lib-src/config.values creating lib-src/ellcc.h creating src/config.h creating lwlib/config.h creating ./Makefile creating ./GNUmakefile creating lib-src/Makefile creating lib-src/GNUmakefile creating lwlib/Makefile creating lwlib/GNUmakefile creating src/Makefile junk.c:99:2: invalid preprocessing directive #Object junk.c:101:2: invalid preprocessing directive #NOTE junk.c:102:2: invalid preprocessing directive #others junk.c:103:2: invalid preprocessing directive #here junk.c:104:2: invalid preprocessing directive #They junk.c:105:2: invalid preprocessing directive #when junk.c:106:2: invalid preprocessing directive #needed junk.c:107:2: invalid preprocessing directive #duplicate creating src/GNUmakefile junk.c:99:2: invalid preprocessing directive #Object junk.c:101:2: invalid preprocessing directive #NOTE junk.c:102:2: invalid preprocessing directive #others junk.c:103:2: invalid preprocessing directive #here junk.c:104:2: invalid preprocessing directive #They junk.c:105:2: invalid preprocessing directive #when junk.c:106:2: invalid preprocessing directive #needed junk.c:107:2: invalid preprocessing directive #duplicate ---------------------------------------------------------------------- Yours -- %% Mats

Ben> ok, i think i fixed it. I think so too! Works fine now. Yours -- %% Mats

Stef> /opt/xemacs/src/xemacs-21.6/lisp/behavior-defs.el: Stef> !! File error (("Cannot open load file" "func-menu")) func-menu is in the edit-utils package. Apparently for some reason XEmacs can't find it on your system. Ben: we need to do define-behavior in the package for functions that are defined in packages. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Stephen> func-menu is in the edit-utils package. Apparently for Stephen> some reason XEmacs can't find it on your system. Mats> Why are the packages needed or even seen while building the Mats> binary? They shouldn't be needed at all or? beta is beta, you take your chances. (However, I'm going to submit a patch to enforce a cleaner environment; we'll see if it gets accepted. ;-) Ben's adding a new feature, define-behavior, so that when you turn on a feature like fontify or filladapt, existing buffers _also_ get the new behavior. What happened here is that to do this for func-menu you need some func-menu code, so he required it. He probably didn't think about func-menu being in the packages. There are also dependencines on the packages in the test suite. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Ben Wing <ben(a)666.com&gt; writes: Hi Ben! I see the following build error on my FreeBSD 4.5-STABLE i386 box: gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -Wshadow -Wpointer-arith -Demacs -I. -DHAVE_CONFIG_H -I/usr/local/include -I/usr/X11R6/include sysdep.c In file included from sysproc.h:55, from sysdep.c:72: /usr/include/sys/socket.h:54: warning: empty declaration sysdep.c: In function `get_process_times_1': sysdep.c:3489: storage size of `tttt' isn't known sysdep.c:3490: warning: implicit declaration of function `times' sysdep.c:3489: warning: unused variable `tttt' gmake[1]: *** [sysdep.o] Error 1 gmake[1]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-21.5/src' gmake: *** [dump-elcs] Error 2 norbert.

please check out the new workspace. Alexander Reinwarth wrote:

please check out the new workspace. Norbert Koch wrote:

hmm, i don't understand. can you run with -q, and try (get-language-environment-from-locale "C") in *scratch* and see if it infloops? Norbert Koch wrote:

Josh Huber <huber(a)alum.wpi.edu&gt; writes: Scratch that...there is no infinite loop for me -- xemacs was just using a LOT of memory (>60M), and was taking quite some time to start gnus because of all the GC going on. Why is the new xemacs using so much memory? ttyl, -- Josh Huber

i have no clue. i wish you could find out; it doesn't happen for me. my xemacs.exe is using 15 MB. we do use more memory with the unicode tables, but that should only be on the order of 1 MB. i wrote a fun to show memory usage. update to the latest cvs and do M-x show-memory-usage. let me know if you see anything weird. Josh Huber wrote:

On Tue, 19 Mar 2002, Daniel Pittman wrote: [...] [...] That should have been 59,236 /kilo/ bytes. :) ...and on further investigation, this is actually worse than I thought. I sat through a full startup with Ben-MULE. This means that my code did a whole bunch of face manipulation, loaded a number of things including BBDB, CC-mode, did a bit of byte-compiling, then started Gnus. No garbage collection occurred between the drop described above and the completion of loading of Gnus -- it seems that .xemacs/init.el is run with garbage collection disabled. This is suboptimal, IMO, because it results in a much larger fragmented image when the init process is done. Anyway, this startup run had a peak image size of around 485MB, dropping down to 125MB or so when it did a GC pass after the init file had finished. Sadly I can't track down exactly *where* this memory allocation is coming from. The closest I can get is that it centers around the set of calls `Ffuncall', `Feval', `execute_optimized_program' and `funcall_compiled_function'. Obviously this is the core loop of the Lisp engine. I can't for the life of me see what, if anything, in there is causing this bloom in memory usage, though. Worse still, none of the information that I can extract from the memory profiler[1] seems to account for it -- it looks like those functions are (recursively) doing the needed allocation directly, not calling sub-functions which do it. :( I can't really test beyond this point at the moment, partly because I should do some real work and partly because I am out of ideas as to what more I /can/ do to trace down this problem. Er, does anyone out there know of a memory allocation tracing tool that works with Linux and XEmacs? Other, sadly, than Purify, which I have no license for. Daniel Footnotes: [1] memprof, a Linux-based tool, run against the lined xemacs. -- The two greatest obstacles to democracy in the United States are, first, the widespread delusion among the poor that we have a democracy, and second, the chronic terror among the rich, lest we get it. -- Edward Dowling

On Tue, 19 Mar 2002, Ben Wing wrote: [...] [...] [...] That /is/ running with -vanilla -- running my normal startup is the other report I posted, with an image of ~480MB during startup and ~350MB of it garbage... [...] When I caught it about half way through the startup it was doing `assoc-ignore-case' in the MULE startup code. This wasn't a rigorous sample, though, and might have missed other causes. In progress ... and that resolves it. A '-vanilla -q' run built without MULE hit 17MB total allocated, and almost no garbage, during startup. It's also worth noting that it seemed to show a much lower level of garbage accumulating while starting up. Now, if only I didn't need MULE to get International characters I would be a happy camper. :) Ah, good. That looks like useful. If I get a bit of time, which I should[1], I hope to try and further trace down where the memory allocation is actually happening in the core Lisp evaluation code. Daniel Footnotes: [1] My G/F is doing dress rehearsals and the evenings are ... boring. :) -- There is no happiness in having or in getting, but only in giving. -- Henry Drummond

Nickolay> Checked out ben-mule-21-5 today. Nickolay> Compiled as windows native on Windows 2000. Nickolay> `pop3-read-response' from pop3.el hangs when talks to POP3 server. Nickolay> The problem is with the code: Nickolay> (while (not (search-forward "\r\n" nil t)) Nickolay> (accept-process-output process) Nickolay> (goto-char pop3-read-point)) Nickolay> The loop works until there is a complete string, i.e. a Nickolay> string ending with CRLF. BUT under xemacs the Nickolay> pop-process buffer DOES NOT contain CRLF at line ends. Nickolay> Instead it leaves just linefeed (^J) at the end. Nickolay> Consequently the loop condition is always true and the Nickolay> loop never breaks. Nickolay> I removed searches for CR in pop3.el and it Nickolay> worked. Still it not a good solution, IMHO. I have the same problem. What was the fix? I thought a saw a followup from Stephen to this but can't find it now. Thanks in advance, Adrian Nickolay> Nick. -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Crash occured when XEmacs was receiving a VERY long mail (attachment several Mb long). Fatal error: assertion failed, file c:\software\SRC\xemacs-win-mule\nt\..\src\al loc.c, line 1847, i == (Bytecount) XSTRING_ASCII_BEGIN (str) || (i > MAX_STRING_ ASCII_BEGIN && (Bytecount) XSTRING_ASCII_BEGIN (str) == (Bytecount) MAX_STRING_A SCII_BEGIN) Fatal error. Your files have been auto-saved. Use `M-x recover-session' to recover them. If you have access to the PROBLEMS file that came with your version of XEmacs, please check to see if your crash is described there, as there may be a workaround available. Otherwise, please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org&#39;. *MAKE SURE* to include the information in the command M-x describe-installation. Lisp backtrace follows: insert-buffer-substring(#<buffer "trace of POP session to sever"> 236 #<marker at 2435127 in trace of POP session to sever 0x2de955c>) # (unwind-protect ...) # bind (oldbuf end start buffer) append-to-buffer(#<buffer " *pop3-retr*"> 236 #<marker at 2435127 in trace of POP session to sever 0x2de955c>) # bind (retrieved) # (unwind-protect ...) # bind (crashbuf msg process) pop3-retr(#<network connection "POP" (110 . "sever") state:exit> 1 #<buffer " *pop3-retr*">) # (unwind-protect ...) # bind (message-list retrieved-messages password message-count msglen msgid n crashbuf process crashbox) pop3-movemail("~/.emacs-mail-crash-box") # (unwind-protect ...) byte-code("..." [mail-source-crash-box pop3-movemail] 2) # (condition-case ... . ((error (byte-code "?+?\n\"\n\"??+ ＠ A\"??" . .. 4)))) # bind (pop3-password pop3-maildrop pop3-mailhost pop3-port pop3-authenticatio n-scheme from mail-source-string result authentication password function program user port server postscript prescript-delay prescript callback source) mail-source-fetch-pop((pop :server "sever" :user "npak") (lambda (file orig-fi le) (nnmail-split-incoming file (quote nnml-save-mail) (quote nil) (nnmail-get-s plit-group orig-file source) (quote nnml-active-number)))) funcall(mail-source-fetch-pop (pop :server "sever" :user "npak") (lambda (file orig-file) (nnmail-split-incoming file (quote nnml-save-mail) (quote nil) (nnma il-get-split-group orig-file source) (quote nnml-active-number)))) # (condition-case ... . ((error (byte-code "?-?-?\"!?????-?+!???¦??" ... 4)))) # bind (function found) # (unwind-protect ...) # bind (plugged callback source) mail-source-fetch((pop :server "sever" :user "npak") (lambda (file orig-file) (nnmail-split-incoming file (quote nnml-save-mail) (quote nil) (nnmail-get-split -group orig-file source) (quote nnml-active-number)))) # bind (source incomings incoming total new i group-in fetching-sources source s spool-func group temp exit-func method) nnmail-get-new-mail(nnml nnml-save-nov "c:/tmp/gnus/Mail/" nil) # bind (server group) nnml-request-scan(nil "private") # bind (gnus-command-method gnus-inhibit-demon mail-source-plugged gnus-comman d-method group) gnus-request-scan(nil (nnml "private")) # bind (where mesg force method) gnus-read-active-file-1((nnml "private") nil) # (condition-case ... . ((quit (message "Quit reading the active file")))) # (unwind-protect ...) # bind (methods method not-native force) gnus-read-active-file() # bind (gnus-inhibit-demon nnmail-fetched-sources arg) gnus-group-get-new-news(nil) # bind (command-debug-status) call-interactively(gnus-group-get-new-news) # (condition-case ... . error) # (catch top-level ...) C backtrace assert_failed(const char * 0x0125b1cc, int 0x00000737, const char * 0x0125b130) line 3518 sledgehammer_check_ascii_begin(long 0x02da6d24) line 1847 + 88 bytes init_string_ascii_begin(long 0x02da6d24) line 2153 + 9 bytes make_string_from_buffer_1(buffer * 0x022dc000, long 0x000000ec, long 0x0025274b, int 0x00000000) line 1646 + 9 bytes make_string_from_buffer(buffer * 0x022dc000, long 0x000000ec, long 0x0025274b) line 1656 + 19 bytes buffer_insert_from_buffer_1(buffer * 0x025d2a00, long 0xffffffff, buffer * 0x022dc000, long 0x000000ec, long 0x0025274b, int 0x00000000) line 1255 + 17 bytes Finsert_buffer_substring(long 0x022dc000, long 0x000001d9, long 0x02de955c) line 1685 + 31 bytes Ffuncall(int 0x00000004, long * 0x0082cfe0) line 3479 + 127 bytes execute_optimized_program(const unsigned char * 0x022c23d0, int 0x00000004, long * 0x01c4bf90) line 744 + 16 bytes funcall_compiled_function(long 0x01c3eecc, int 0x00000003, long * 0x0082d2c4) line 516 + 53 bytes Ffuncall(int 0x00000004, long * 0x0082d2c0) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x022dd190, int 0x00000005, long * 0x0229e310) line 744 + 16 bytes funcall_compiled_function(long 0x022e51a8, int 0x00000003, long * 0x0082d5a8) line 516 + 53 bytes Ffuncall(int 0x00000004, long * 0x0082d5a4) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x022cd210, int 0x00000007, long * 0x022dbf10) line 744 + 16 bytes funcall_compiled_function(long 0x02295f3c, int 0x00000001, long * 0x0082d894) line 516 + 53 bytes Ffuncall(int 0x00000002, long * 0x0082d890) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x0082da74, int 0x00000002, long * 0x0220f470) line 744 + 16 bytes Fbyte_code(long 0x0227a5a4, long 0x0220f460, long 0x00000005) line 2392 + 38 bytes Feval(long 0x02221b28) line 3281 + 187 bytes condition_case_1(long 0x0215bbd0, long (long)* 0x01094cd7 Feval(long), long 0x02221b28, long (long, long)* 0x01092256 run_condition_case_handlers(long, long), long 0x01c723dc) line 1692 + 7 bytes condition_case_3(long 0x02221b28, long 0x01c723dc, long 0x0215bbd0) line 1779 + 27 bytes execute_rare_opcode(long * 0x0082dd80, const unsigned char * 0x022b85b6, int 0x0000008f) line 1269 + 19 bytes execute_optimized_program(const unsigned char * 0x022b8510, int 0x0000000f, long * 0x0228ca10) line 654 + 17 bytes funcall_compiled_function(long 0x0227de40, int 0x00000002, long * 0x0082e08c) line 516 + 53 bytes Ffuncall(int 0x00000003, long * 0x0082e088) line 3514 + 17 bytes Feval(long 0x02216d2c) line 3307 + 20 bytes condition_case_1(long 0x020ff334, long (long)* 0x01094cd7 Feval(long), long 0x02216d2c, long (long, long)* 0x01092256 run_condition_case_handlers(long, long), long 0x01c723dc) line 1692 + 7 bytes condition_case_3(long 0x02216d2c, long 0x01c723dc, long 0x020ff334) line 1779 + 27 bytes execute_rare_opcode(long * 0x0082e368, const unsigned char * 0x0229edc4, int 0x0000008f) line 1269 + 19 bytes execute_optimized_program(const unsigned char * 0x0229ed90, int 0x00000005, long * 0x0228ac90) line 654 + 17 bytes funcall_compiled_function(long 0x0227dd0c, int 0x00000002, long * 0x0082e64c) line 516 + 53 bytes Ffuncall(int 0x00000003, long * 0x0082e648) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x022b2810, int 0x0000000f, long * 0x02146c10) line 744 + 16 bytes funcall_compiled_function(long 0x02281384, int 0x00000004, long * 0x0082e958) line 516 + 53 bytes Ffuncall(int 0x00000005, long * 0x0082e954) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x01ba78d0, int 0x00000005, long * 0x022be2d0) line 744 + 16 bytes funcall_compiled_function(long 0x022959c4, int 0x00000002, long * 0x0082ec3c) line 516 + 53 bytes Ffuncall(int 0x00000003, long * 0x0082ec38) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x022a8090, int 0x00000004, long * 0x02195b10) line 744 + 16 bytes funcall_compiled_function(long 0x02171608, int 0x00000002, long * 0x0082ef1c) line 516 + 53 bytes Ffuncall(int 0x00000003, long * 0x0082ef18) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x02155010, int 0x00000007, long * 0x02132410) line 744 + 16 bytes funcall_compiled_function(long 0x021c4af8, int 0x00000002, long * 0x0082f184) line 516 + 53 bytes Feval(long 0x02073730) line 3338 + 20 bytes condition_case_1(long 0x0206a888, long (long)* 0x01094cd7 Feval(long), long 0x02073730, long (long, long)* 0x01092256 run_condition_case_handlers(long, long), long 0x01b04804) line 1692 + 7 bytes condition_case_3(long 0x02073730, long 0x01b04804, long 0x0206a888) line 1779 + 27 bytes execute_rare_opcode(long * 0x0082f45c, const unsigned char * 0x01fdde48, int 0x0000008f) line 1269 + 19 bytes execute_optimized_program(const unsigned char * 0x01fdde10, int 0x00000005, long * 0x021ec590) line 654 + 17 bytes funcall_compiled_function(long 0x021c4adc, int 0x00000000, long * 0x0082f744) line 516 + 53 bytes Ffuncall(int 0x00000001, long * 0x0082f740) line 3514 + 17 bytes execute_optimized_program(const unsigned char * 0x02d4a310, int 0x00000003, long * 0x01fdd910) line 744 + 16 bytes funcall_compiled_function(long 0x02295480, int 0x00000001, long * 0x0082fa1c) line 516 + 53 bytes Ffuncall(int 0x00000002, long * 0x0082fa18) line 3514 + 17 bytes Fcall_interactively(long 0x0215c394, long 0x01b04804, long 0x01b04804) line 998 + 22 bytes Fcommand_execute(long 0x0215c394, long 0x01b04804, long 0x01b04804) line 2920 + 17 bytes execute_command_event(command_builder * 0x01ebb540, long 0x02da07ac) line 4055 + 25 bytes Fdispatch_event(long 0x02da07ac) line 4350 + 70 bytes Fcommand_loop_1() line 584 + 9 bytes command_loop_1(long 0x01b04804) line 497 condition_case_1(long 0x01b04864, long (long)* 0x01072979 command_loop_1(long), long 0x01b04804, long (long, long)* 0x01072390 cmd_error(long, long), long 0x01b04804) line 1692 + 7 bytes command_loop_3() line 258 + 35 bytes command_loop_2(long 0x01b04804) line 271 internal_catch(long 0x01b252a4, long (long)* 0x010724e0 command_loop_2(long), long 0x01b04804, int * volatile 0x00000000) line 1317 + 7 bytes initial_command_loop(long 0x01b04804) line 307 + 25 bytes STACK_TRACE_EYE_CATCHER(int 0x00000001, char * * 0x01dd1e80, char * * 0x01b48200, int 0x00000000) line 2301 main(int 0x00000001, char * * 0x01dd1e80, char * * 0x01b48200) line 2739 XEMACS! mainCRTStartup + 180 bytes _start() line 167 KERNEL32! 77e87903()

AA> Hi Nick, AA> how do you get pop3 working in MERGED-BEN-MULE? AA> I also have the problem that mail popping hangs. AA> When I quit I get: AA> Signaling: (quit) AA> accept-process-output(#<network connection "POP<1>" ("pop3" . "pop.t-online.com") state:run>) AA> pop3-read-response(#<network connection "POP<1>" ("pop3" . "pop.t-online.com") state:run> t) AA> pop3-open-server("pop.t-online.com" "pop3") I attached the patch below that makes pop3.el work. Still it seems VERY suspicios to me. I changed search patterns but the real fix should deal with coding systems IMHO. Nick. AA> Best regards, AA> Adrian --- mail-lib/pop3.el Fri Oct 6 13:40:48 2000 +++ /c/Program Files/XEmacs/xemacs-packages/lisp/mail-lib/pop3.el Mon Mar 18 14:39:18 2002 ＠＠ -283,8 +283,8 ＠＠ (save-excursion (set-buffer (process-buffer process)) (goto-char pop3-read-point) - (while (not (search-forward "\r\n" nil t)) - (accept-process-output process) + (while (not (search-forward "\n" nil t)) + (accept-process-output process 3) (goto-char pop3-read-point)) (setq match-end (point)) (goto-char pop3-read-point) ＠＠ -678,7 +678,7 ＠＠ "Get the extended pop3 response in the PROCESS buffer." (let ((start pop3-read-point) end) (set-buffer (process-buffer process)) - (while (not (re-search-forward "^\\.\r\n" nil t)) + (while (not (re-search-forward "^\\.\n" nil t)) (accept-process-output process) (goto-char start)) (setq pop3-extended-response-beginning start)

intro: "SJ" == Simon Josefsson <jas(a)extundo.com&gt; writes: SJ> On 18 Mar 2002, Nickolay Pakoulin wrote: AA> Signaling: (quit) accept-process-output(#<network connection "POP<1>" AA> ("pop3" . "pop.t-online.com") state:run>) AA> pop3-read-response(#<network connection "POP<1>" ("pop3" AA> . "pop.t-online.com") state:run> t) AA> pop3-open-server("pop.t-online.com" "pop3") SJ> This is the obvious fix, yes, but I think it is the wrong one. pop3 SJ> should disable EOL magic instead, and match on \r\n. I thought SJ> setting the read/write coding system to binary would be enough, but SJ> apparently it isn't. The solution is to set coding system for the process: --- mail-lib/pop3.el Fri Oct 6 13:40:48 2000 +++ /c/Program Files/XEmacs/xemacs-packages/lisp/mail-lib/pop3.el Mon Mar 18 15:12:22 2002 ＠＠ -248,6 +248,7 ＠＠ (erase-buffer)) (setq process (open-network-stream "POP" process-buffer mailhost port)) + (set-process-input-coding-system process 'binary) (setq pop3-read-point (point-min)) (let ((response (pop3-read-response process t))) (setq pop3-timestamp

On 18 Mar 2002, Nick V. Pakoulin wrote: I believe so. We have to change lots of code if not. Ben, is this a bug in 21.5? Can it be fixed?

Simon> On 18 Mar 2002, Nick V. Pakoulin wrote: Simon> Look a few lines up, and you see that Simon> `coding-system-for-{read,write}' is bound. It should be Simon> sufficient IMHO. Er, the function unbinds c-s-f-r as it returns the process. c-f-s-r is consulted by functions that read from streams, not by functions that create streams. So when you read from the process, the value of c-s-f-r is not bound. Nick's code sets the coding system for the process, which you can then return. Since this is part of the process, it works. Don't ask me why the API is designed this way. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Simon> But simply binding c-s-f-* when opening the stream used to Simon> work. If pop3 and nntp now both breaks, I'd say something Simon> changed in 21.5 that triggers this. Maybe it can be Simon> reverted. Yeah, you're right. process.c:init_process_io_handles has changed in ways that might account for this. It looks like processes now get set to default-process-coding-system no matter what c-s-f-* are. Ben probably didn't intend it to work out that way. OTOH, the c-s-f-* interface is really horrible. Maybe he did ;-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

APA> We also need to test for file-coding (or boundedness of APA> involved variables and functions) in any patches to pop3.el APA> or nntp.el not to break under released XEmacsen built without APA> file-coding feature. Right, but those tests should already be there---we're not going to be using any functionality we hadn't used before. So just make sure we stay inside of them. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.