Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Reiner Steib]

On Wed, Sep 21 2011, Stephen J. Turnbull wrote:

> Uwe Brauer writes:
>
>  > This is bizzare: I have install a no-gnus version which I
>  > use either with 21.4.22 Or 21.5.29.
>  > 
>  > I wanted to send a message with 2 PDF attachments. It worked
>  > fine in 21.4.22 but in 21.5.29 I obtained an error which I
>  > attach. Since it works in 21.4.22 I hesitate to send a bug
>  > report to the gnus list.
>
> Unfortunately, this isn't bizarre at all.  Both XEmacs 21.5 and Gnus
> use private space character sets internally for various purposes, and
> you contribute to that by using X-symbol, most likely.  There are only
> about 10 of them so it's a scarce resource.
>
> Please show us the output of M-x list-character-sets so we can see
> where the resource drain is coming from.
>
> Aidan may be able to help you with XEmacs's use since he implemented
> the JIT Unicode charset stuff, but IIRC he hard-coded it so there's
> probably nothing you can do by customizing a variable---it will need
> code changes.  It's more likely that a workaround can be found in Gnus
> IMO, but since XEmacs is more a platform than an application, IMHO it
> should be reserving private charsets for applications written in Emacs
> Lisp.  So I wouldn't be surprised if the Gnus folks take the position
> that this is an XEmacs 21.5 limitation, and put low priority on
> addressing it.

This problem came up before:
<http://thread.gmane.org/gmane.emacs.gnus.general/68154>.

There you may find a possible solution[1] or a workaround[2] there.  I
don't know why[1] hasn't been implemented.

,----[ http://thread.gmane.org/gmane.emacs.gnus.general/68154/focus=68185 ]
| Gnus should bind `coding-system-for-read' then to the value of
| `mm-binary-coding-system' that defaults to `binary'.  However,
| it seems to have been set to nil or `undecided':
`----

,----[ http://thread.gmane.org/gmane.emacs.gnus.general/68154/focus=68189 ]
| 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.
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Lars Magne Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> There you may find a possible solution[1] or a workaround[2] there.  I
> don't know why[1] hasn't been implemented.
>
> ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/68154/focus=68185 ]
> | Gnus should bind `coding-system-for-read' then to the value of
> | `mm-binary-coding-system' that defaults to `binary'.  However,
> | it seems to have been set to nil or `undecided':
> `----

I don't know why, either.  Katsumi?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen wrote:
> Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> There you may find a possible solution[1] or a workaround[2] there.  I
>> don't know why[1] hasn't been implemented.
>>
>> ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/68154/focus=68185 ]
>>| Gnus should bind `coding-system-for-read' then to the value of
>>| `mm-binary-coding-system' that defaults to `binary'.  However,
>>| it seems to have been set to nil or `undecided':
>> `----

> I don't know why, either.  Katsumi?

I realized what we have to fix is `mml-compute-boundary-1'.  It
may take a couple of days (or shorter?).  I'll work on it.

The function looks for ones that are the same as a MIME boundary
(e.g., =-=-=) in contents of MIME parts, and updates the boundary
pattern so as to be unique, if any.  Contents to be checked should
be encoded ones, however it doesn't so.  As for a file to attach,
it reads the file without binding `coding-system-for-read', doesn't
encode it, and looks for things like the boundary in it.  That is
the root cause of an XEmacs 21.5 error.

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> Lars Magne Ingebrigtsen wrote:
>> Reiner Steib <reinersteib+gmane@imap.cc> writes:

>>> There you may find a possible solution[1] or a workaround[2] there.  I
>>> don't know why[1] hasn't been implemented.
>>>
>>> ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/68154/focus=68185 ]
>>>| Gnus should bind `coding-system-for-read' then to the value of
>>>| `mm-binary-coding-system' that defaults to `binary'.  However,
>>>| it seems to have been set to nil or `undecided':
>>> `----

>> I don't know why, either.  Katsumi?

> I realized what we have to fix is `mml-compute-boundary-1'.  It
> may take a couple of days (or shorter?).  I'll work on it.

> The function looks for ones that are the same as a MIME boundary
> (e.g., =-=-=) in contents of MIME parts, and updates the boundary
> pattern so as to be unique, if any.  Contents to be checked should
> be encoded ones, however it doesn't so.  As for a file to attach,
> it reads the file without binding `coding-system-for-read', doesn't
> encode it, and looks for things like the boundary in it.  That is
> the root cause of an XEmacs 21.5 error.

Done.  Not yet tested with XEmacs 21.5 though.
The new function definition encodes every part in the same way
practicing when actually sending them in advance and then looks
for things like a MIME boundary.  So it may slow message sending.
In addition, it assumes that signing and encrypting will never
generate a boundary pattern in data.

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Reiner Steib]

On Thu, Sep 22 2011, Katsumi Yamaoka wrote:

