From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/9630 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.user Subject: Re: Hidden lines in the message body Date: Tue, 11 Sep 2007 10:01:32 +0900 Organization: Emacsen advocacy group Message-ID: References: <87hcm4zxlo.fsf@gmail.com> <878x7eafyr.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189478839 4588 80.91.229.12 (11 Sep 2007 02:47:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 Sep 2007 02:47:19 +0000 (UTC) To: info-gnus-english@gnu.org Original-X-From: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Tue Sep 11 12:47:06 2007 Return-path: Envelope-to: gegu-info-gnus-english@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IV2Ed-000753-5D for gegu-info-gnus-english@m.gmane.org; Tue, 11 Sep 2007 11:40:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUukG-000269-K0 for gegu-info-gnus-english@m.gmane.org; Mon, 10 Sep 2007 21:40:52 -0400 Original-Path: shelby.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.gnus Original-Lines: 47 Original-X-Trace: individual.net 6fGxJFP33Su3qzF0a4HRIAeIUBZsOdirNsFIooD3/RLWjiyLA= Cancel-Lock: sha1:/mieXMUVfQLSBzamPclynScWI7k= sha1:s+USzAUEN2aZ7q2clcbCwwaNToI= X-Face: #kKnN,xUnmKia.'[pp`; Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu; B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux) Original-Xref: shelby.stanford.edu gnu.emacs.gnus:79832 X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Errors-To: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.gnus.user:9630 Archived-At: >>>>> 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,