bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup

bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup

[Eli Zaretskii]

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

bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup

[Stefan Monnier]

> 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

bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup

[Eli Zaretskii]

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

bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup

[Stefan Monnier]

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

bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup

[Eli Zaretskii]

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

bug#17801: 24.3.91; Regression: Texinfo Mode inserts newline after markup

[Stefan Monnier]

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