From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 18 10:58:15 2014 Received: (at submit) by debbugs.gnu.org; 18 Jun 2014 14:58:15 +0000 Received: from localhost ([127.0.0.1]:51884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxHJW-0004wW-6n for submit@debbugs.gnu.org; Wed, 18 Jun 2014 10:58:14 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56945) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxHJU-0004wI-DW for submit@debbugs.gnu.org; Wed, 18 Jun 2014 10:58:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxHJE-0005WY-UU for submit@debbugs.gnu.org; Wed, 18 Jun 2014 10:58:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxHJE-0005WU-RC for submit@debbugs.gnu.org; Wed, 18 Jun 2014 10:57:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxHJ7-0000Wf-3b for bug-gnu-emacs@gnu.org; Wed, 18 Jun 2014 10:57:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxHIz-0005S7-Iq for bug-gnu-emacs@gnu.org; Wed, 18 Jun 2014 10:57:49 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:45975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxHIz-0005Rl-B4 for bug-gnu-emacs@gnu.org; Wed, 18 Jun 2014 10:57:41 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N7D00200D9DVO00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Wed, 18 Jun 2014 17:57:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7D002Z7DK25LA0@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Wed, 18 Jun 2014 17:57:39 +0300 (IDT) Date: Wed, 18 Jun 2014 17:57:39 +0300 From: Eli Zaretskii Subject: 24.3.91; Regression: Texinfo Mode inserts newline after markup X-012-Sender: halo1@inter.net.il To: bug-gnu-emacs@gnu.org Message-id: <83wqcetgd8.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Steps to reproduce: emacs -Q C-x b foo.texi RET M-x texinfo-mode RET Type this into the buffer: If non-nil, this is good. Now put point before "nil" and type "C-u 1 C-c C-c c". This produces: If non-@code{nil} , this is good. IOW, an unwarranted newline was inserted after the closing brace. I understand that this is because this and similar commands now use skeleton.el, which inserts a newline after a skeleton. This is a regression from Emacs 23, which didn't use skeleton.el, and thus avoided this problem. I couldn't find a clear-cut way to fix this. Setting skeleton-end-newline to nil doesn't sound right, as it is a global variable, and not a defcustom; also, some Texinfo commands do benefit from the newline. I also couldn't find any way of telling a skeleton not to insert a newline; did I miss something? Please fix this annoyance before 24.4 is released. In GNU Emacs 24.3.91.59 (i686-pc-mingw32) of 2014-06-18 on HOME-C4E4A596F7 Repository revision: 117253 juri@jurta.org-20140618075727-vxeneaqcl9e30m5e Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-2 -g3'' Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Texinfo Minor modes in effect: tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x b f o o . t e x i M-x n o m r m m o M-x t x e x i n f o - m o I f SPC n o n - n i l , SPC t h i s SPC i s SPC g o o d . C-u 1 C-c C-c c C-SPC M-w M-x r e p o r t - e m Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Mark set End of buffer Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils skeleton texinfo easymenu time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 76060 7541) (symbols 32 17630 0) (miscs 32 40 128) (strings 16 11311 4124) (string-bytes 1 280823) (vectors 8 9633) (vector-slots 4 375107 5060) (floats 8 58 333) (intervals 28 277 130) (buffers 508 12)) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 18 23:54:52 2014 Received: (at 17801) by debbugs.gnu.org; 19 Jun 2014 03:54:52 +0000 Received: from localhost ([127.0.0.1]:52334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxTR5-00088y-0E for submit@debbugs.gnu.org; Wed, 18 Jun 2014 23:54:51 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:4659) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxTR2-00088h-Jo for 17801@debbugs.gnu.org; Wed, 18 Jun 2014 23:54:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJC6HVgjSGReOegeEOASpGYFqg0wh X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJC6HVgjSGReOegeEOASpGYFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="67966515" Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Jun 2014 23:54:42 -0400 Received: by pastel.home (Postfix, from userid 20848) id B028662D00; Wed, 18 Jun 2014 23:54:42 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Message-ID: References: <83wqcetgd8.fsf@gnu.org> Date: Wed, 18 Jun 2014 23:54:42 -0400 In-Reply-To: <83wqcetgd8.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 18 Jun 2014 17:57:39 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 17801 Cc: 17801@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > I couldn't find a clear-cut way to fix this. Setting > skeleton-end-newline to nil doesn't sound right, I think it's the right solution, tho. > I also couldn't find any way of telling a skeleton not to insert a > newline; did I miss something? Indeed, there isn't any. But really skeleton shouldn't insert a newline by default (since it offers no way for individual skeletons to override it). Instead, each skeleton that needs it should end with a \n. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 19 10:55:24 2014 Received: (at 17801) by debbugs.gnu.org; 19 Jun 2014 14:55:24 +0000 Received: from localhost ([127.0.0.1]:53311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxdkK-0001EX-19 for submit@debbugs.gnu.org; Thu, 19 Jun 2014 10:55:24 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:65317) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxdkG-0001EC-SE for 17801@debbugs.gnu.org; Thu, 19 Jun 2014 10:55:22 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N7F00E007T5GL00@a-mtaout21.012.net.il> for 17801@debbugs.gnu.org; Thu, 19 Jun 2014 17:55:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7F00ECS841BV70@a-mtaout21.012.net.il>; Thu, 19 Jun 2014 17:55:13 +0300 (IDT) Date: Thu, 19 Jun 2014 17:54:58 +0300 From: Eli Zaretskii Subject: Re: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <834mzht0e5.fsf@gnu.org> References: <83wqcetgd8.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17801 Cc: 17801@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: 17801@debbugs.gnu.org > Date: Wed, 18 Jun 2014 23:54:42 -0400 > > > I couldn't find a clear-cut way to fix this. Setting > > skeleton-end-newline to nil doesn't sound right, > > I think it's the right solution, tho. > > > I also couldn't find any way of telling a skeleton not to insert a > > newline; did I miss something? > > Indeed, there isn't any. But really skeleton shouldn't insert a newline > by default (since it offers no way for individual skeletons to override > it). Instead, each skeleton that needs it should end with a \n. But this will probably cause massive breakage in users of skeleton. So it might be appropriate for the trunk, but not for the emacs-24 branch. For the branch, is it OK to make skeleton-end-newline buffer-local in Texinfo buffers, and then give it a nil value? From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 19 11:44:41 2014 Received: (at 17801) by debbugs.gnu.org; 19 Jun 2014 15:44:41 +0000 Received: from localhost ([127.0.0.1]:53340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxeVv-0002WY-NU for submit@debbugs.gnu.org; Thu, 19 Jun 2014 11:44:40 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:31242) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxeVo-0002WA-QV for 17801@debbugs.gnu.org; Thu, 19 Jun 2014 11:44:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="68275706" Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 19 Jun 2014 11:44:23 -0400 Received: by pastel.home (Postfix, from userid 20848) id D947360D16; Thu, 19 Jun 2014 11:44:22 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Message-ID: References: <83wqcetgd8.fsf@gnu.org> <834mzht0e5.fsf@gnu.org> Date: Thu, 19 Jun 2014 11:44:22 -0400 In-Reply-To: <834mzht0e5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 19 Jun 2014 17:54:58 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 17801 Cc: 17801@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Indeed, there isn't any. But really skeleton shouldn't insert a newline >> by default (since it offers no way for individual skeletons to override >> it). Instead, each skeleton that needs it should end with a \n. > But this will probably cause massive breakage in users of skeleton. Indeed, that's why I haven't made such a change. > For the branch, is it OK to make skeleton-end-newline buffer-local in > Texinfo buffers, and then give it a nil value? Yes. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 20 04:55:25 2014 Received: (at 17801-done) by debbugs.gnu.org; 20 Jun 2014 08:55:25 +0000 Received: from localhost ([127.0.0.1]:53770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxubU-0006y7-NO for submit@debbugs.gnu.org; Fri, 20 Jun 2014 04:55:25 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:49014) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxubO-0006xk-6S for 17801-done@debbugs.gnu.org; Fri, 20 Jun 2014 04:55:19 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N7G00500M098600@mtaout28.012.net.il> for 17801-done@debbugs.gnu.org; Fri, 20 Jun 2014 11:53:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7G000JIM1IKB40@mtaout28.012.net.il>; Fri, 20 Jun 2014 11:53:42 +0300 (IDT) Date: Fri, 20 Jun 2014 11:54:58 +0300 From: Eli Zaretskii Subject: Re: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83bntorme5.fsf@gnu.org> References: <83wqcetgd8.fsf@gnu.org> <834mzht0e5.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17801-done Cc: 17801-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: 17801@debbugs.gnu.org > Date: Thu, 19 Jun 2014 11:44:22 -0400 > > >> Indeed, there isn't any. But really skeleton shouldn't insert a newline > >> by default (since it offers no way for individual skeletons to override > >> it). Instead, each skeleton that needs it should end with a \n. > > But this will probably cause massive breakage in users of skeleton. > > Indeed, that's why I haven't made such a change. Should we make such a change on the trunk at this time? > > For the branch, is it OK to make skeleton-end-newline buffer-local in > > Texinfo buffers, and then give it a nil value? > > Yes. Done as r117265 on the emacs-24 branch. Btw, while working on this, I bumped into some strange feature: the last \n element in a skeleton is only obeyed when it would be inserted not at end of line. This is explicitly coded in skeleton.el: ;; \n as last element only inserts \n if not at eol. ((and (null (cdr skeleton-il)) (not recursive) (eolp)) For this reason, if a skeleton wants to always insert a newline at the end, it quite embarrassingly must end with 2 \n elements, and risk inserting an extra newline in some cases. Is this a feature or a bug? If a feature, does the code assume that skeleton-end-newline is non-nil? That is, should the condition above also test skeleton-end-newline? From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 20 09:20:18 2014 Received: (at 17801-done) by debbugs.gnu.org; 20 Jun 2014 13:20:18 +0000 Received: from localhost ([127.0.0.1]:53877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxyjk-0007ka-RT for submit@debbugs.gnu.org; Fri, 20 Jun 2014 09:20:17 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:5254) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxyjd-0007jv-7D for 17801-done@debbugs.gnu.org; Fri, 20 Jun 2014 09:20:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="68726062" Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Jun 2014 09:19:59 -0400 Received: by pastel.home (Postfix, from userid 20848) id 61EBE60D09; Fri, 20 Jun 2014 09:19:59 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Message-ID: References: <83wqcetgd8.fsf@gnu.org> <834mzht0e5.fsf@gnu.org> <83bntorme5.fsf@gnu.org> Date: Fri, 20 Jun 2014 09:19:59 -0400 In-Reply-To: <83bntorme5.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 20 Jun 2014 11:54:58 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 17801-done Cc: 17801-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Indeed, that's why I haven't made such a change. > Should we make such a change on the trunk at this time? We could try, yes. I bumped into this problem many years ago and didn't dare to make such a change back then (instead, I added the skeleton-end-newline variable, so that at least you can get rid of these newlines without having to remove a lambda expression from a hook). > Btw, while working on this, I bumped into some strange feature: the > last \n element in a skeleton is only obeyed when it would be inserted > not at end of line. This is explicitly coded in skeleton.el: > ;; \n as last element only inserts \n if not at eol. > ((and (null (cdr skeleton-il)) (not recursive) (eolp)) Right, this is specifically so you can write skeletons which do the same regardless of skeleton-end-newline. I.e. so that after changing the default of skeleton-end-newline, you can tell people they can fix their skeletons by simply adding a final \n rather than having to test Emacs version or the value of skeleton-end-newline. > For this reason, if a skeleton wants to always insert a newline at the > end, it quite embarrassingly must end with 2 \n elements, and risk > inserting an extra newline in some cases. Right, but this need is very rare in my experience. You can always use some other element, like "\n" instead. Stefan From unknown Sat Aug 16 18:44:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 19 Jul 2014 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator