* Problems with inlining images in Emacs 20
@ 2001-07-26 19:23 Barry Fishman
2001-07-26 21:54 ` ShengHuo ZHU
0 siblings, 1 reply; 3+ messages in thread
From: Barry Fishman @ 2001-07-26 19:23 UTC (permalink / raw)
I'm not an expert at gnus mime processing but:
Concerning mm-decode.el:
It seems wrong to put the image file wildcard "image/.*" as a part of
mm-inlined-types. This seems to mean that any image type not caught
by the mm-inline-media-tests will be just placed inline. Shouldn't
one assume that if an image is not of a known type, the Emacs 21's
will probably not know what to do with it, and if they did, at least
the mm-valid-and-fit-image-p test should be made.
In Emacs 20, inlined images do not look very pretty, and since they
are inlined there isn't even a button to save them to a file or even
get rid of them. This is a real pain.
Concerning gnus-art.el:
In gnus-display-mime, The mm-dissect-buffer test is always done in its
strict mode. There seems to be messages that get correctly dissected
with the strict option off, but using
(or (mm-dissect-buffer) (mm-uu-dissect) (mm-dissect-buffer t))
about line 3776 seems to cause emacs to break (although not to crash).
Is this why strict mime processing is not a customization option?
I have been working on a `gnus-force-mime' which can be called
interactively, when you are seeing a message which is obviously
intended to be mime, but is missing something like a mime version
header. It would be available like "C-u g" which in a sense does the
opposite in shutting off all processing. Does this seem reasonable?
Is something like this already done?
In general:
I don't like encouraging the use of invalidly formatted mime messages,
by just having mail/news readers accept them without comment.
However, I can't just ignore mail that is incorrectly formatted, and
disassembling them by hand is a real pain.
Barry Fishman
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problems with inlining images in Emacs 20
2001-07-26 19:23 Problems with inlining images in Emacs 20 Barry Fishman
@ 2001-07-26 21:54 ` ShengHuo ZHU
2001-07-27 0:49 ` Barry Fishman
0 siblings, 1 reply; 3+ messages in thread
From: ShengHuo ZHU @ 2001-07-26 21:54 UTC (permalink / raw)
Barry Fishman <barry_fishman@acm.org> writes:
> I'm not an expert at gnus mime processing but:
>
> Concerning mm-decode.el:
>
> It seems wrong to put the image file wildcard "image/.*" as a part of
> mm-inlined-types. This seems to mean that any image type not caught
> by the mm-inline-media-tests will be just placed inline. Shouldn't
> one assume that if an image is not of a known type, the Emacs 21's
> will probably not know what to do with it, and if they did, at least
> the mm-valid-and-fit-image-p test should be made.
Emm. I think the recent change of "Default to displaying as text"
causes the problem. I've fixed it.
> In Emacs 20, inlined images do not look very pretty, and since they
> are inlined there isn't even a button to save them to a file or even
> get rid of them. This is a real pain.
> Concerning gnus-art.el:
>
> In gnus-display-mime, The mm-dissect-buffer test is always done in its
> strict mode. There seems to be messages that get correctly dissected
> with the strict option off, but using
>
> (or (mm-dissect-buffer) (mm-uu-dissect) (mm-dissect-buffer t))
>
> about line 3776 seems to cause emacs to break (although not to crash).
> Is this why strict mime processing is not a customization option?
I don't think so. Forcing to dissect a non-strict mime message may
causes some unexpected troubles.
> I have been working on a `gnus-force-mime' which can be called
> interactively, when you are seeing a message which is obviously
> intended to be mime, but is missing something like a mime version
> header. It would be available like "C-u g" which in a sense does the
> opposite in shutting off all processing. Does this seem reasonable?
> Is something like this already done?
`K m' repairs it.
> In general:
>
> I don't like encouraging the use of invalidly formatted mime messages,
> by just having mail/news readers accept them without comment.
> However, I can't just ignore mail that is incorrectly formatted, and
> disassembling them by hand is a real pain.
`K m', `W 6', `W q' and `W h' are designed for this purpose.
ShengHuo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problems with inlining images in Emacs 20
2001-07-26 21:54 ` ShengHuo ZHU
@ 2001-07-27 0:49 ` Barry Fishman
0 siblings, 0 replies; 3+ messages in thread
From: Barry Fishman @ 2001-07-27 0:49 UTC (permalink / raw)
ShengHuo ZHU <zsh@cs.rochester.edu> writes:
>
> Barry Fishman <barry_fishman@acm.org> writes:
>> Concerning mm-decode.el:
> Emm. I think the recent change of "Default to displaying as text"
> causes the problem. I've fixed it.
Now all my problem messages work fine, unexpectedly without a 'K m'.
Thanks.
>> In general:
>>
>> I don't like encouraging the use of invalidly formatted mime messages,
>> by just having mail/news readers accept them without comment.
>> ...
> `K m', `W 6', `W q' and `W h' are designed for this purpose.
As usually your n steps in front of me. Everything was in the
documentation (and reference card). (So I can add 'K b'). Can I
complain that there are so many feature that I don't expect, I just
forget to look for them? :-) I need to read through the manual again.
It seems to take continual reading since many parts don't make sense
until you start using the feature.
Thanks Again
Barry
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-07-27 0:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-26 19:23 Problems with inlining images in Emacs 20 Barry Fishman
2001-07-26 21:54 ` ShengHuo ZHU
2001-07-27 0:49 ` Barry Fishman
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).