GNU bug report logs - #17801
24.3.91; Regression: Texinfo Mode inserts newline after markup

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17801 in the body.
You can then email your comments to 17801 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.91; Regression: Texinfo Mode inserts newline after markup
Date: Wed, 18 Jun 2014 17:57:39 +0300

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 <at> 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 <return> M-x n o m <tab> <backspace> 
r m <tab> m o <tab> <return> M-x t x <backspace> e 
x i n f o - m o <tab> <return> I f SPC n o n - n i 
l , SPC t h i s SPC i s SPC g o o d . <C-left> <C-left> 
<C-left> <C-left> C-u 1 C-c C-c c <up> C-SPC <down> 
<down> M-w M-x r e p o r t - e m <tab> <return>

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

Message #8 received at 17801 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17801 <at> debbugs.gnu.org
Subject: Re: bug#17801: 24.3.91;
 Regression: Texinfo Mode inserts newline after markup
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.


        Stefan

Message #11 received at 17801 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17801 <at> debbugs.gnu.org
Subject: Re: bug#17801: 24.3.91;
 Regression: Texinfo Mode inserts newline after markup
Date: Thu, 19 Jun 2014 17:54:58 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 17801 <at> 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?

Message #14 received at 17801 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17801 <at> debbugs.gnu.org
Subject: Re: bug#17801: 24.3.91;
 Regression: Texinfo Mode inserts newline after markup
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.

> 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

Message #19 received at 17801-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17801-done <at> debbugs.gnu.org
Subject: Re: bug#17801: 24.3.91;
 Regression: Texinfo Mode inserts newline after markup
Date: Fri, 20 Jun 2014 11:54:58 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 17801 <at> 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?

Message #22 received at 17801-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17801-done <at> debbugs.gnu.org
Subject: Re: bug#17801: 24.3.91;
 Regression: Texinfo Mode inserts newline after markup
Date: Fri, 20 Jun 2014 09:19:59 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.