Gnus development mailing list
 help / color / mirror / Atom feed
* [François Pinard <pinard@iro.umontreal.ca>] pgnus 0.84 - White lines and MML parts
@ 2000-01-02 11:40 Lars Magne Ingebrigtsen
  0 siblings, 0 replies; only message in thread
From: Lars Magne Ingebrigtsen @ 2000-01-02 11:40 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 38 bytes --]

This is a very good point.  Anybody?


[-- Attachment #2: Type: message/rfc822, Size: 3610 bytes --]

To: Lars Magne Ingebrigtsen <larsi@gnus.org>
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~xhYka_.LV?Qq
 `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m<Ok5/cC^=
 CxDhg=TJi^o[E
From: François Pinard <pinard@iro.umontreal.ca>
Date: 07 May 1999 11:37:19 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi, Lars.  Here is a suggestion to get rid of those spurious white lines that
are often tied up with the usage of MML parts.  In fact, the idea is not new.

If someone writes:

        [text]

        <!#part ...>
        [inside]
        <!/#part>

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 explain
those three white lines between parts we too often observe! :-)

The idea would to specify that an MML start part tag may only be recognized
when alone on its line, that is, the `<' should not preceded by non-white
characters, and the '>' should not be followed by non-white characters.
Preceding whitespace could be used to indent MML directives at will according
to the part nesting (and Gnus should generate the edit buffer with indented
MML), it should be ignored when reading MML back in.  Following whitespace
would be ignored while reading MML back in.  Of course, between `<' and
'>', white space and new lines could still be used at will for readability.
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]
        <!#part ...>
        [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 message.
Another current possibility is writing:

        [text]

        <!#part ...>[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 always
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 swallowed,
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 debatable
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 <!#part> embedded in a paragraph,
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 again,
this choice is somewhat tied to swallowing preceding end of lines or not.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard



From: Fran=E7ois Pinard <pinard@iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Subject: pgnus 0.84 - White lines and MML parts
Date: 07 May 1999 11:37:19 -0400


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1: Type: text/plain; charset=3Diso-8859-1, Size: 3133 bytes --]

From: Fran=E7ois Pinard <pinard@iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Subject: pgnus 0.84 - White lines and MML parts
Date: 07 May 1999 11:37:19 -0400

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]

        <!#part ...>
        [inside]
        <!/#part>

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]
        <!#part ...>
        [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]

        <!#part ...>[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 <!#part> 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



[-- Attachment #3: Type: text/plain, Size: 104 bytes --]


-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2000-01-02 11:40 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-02 11:40 [François Pinard <pinard@iro.umontreal.ca>] pgnus 0.84 - White lines and MML parts Lars Magne Ingebrigtsen

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).