From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/28514 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: [=?iso-8859-1?q?Fran=E7ois?= Pinard ] pgnus 0.84 - White lines and MML parts Date: 02 Jan 2000 12:40:56 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1035165348 30259 80.91.224.250 (21 Oct 2002 01:55:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:55:48 +0000 (UTC) Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id 1E42AD051E for ; Sun, 2 Jan 2000 06:50:42 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id FAB04472; Sun, 2 Jan 2000 05:47:08 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 02 Jan 2000 05:45:49 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id FAA26655 for ; Sun, 2 Jan 2000 05:45:38 -0600 (CST) Original-Received: from quimbies.gnus.org (quimbies.gnus.org [193.69.4.148]) by mailhost.sclp.com (Postfix) with ESMTP id 20273D051E for ; Sun, 2 Jan 2000 06:44:02 -0500 (EST) Original-Received: (from larsi@localhost) by quimbies.gnus.org (8.8.7/8.8.7) id MAA20368; Sun, 2 Jan 2000 12:45:01 +0100 X-Authentication-Warning: quimbies.gnus.org: larsi set sender to lmi@gnus.org using -f X-Now-Playing: Brokeback's _Field Recordings From The Cook County Water Table_: "Seiche 2" Original-To: ding@gnus.org User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.2 (Sumida) X-Face: &w!^oO~dS|}-P0~ge{$c!h\ Subject: pgnus 0.84 - White lines and MML parts X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYk= a_.LV?Qq `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<= Ok5/cC^=3D CxDhg=3DTJi^o[E From: Fran=E7ois Pinard Date: 07 May 1999 11:37:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=3Diso-8859-1 Content-Transfer-Encoding: 8bit Hi, Lars. Here is a suggestion to get rid of those spurious white line= s that are often tied up with the usage of MML parts. In fact, the idea is no= t new. If someone writes: [text] [inside] as readability invites to, there is one end of line between [text] and = the MML start tag already, but surely another after the `>' and the [inside= ]. Another new line is also implied after the MML end tag. That might exp= lain those three white lines between parts we too often observe! :-) The idea would to specify that an MML start part tag may only be recogn= ized when alone on its line, that is, the `<' should not preceded by non-whi= te characters, and the '>' should not be followed by non-white characters. Preceding whitespace could be used to indent MML directives at will acc= ording to the part nesting (and Gnus should generate the edit buffer with inde= nted MML), it should be ignored when reading MML back in. Following whitesp= ace would be ignored while reading MML back in. Of course, between `<' and '>', white space and new lines could still be used at will for readabil= ity. The main point is that the end of line after the MML directive should be swallowed and ignored. Right now, I'm being forced into writing things like: [text] [inside] which is too cluttered to my taste, because I would like to see a white= line while writing MML, where there would be a white line in the rendered me= ssage. Another current possibility is writing: [text] [inside] which is not very nice when [inside] is many lines, as the first of the lines is forced into some awkward indentation in the editing buffer, making it unnatural. I have experienced this many times by now. If the end of line following the MML tag was plainly swallowed as part of the = tag, it would allow more nicer writing of MML, in my opinion. A debatable choice to make is to swallow, or not, the end of line which precedes the tag. My opinion is that it has to be, if we want MML to a= lways stand alone on its line and be nicely indentable. That would make two = white lines in the editing buffer when one is meant in the rendering, which is not very elegant. Or else, if that preceding end of line is not swallo= wed, then it might be best then to forget the idea of indenting MML, and just consider whitespace which precedes `<' as fully significant, like it is= now. But swallowing the end of line following '>' does not look that debatab= le to me, as I see it as necessary for editing to be nice, while avoiding spurious white lines at later rendering time. Once consequence of my suggestion is that embedded in a paragr= aph, not being recognizable as MML, might not require `!' quoting. It would then be a bit easier to speak about MML in running text. The only case requiring quoting would be while giving whole line as examples. Once a= gain, this choice is somewhat tied to swallowing preceding end of lines or no= t. --=20 Fran=E7ois Pinard http://www.iro.umontreal.ca/~pinard --=-=-= -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen --=-=-=--