Re: Couple of useful (?) patches

--pgp-sign-Multipart_Sun_Aug_28_19:43:22_2011-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Tue, 05 Apr 2011 22:20:50 -0400,
Vitaly Mayatskikh wrote:
>=20
> Hi!
>=20
> This is follow up to recent issues claimed by Dave Abrahams on wl-en
> list. Indeed, I agree with him, here're fixes:
>=20
> Next patch is for SEMI. The reason why mime-view-buttons-visible
> defcustom has appeared is that people don't want to see MIME buttons
> for multipart messages. The only need for them is to see
> attachments. So last time I added defcustom and some code around to
> toggle visibility of buttons, and now it's a time to finish it
> logically. This patch allows to display buttons only for parts in
> which we are interested.
>=20
> Now it is part of type "application", but it can be extended. I've
> seen, of course, function mime-view-entity-button-visible-p, which is
> commented out, but I was afraid to reanimate this 10-years old code,
> because I don't understand it. My approach is less smart may be, but
> it works ;)

=46rom my understanding the function `mime-view-entity-button-visible-p'
was used to hide the buttons for MIME entities of type
application/x-selection, and application/octet-stream inside a
multipart/encrypted entity.

The proposed patch is not the right thing to do.  Visibility of MIME
buttons is controlled by `mime-preview-condition',

,----
| (defvar mime-preview-condition nil
|   "Condition-tree about how to display entity.")
`----

which is setup below the defvar with calls to
`ctree-set-calist-strictly'. The suggested approach duplicates code
that is already present. I think a better solution would be to make
the composition of `mime-preview-condition' customizable.

Personally I don't like the whitelist approach (only show...) because
I don't have any control over what people might send me or what
people's mailers decide about MIME media types and subtypes.

> The reason why mime-view-buttons-visible defcustom has appeared is
> that people don't want to see MIME buttons for multipart
> messages. The only need for them is to see attachments.

What about a multipart/mixed like this:

 [1  <multipart/mixed (7bit)>]
 [1.1  <text/plain; US-ASCII (7bit)>]
 [1.2 0001-Provide-edebug-spec-for-with-org-lparse-preserve-par.patch <text=
/plain; US-ASCII (base64)>]
 [2  <application/pgp-signature (7bit)>]

which is enclosed in a multipart/signed MIME entity? You need the MIME
button 1.2 to save the patch to disc.

It makes sense to hide MIME buttons in multipart/alternative where the
children are considered to be alternative representations of each
other (Cf. RFC2046, 5.1.4).

Maybe this could be achived with the help of
`mime-view-type-subtype-score-alist' in
`mime-display-multipart/alternative'? AFAIK the scores are used to
select the desired representation, why not extend it and hide the
buttons of representations that are not selected?

Best,
  -- David
--=20
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... [email protected]
Email..... [email protected]

--pgp-sign-Multipart_Sun_Aug_28_19:43:22_2011-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iF4EABEIAAYFAk5afjoACgkQma24O1pEeObOuQEAtu5Z6a2gb/aarVOO3yB+RwWy
k3pJ2CfK92mLwlBcc6EBAImd/2fGrrEpVnRXjt3kPxGfW502hHwBtWMcBX58Kths
=wKzK
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Sun_Aug_28_19:43:22_2011-1--