bug#3788: 23.0.95; nxml-mode: close-start-tag-block == close-start-tag-inline

bug#3788: 23.0.95; nxml-mode: close-start-tag-block == close-start-tag-inline

[Rommerskirchen, Heinrich (NSN - DE/Munich)]

nxml-balanced-close-start-tag-block doesn't work as advertised. It
doesn't
insert a line break, even if the start-tag is on a line by its own.
Instead it
behaves like nxml-balanced-close-start-tag-inline.

To recreate it:
start emacs with '-Q'
open (C-x C-f) non existing file tmp.xml
enter 'M-x nxml-mode'
type '<a'
enter C-c C-b
Now the buffer contains one line '<a></a>' with the cursor between the
two tags.

In emacs 22.3 with nxml-mode-20041004, the same recipe
(plus '(load-library "rng-auto.el")' before calling nxml-mode) gives the
expected three lines (start tag, empty line, end tag) with the cursor at
the
correct place, i.e. at the empty line.


In GNU Emacs 23.0.95.1 (i386-mingw-nt5.1.2600)
 of 2009-06-20 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: DEU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

bug#3788: 23.0.95; nxml-mode: close-start-tag-block == close-start-tag-inline

[Jeff Trull]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

In Emacs 25, I do not observe the reported behavior.  Following the
reproduction instructions gives me the "correct" behavior reported to be
present in Emacs 22.3.  I suspect that this regression has been repaired in
the meantime.

Best Regards,
Jeff

[-- Attachment #2: Type: text/html, Size: 334 bytes --]

bug#3788: 23.0.95; nxml-mode: close-start-tag-block == close-start-tag-inline

[Andrew Hyatt]

I also can't reproduce this in Emacs 25.  Since this hasn't been replied
to in a few weeks, I will close this out.

Jeff Trull <edaskel@att.net> writes:

> In Emacs 25, I do not observe the reported behavior. Following the reproduction instructions gives me the "correct" behavior reported to be present in Emacs 22.3. I suspect that this regression has been repaired in the meantime.
>
> Best Regards,
> Jeff