From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/37525 Path: main.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.gnus.general Subject: Re: "> > >" space removal removes too many spaces? Date: Sun, 05 Aug 2001 16:47:36 +0200 Message-ID: <87g0b64l87.fsf@deneb.enyo.de> References: <878zgy62mg.fsf@deneb.enyo.de> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1035172925 14353 80.91.224.250 (21 Oct 2002 04:02:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:02:05 +0000 (UTC) Return-Path: Return-Path: Original-Received: (qmail 22340 invoked from network); 5 Aug 2001 14:29:34 -0000 Original-Received: from mail.s.netic.de (HELO mail.netic.de) (212.9.160.11) by gnus.org with SMTP; 5 Aug 2001 14:29:34 -0000 Original-Received: by mail.netic.de (Smail3.2.0.111/mail.s.netic.de) via LF.net GmbH Internet Services via remoteip 212.9.163.40 via remotehost mail.enyo.de with esmtp for mail.gnus.org id m15TOuK-001WzyC; Sun, 5 Aug 2001 16:29:32 +0200 (CEST) Original-Received: from [192.168.1.2] (helo=deneb.enyo.de ident=exim) by mail.enyo.de with esmtp (Exim 3.12 #1) id 15TOtV-0006iV-00 for ding@gnus.org; Sun, 05 Aug 2001 16:28:41 +0200 Original-Received: from fw by deneb.enyo.de with local (Exim 3.12 #1) id 15TPBo-0000e4-00 for ding@gnus.org; Sun, 05 Aug 2001 16:47:36 +0200 Original-To: ding@gnus.org In-Reply-To: (Simon Josefsson's message of "Sun, 05 Aug 2001 15:57:40 +0200") User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 Original-Lines: 83 Xref: main.gmane.org gmane.emacs.gnus.general:37525 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:37525 --=-=-= Simon Josefsson 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. --=-=-= Content-Type: text/diff 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) --=-=-= > 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. --=-=-=--