> Katsumi Yamaoka wrote:
>> I realized what we have to fix is `mml-compute-boundary-1'.  [...]
>> The function looks for ones that are the same as a MIME boundary
>> (e.g., =-=-=) in contents of MIME parts, and updates the boundary
>> pattern so as to be unique, if any.  Contents to be checked should
>> be encoded ones, however it doesn't so.  As for a file to attach,
>> it reads the file without binding `coding-system-for-read', doesn't
>> encode it, and looks for things like the boundary in it.  That is
>> the root cause of an XEmacs 21.5 error.
>
> Done.  Not yet tested with XEmacs 21.5 though.
> The new function definition encodes every part in the same way
> practicing when actually sending them in advance and then looks
> for things like a MIME boundary.  So it may slow message sending.
> In addition, it assumes that signing and encrypting will never
> generate a boundary pattern in data.

Note that Aidan Kehoe added ".pdf" to `binary-file-regexps' in XEmacs
21.5 now[1].  If the slowdown is notable and the change is only
because of the reported XEmacs problem, it is not necessary, I think.
Or does your commit fix a more general problem?

[1] http://thread.gmane.org/gmane.emacs.xemacs.beta/35574

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Katsumi Yamaoka]

Reiner Steib wrote:
> On Thu, Sep 22 2011, Katsumi Yamaoka wrote:

>> Katsumi Yamaoka wrote:
>>> I realized what we have to fix is `mml-compute-boundary-1'.  [...]
>>> The function looks for ones that are the same as a MIME boundary
>>> (e.g., =-=-=) in contents of MIME parts, and updates the boundary
>>> pattern so as to be unique, if any.  Contents to be checked should
>>> be encoded ones, however it doesn't so.  As for a file to attach,
>>> it reads the file without binding `coding-system-for-read', doesn't
>>> encode it, and looks for things like the boundary in it.  That is
>>> the root cause of an XEmacs 21.5 error.
>>
>> Done.  Not yet tested with XEmacs 21.5 though.
>> The new function definition encodes every part in the same way
>> practicing when actually sending them in advance and then looks
>> for things like a MIME boundary.  So it may slow message sending.
>> In addition, it assumes that signing and encrypting will never
>> generate a boundary pattern in data.

> Note that Aidan Kehoe added ".pdf" to `binary-file-regexps' in XEmacs
> 21.5 now[1].

I knew it.  Aidan's change seems generally useful.  But I realized
today, avoiding the error in question is not a solution in this case.
The root cause is that `mml-compute-boundary-1' was mis-designed.

> If the slowdown is notable and the change is only
> because of the reported XEmacs problem, it is not necessary, I think.
> Or does your commit fix a more general problem?

> [1] http://thread.gmane.org/gmane.emacs.xemacs.beta/35574

Yes, it is necessary for not only XEmacs.  If the slowdown is not
disregarded, I think we will possibly be able to make a change so
as to make the mml functions encode a part only once.  Though it
will need major changes on those functions and will take much time.

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Uwe Brauer]

>> Regarding Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22; Katsumi Yamaoka <yamaoka@jpl.org> adds:

   > Done.  Not yet tested with XEmacs 21.5 though.
   > The new function definition encodes every part in the same way
   > practicing when actually sending them in advance and then looks
   > for things like a MIME boundary.  So it may slow message sending.
   > In addition, it assumes that signing and encrypting will never
   > generate a boundary pattern in data.


Hm Aidan already committed a patch to Xemacs which takes care
of the problem. Given that the sending function is already
not very fast, I would recommend not to implement your
solution, but this is just a personal  opinion.

Uwe Brauer  

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Done.

Great; thanks.

> The new function definition encodes every part in the same way
> practicing when actually sending them in advance and then looks
> for things like a MIME boundary.  So it may slow message sending.

But it should be done -- otherwise we can't be sure of successfully
sending these messages, so I think your fix is totally the right thing.

> In addition, it assumes that signing and encrypting will never
> generate a boundary pattern in data.

True.  Hm... is that possible?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Done.

> Great; thanks.

>> The new function definition encodes every part in the same way
>> practicing when actually sending them in advance and then looks
>> for things like a MIME boundary.  So it may slow message sending.

> But it should be done -- otherwise we can't be sure of successfully
> sending these messages, so I think your fix is totally the right thing.

But encoded data made for only computing a boundary can be used
for sending, too.  So, the mml functions for sending may be
rearranged so as to encode all parts of a message first, compute
a boundary, and combine them.  It seems not easy to achieve, though.

>> In addition, it assumes that signing and encrypting will never
>> generate a boundary pattern in data.

> True.  Hm... is that possible?

I'm not quite sure of it.  I was only worried a user who has no
caching mechanism will be bothered by being prompted for
a passphrase twice a part if performing signing or encrypting
for computing a boundary.