Looks like a problem in XEmacs' `insert-file-contents-internal' to me. Cc-ing xemacs-beta...

On Tue, Jan 13 2009, Michael Baer wrote: > I've been having an error when sending attached files with gnus > email that has been driving me crazy. I was hoping someone on this > list might have some insight into the problem. It is somewhat > inconsistent and seems to happen more often with pdf and MS Word > files. If it happens with a file, it won't send that file and will > continue to fail on repeated tries. Although, if I reopen and save > a doc again with Openoffice or convert a pdf to something else, it > often will send the new file. I usually attach the file with > mml-attach-file (C-c C-a), but when I try to send I get the error > message below: > > Invalid operation: No more character sets free for this dimension, 1 > > The error message is kind of amusing, but doesn't really make much > sense to me in this context. > > I'm using a Fedora 9 on a PPC platform, and I was using the version > of gnus that is standard on F9 (I forget what version gnus is, it's > xemacs 21.5.28-6) but I switched to the source gnus-5.10.10 with no > noticeable change in this error. > > The debug on error output is: > > Debugger entered--Lisp error: (invalid-operation "No more character sets free for this dimension" 1) > insert-file-contents-internal("~/wtemp/scan/temp.pdf" nil nil nil > nil undecided used-codesys) > byte-code("..." [buffer-file-coding-system-for-read > coding-system-for-read return-val visit filename coding-system > run-hook-with-args insert-file-contents-access-hook > run-hook-with-args-until-success insert-file-contents-pre-hook > find-file-coding-system-for-read-from-filename raw-text > find-coding-system lwarn notice "Invalid coding-system (%s), using > 'undecided" undecided insert-file-contents-internal used-codesys > start end replace] 9) > insert-file-contents("~/wtemp/scan/temp.pdf" nil nil nil nil) > mm-insert-file-contents("~/wtemp/scan/temp.pdf" nil nil nil nil t) [...] > mml-generate-mime() > message-encode-message-body() > message-send-mail(nil) > message-send-via-mail(nil) > message-send(nil) > message-send-and-exit(nil) > call-interactively(message-send-and-exit) > > It's not making much sens to me, but any suggestions would > definitely be appreciated, Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

>>>> On Mon, 19 Jan 2009 11:28:28 +0900, Katsumi Yamaoka <yamaoka(a)jpl.org&gt; said:

>>>> Aidan Kehoe wrote: > Ar an seachtú lá déag de mí Eanair, scríobh Reiner Steib:

>> Looks like a problem in XEmacs' >> `insert-file-contents-internal' to me. Cc-ing >> xemacs-beta...

> As far as I can tell, our encoding autodetection code thinks > the file is ISO 2022 JP, and is auto-allocating character > sets and running out of them. What does Gnus bind > coding-system-for-read to? It should be binary for this use > case.

>> On Tue, Jan 13 2009, Michael Baer wrote:

>>> Debugger entered--Lisp error: (invalid-operation "No more >>> character sets free for this dimension" 1) >>> insert-file-contents-internal("~/wtemp/scan/temp.pdf" nil >>> nil nil nil undecided used-codesys)

>>> byte-code("..." [buffer-file-coding-system-for-read

>>> insert-file-contents("~/wtemp/scan/temp.pdf" nil nil nil >>> nil) mm-insert-file-contents("~/wtemp/scan/temp.pdf" nil >>> nil nil nil t) >> [...] >>> mml-generate-mime()

>>> It's not making much sens to me, but any suggestions would >>> definitely be appreciated,

On 2009-01-17, Reiner Steib <reinersteib+gmane(a)imap.cc&gt; wrote: > Looks like a problem in XEmacs' `insert-file-contents-internal' to me. > Cc-ing xemacs-beta... > > On Tue, Jan 13 2009, Michael Baer wrote: > >> I usually attach the file with mml-attach-file (C-c C-a), but when I >> try to send I get the error message below: >> >> Invalid operation: No more character sets free for this dimension, 1 Here's a guess, which is the first thing that comes to mind. Obviously, a reproducible example would be helpful. XEmacs is loading the file, guessing the encoding, and guessing it's Unicode. But it's actually binary junk, so it ends up trying to handle more Unicode characters than XEmacs can. (Because of the horrible nature of the way XEmacs currently handles Unicode, it can only cope with "tens of thousands" of distinct characters beyond those that Mule

already knows about, and when it runs out of space, the above error is what will happen.)

As to why it might doing that, I can't imagine. Loading an attachment should be done in binary coding,

and surely gnus must normally do that correctly, or nothing would ever work. Reproducible example needed!