Re: "> > >" space removal removes too many spaces?

[Florian Weimer <fw@deneb.enyo.de>]

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

Simon Josefsson <jas@extundo.com> writes:

>> '>' may appear at the beginning of a line accidently, and we certainly
>> want to supply the space character in this case.
> 
> First, wouldn't it be very complicated to solve your case?

No, I don't think so.  I think it helps to consider a leading '>' to
be a quote character only if the preceding line is empty (or consists
entirely of whitespace), or if it starts in turn with a '>'.

I've just implemented this logic (at least I think so).  The diff is a
bit more complicated then it needs to be, but if you don't like this
implementation, I'm going to add some backtracking code which should
do somewhat better.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 1552 bytes --]

Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.108
diff -u -r6.108 message.el
--- message.el	2001/07/28 16:43:18	6.108
+++ message.el	2001/08/05 14:26:26
@@ -2100,11 +2100,31 @@
 	(indent-rigidly start (mark t) message-indentation-spaces)
       (save-excursion
 	(goto-char start)
-	(while (< (point) (mark t))
-	  (if (looking-at message-cite-prefix-regexp)
-	      (insert message-yank-cited-prefix)
-	    (insert message-yank-prefix))
-	  (forward-line 1))))
+	(let (last-line)
+	  ;; `last-line' describes the contents of the last line
+	  ;; encountered in the loop below. nil means "empty line",
+	  ;; spaces "line consisting entirely of whitespace",
+	  ;; right-angle "line starts with >", quoted "quote character
+	  ;; at the beginning of the line", text "the remaining cases".
+	  (while (< (point) (mark t))
+	    (cond
+	     ((eolp) 
+	      (insert message-yank-prefix)
+	      (setq last-line nil))
+	     ((looking-at ">")
+	      (if (memq last-line '(nil spaces right-angle quoted))
+		  (progn
+		    (insert message-yank-cited-prefix)
+		    (setq last-line 'quoted))
+		(insert message-yank-prefix)
+		(setq last-line 'right-angle)))
+	     ((looking-at "\\s-+$")
+	      (insert message-yank-prefix)
+	      (setq last-line 'spaces))
+	     (t
+	      (insert message-yank-prefix)
+	      (setq last-line 'text)))
+	    (forward-line 1)))))
     (goto-char start)))
 
 (defun message-yank-original (&optional arg)

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


> I don't see how you programatically can easily separate your case
> from e.g.
> 
>> According to your analysis
>>>42 is a nice number
>> you indicate that 42 is a nice number.
> 
> but suggestions are welcome. :)

Not leaving blank lines before and after quotes is not my preferred
style of writing messages. ;-)

> Secondly, RFC 2646 compliant MUAs should never generate this case in
> the first place.  Even if you don't generate RFC 2646 (Gnus doesn't)
> you could QP encode the character to prevent the ambiguity.

Does RFC 2646 really try to solve the problem this way?  In this
case, the RFC is horribly broken.  Attaching semantic to QP encoding
vs. not-encoding is clearly an extremely bad idea, and it certainly
contradicts the spirit of MIME.