>>>> On Mon, 19 Jan 2009 11:28:28 +0900, Katsumi Yamaoka
Cool, thanks!, this definitely helped me track down a work-around.
I don't know what is actually causing the problem (It seems unique
to me), but by adding the .pdf extension to the
file-coding-system-alist for binary, it will successfully send files
that were previously failing.
>>>> 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
> 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
KY> Gnus should bind `coding-system-for-read' then to the value
KY> of `mm-binary-coding-system' that defaults to `binary'.
KY> However, it seems to have been set to nil or `undecided':
>> On Tue, Jan 13 2009, Michael Baer wrote:
>>> Debugger entered--Lisp error: (invalid-operation "No
>>> character sets free for this dimension" 1)
>>> insert-file-contents-internal("~/wtemp/scan/temp.pdf" nil
>>> nil nil nil undecided used-codesys)
KY> (The function `insert-file-contents' defined in
KY> determines it according to `coding-system-for-read',
KY> `buffer-file-coding-system-for-read', etc.)
nil nil nil
>>> nil) mm-insert-file-contents("~/wtemp/scan/temp.pdf" nil
>>> nil nil nil t)
>>> It's not making much sens to me, but any suggestions
>>> definitely be appreciated,
XEmacs-Beta mailing list