Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
From: Katsumi Yamaoka <yamaoka@jpl.org>
To: info-gnus-english@gnu.org
Subject: Re: Hidden lines in the message body
Date: Tue, 11 Sep 2007 10:01:32 +0900	[thread overview]
Message-ID: <b4mk5qyuiab.fsf@jpl.org> (raw)
In-Reply-To: <878x7eafyr.fsf@gmail.com>

>>>>> Rodolfo Medina wrote:

> Thanks.
> The problem seems to be solved since I put in .gnus.el the line:

>  (setq gnus-article-emulate-mime nil)

Well, this may cause you inconvenience, especially when exchanging
messages with Gnus users.  Because Gnus users may expect others
who use Gnus not change such an option.  I'm not an exception.
I think the second one (i.e., using `mm-uu-configure-list') is
better for you.  Otherwise, to use another pattern that does not
conflict with Gnus' default is much better if it is possible.
For instance:

--- --- --- --- --- --- --- --%<-- --- --- --- --- --- --- ---

You can verify how your message will be seen by Gnus users before
sending, by typing the `C-c C-m P' command in the message buffer.

>> --8<---------------cut here---------------start------------->8---
>> (setq gnus-article-emulate-mime nil)
>> --8<---------------cut here---------------end--------------->8---
>> or
>> --8<---------------cut here---------------start------------->8---
>> (eval-after-load "mm-uu"
>>   '(add-to-list 'mm-uu-configure-list
>> 		'(insert-marks . disabled)))
>> --8<---------------cut here---------------end--------------->8---

> 1) Is that what you meant? (I don't well understand the meaning of the lines
>    where it says `cut here', `start', `end'.)

I ran the `C-c M-m' command (in the message buffer) on those two
Lisp snippets to surround them with `-cut here-' lines.  Those
lines will not appear in the Gnus article buffer if
`gnus-article-emulate-mime' is non-nil.  Moreover the Lisp codes
will be highlighted with the `mm-uu-extract' face.  This is what
I intended, however I forgot that you might disable this feature.

> 2) Won't there be any unwished side effects with other messages (e.g.,
>    including attachments)?

I believe this feature never breaks attachments that senders put
on purpose.

Regards,

      parent reply	other threads:[~2007-09-11  1:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-08 20:54 Rodolfo Medina
2007-09-10  0:51 ` Katsumi Yamaoka
2007-09-10 11:59   ` Rodolfo Medina
2007-09-10 17:10     ` Daniel C. Bastos
2007-09-11  1:01     ` Katsumi Yamaoka [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=b4mk5qyuiab.fsf@jpl.org \
    --to=yamaoka@jpl.org \
    --cc=info-gnus-english@gnu.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).