[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 7 Oct 2003 20:24:19 -0500 (CDT)
>From my previous message:
the obvious conclusion of the above statement is that, if this
variable is kept at all, the defcustom for it should be replaced by
On the other hand, from the documentation string:
"*If non-nil, RMAIL uses MIME feature.
If the value is t, RMAIL automatically shows MIME decoded message.
If the value is neither t nor nil, RMAIL does not show MIME decoded message
until a user explicitly requires it."
This makes it seem that this is _really meant_ as a user option.
However setting the variable not only does nothing useful, but
actually causes trouble, as Alexander pointed out. The documentation
string also suggests that (require 'mime), or maybe (require 'MIME),
or maybe something else that the user is just not smart enough to
think about, is supposed to enable mime support and make this variable
"work". Regardless of whether the defcustom gets replaced by a
defvar, _if_ the variable is kept at all, should the documentation
string not contain a warning style:
"*If non-nil, RMAIL uses MIME feature, if available.
This variable only takes effect if you use some add-on package that
knows how to handle it it. The feature MIME will only be defined if
you use such a package. Do not set this variable to a non-nil value
if you are not using such a package, as this might cause trouble.
When using a proper add-on package, if the value is t, RMAIL
automatically shows MIME decoded message. If the value is neither t
nor nil, RMAIL does not show MIME decoded message until a user
explicitly requires it."
The above is not really meant as a _literal_ suggestion, since I do
not really know the situation behind this variable well enough to
properly rewrite the documentation string in full detail.