Gnus development mailing list
 help / color / mirror / Atom feed
From: Michael Baer <baerm@mikesoffice.com>
To: Katsumi Yamaoka <yamaoka@jpl.org>
Cc: xemacs-beta@xemacs.org, ding@gnus.org,
	Michael Baer <gnus@mikesoffice.com>
Subject: Re: Error sending attached files
Date: Mon, 19 Jan 2009 22:16:46 -0800	[thread overview]
Message-ID: <m3mydm33jl.fsf@mikesoffice.com> (raw)
In-Reply-To: <b4miqocm3lf.fsf@jpl.org> (Katsumi Yamaoka's message of "Mon\, 19 Jan 2009 11\:28\:28 +0900")

>>>>> On Mon, 19 Jan 2009 11:28:28 +0900, Katsumi Yamaoka <yamaoka@jpl.org> said:

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.

-Mike

>>>>> 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.

    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:
    KY> [...]
    >>>> 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)
    KY>             ^^^^^^^^^
    KY> (The function `insert-file-contents' defined in
    KY> code-files.el
    KY>  determines it according to `coding-system-for-read',
    KY>  `buffer-file-coding-system-for-read', etc.)

    >>>> byte-code("..." [buffer-file-coding-system-for-read
    KY> [...]
    >>>> 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()
    KY> [...]
    >>>> It's not making much sens to me, but any suggestions would
    >>>> definitely be appreciated,


-- 
Michael Baer
baerm@mikesoffice.com

      reply	other threads:[~2009-01-20  6:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13  5:52 Michael Baer
2009-01-17 20:22 ` Reiner Steib
2009-01-18 10:58   ` Aidan Kehoe
2009-01-19  2:28     ` Katsumi Yamaoka
2009-01-20  6:16       ` Michael Baer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3mydm33jl.fsf@mikesoffice.com \
    --to=baerm@mikesoffice.com \
    --cc=ding@gnus.org \
    --cc=gnus@mikesoffice.com \
    --cc=xemacs-beta@xemacs.org \
    --cc=yamaoka@jpl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).