From unknown Fri Aug 15 20:02:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Jun 2014 14:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17801 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 17801@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.140310349519008 (code B ref -1); Wed, 18 Jun 2014 14:59:01 +0000 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 X-012-Sender: halo1@inter.net.il 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-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: -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 unknown Fri Aug 15 20:02:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Jun 2014 03:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17801 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 17801@debbugs.gnu.org Received: via spool by 17801-submit@debbugs.gnu.org id=B17801.140315009231315 (code B ref 17801); Thu, 19 Jun 2014 03:55:01 +0000 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 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-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 unknown Fri Aug 15 20:02:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Jun 2014 14:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17801 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 17801@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 17801-submit@debbugs.gnu.org id=B17801.14031897244752 (code B ref 17801); Thu, 19 Jun 2014 14:56:02 +0000 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 In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <834mzht0e5.fsf@gnu.org> References: <83wqcetgd8.fsf@gnu.org> X-Spam-Score: 1.0 (+) 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: 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 unknown Fri Aug 15 20:02:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Jun 2014 15:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17801 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 17801@debbugs.gnu.org Received: via spool by 17801-submit@debbugs.gnu.org id=B17801.14031926819715 (code B ref 17801); Thu, 19 Jun 2014 15:45:02 +0000 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 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-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 unknown Fri Aug 15 20:02:28 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#17801: closed (Re: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup) Message-ID: References: <83bntorme5.fsf@gnu.org> <83wqcetgd8.fsf@gnu.org> X-Gnu-PR-Message: they-closed 17801 X-Gnu-PR-Package: emacs Reply-To: 17801@debbugs.gnu.org Date: Fri, 20 Jun 2014 08:56:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1403254563-26847-1" This is a multi-part message in MIME format... ------------=_1403254563-26847-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 17801@debbugs.gnu.org. --=20 17801: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17801 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1403254563-26847-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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? ------------=_1403254563-26847-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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)) ------------=_1403254563-26847-1-- From unknown Fri Aug 15 20:02:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Jun 2014 13:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17801 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 17801-done@debbugs.gnu.org Received: via spool by 17801-done@debbugs.gnu.org id=D17801.140327041829807 (code D ref 17801); Fri, 20 Jun 2014 13:21:01 +0000 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 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-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