GNU bug report logs - #37521
26.3; breakage for <x> a > 'b </x> in nxml-mode

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 37521 in the body.
You can then email your comments to 37521 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: Allin Cottrell <cottrell <at> wfu.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: breakage in emacs 26.3 + nxml
Date: Thu, 26 Sep 2019 08:38:20 -0400 (EDT)

There's a broken interaction between unescaped '>' (ASCII 62) and
apostrophe (ASCII 39) when editing an XML file in nxml mode in emacs
26.3. (Version 26.2 was OK.)

At the first apostrophe following an unescaped '>', the font color
switches to "within delimiters" mode, and, depending on the context,
certain nxml editing commands stop working properly.

Here are two little examples. The first just shows the unwanted change
in face:

<?xml version="1.0"?>

<p>Here's some text, including the inequality 3 > 2. And here's
what happens in following text once an apostrophe comes along.
</p>

The second example shows what happens when the apostrophe is inside a
tag. If you delete the trailing "</p>" below, then try to insert it
again via the shortcut C-c C-f, it's "</tt>" that gets inserted
instead:

<?xml version="1.0"?>

<p>Here's some text, including the inequality 3 > 2. And here is an
apostrophe inside a tag: <tt>'</tt>. Plus some following text and
so on.</p>

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

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

From: Rolf Ade <rolf <at> pointsman.de>
To: Allin Cottrell <cottrell <at> wfu.edu>
Cc: 37521 <at> debbugs.gnu.org
Subject: Re: bug#37521: breakage in emacs 26.3 + nxml
Date: Fri, 27 Sep 2019 02:03:27 +0200

Allin Cottrell <cottrell <at> wfu.edu> writes:
> There's a broken interaction between unescaped '>' (ASCII 62) and
> apostrophe (ASCII 39) when editing an XML file in nxml mode in emacs
> 26.3. (Version 26.2 was OK.)
>
> At the first apostrophe following an unescaped '>', the font color
> switches to "within delimiters" mode, and, depending on the context,
> certain nxml editing commands stop working properly.
>
> Here are two little examples. The first just shows the unwanted change
> in face:
>
> <?xml version="1.0"?>
>
> <p>Here's some text, including the inequality 3 > 2. And here's
> what happens in following text once an apostrophe comes along.
> </p>
>
> The second example shows what happens when the apostrophe is inside a
> tag. If you delete the trailing "</p>" below, then try to insert it
> again via the shortcut C-c C-f, it's "</tt>" that gets inserted
> instead:
>
> <?xml version="1.0"?>
>
> <p>Here's some text, including the inequality 3 > 2. And here is an
> apostrophe inside a tag: <tt>'</tt>. Plus some following text and
> so on.</p>

Current master

commit fd6f4bf648c5a4417eb591a8c54b87c7c60de154
Author: Nikolaus Rath <Nikolaus <at> rath.org>
Date:   Fri Sep 27 01:39:13 2019 +0200

works like 26.2 (that is: correct).

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

From: Rolf Ade <rolf <at> pointsman.de>
To: Allin Cottrell <cottrell <at> wfu.edu>
Cc: 37521 <at> debbugs.gnu.org
Subject: Re: bug#37521: breakage in emacs 26.3 + nxml
Date: Fri, 27 Sep 2019 02:26:44 +0200

Allin Cottrell <cottrell <at> wfu.edu> writes:

> There's a broken interaction between unescaped '>' (ASCII 62) and
> apostrophe (ASCII 39) when editing an XML file in nxml mode in emacs
> 26.3. (Version 26.2 was OK.)
>
> At the first apostrophe following an unescaped '>', the font color
> switches to "within delimiters" mode, and, depending on the context,
> certain nxml editing commands stop working properly.
>
> Here are two little examples. The first just shows the unwanted change
> in face:
>
> <?xml version="1.0"?>
>
> <p>Here's some text, including the inequality 3 > 2. And here's
> what happens in following text once an apostrophe comes along.
> </p>
>
> The second example shows what happens when the apostrophe is inside a
> tag. If you delete the trailing "</p>" below, then try to insert it
> again via the shortcut C-c C-f, it's "</tt>" that gets inserted
> instead:
>
> <?xml version="1.0"?>
>
> <p>Here's some text, including the inequality 3 > 2. And here is an
> apostrophe inside a tag: <tt>'</tt>. Plus some following text and
> so on.</p>

But in fact on current emacs-26 (as of commit
bd0f173199c112b2b146e727f80e973e7fc12143)

there is the by Allin described (wrong) behaviour.

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

From: Rolf Ade <rolf <at> pointsman.de>
To: Allin Cottrell <cottrell <at> wfu.edu>
Cc: 37521 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#37521: breakage in emacs 26.3 + nxml
Date: Fri, 27 Sep 2019 13:22:20 +0200

[Added Noam to CC because it seems a commit by him introduced this.]

Rolf Ade <rolf <at> pointsman.de> writes:
> Allin Cottrell <cottrell <at> wfu.edu> writes:
>
>> There's a broken interaction between unescaped '>' (ASCII 62) and
>> apostrophe (ASCII 39) when editing an XML file in nxml mode in emacs
>> 26.3. (Version 26.2 was OK.)
>>
>> At the first apostrophe following an unescaped '>', the font color
>> switches to "within delimiters" mode, and, depending on the context,
>> certain nxml editing commands stop working properly.
>>
>> Here are two little examples. The first just shows the unwanted change
>> in face:
>>
>> <?xml version="1.0"?>
>>
>> <p>Here's some text, including the inequality 3 > 2. And here's
>> what happens in following text once an apostrophe comes along.
>> </p>
>>
>> The second example shows what happens when the apostrophe is inside a
>> tag. If you delete the trailing "</p>" below, then try to insert it
>> again via the shortcut C-c C-f, it's "</tt>" that gets inserted
>> instead:
>>
>> <?xml version="1.0"?>
>>
>> <p>Here's some text, including the inequality 3 > 2. And here is an
>> apostrophe inside a tag: <tt>'</tt>. Plus some following text and
>> so on.</p>
>
> But in fact on current emacs-26 (as of commit
> bd0f173199c112b2b146e727f80e973e7fc12143)
>
> there is the by Allin described (wrong) behaviour.

To be more precise, since

commit 7dab3ee7ab54b3c2e7bc24170376054786c01d6f
Author: Noam Postavsky <npostavs <at> gmail.com>
Date:   Sun Apr 21 22:44:50 2019 -0400

the behaviour is as reported in the bug report.

With state of the previous

commit e4cde42657f8f91f795e6b7041dc50b896dc468d
Author: Noam Postavsky <npostavs <at> gmail.com>
Date:   Fri Apr 19 13:28:00 2019 -0400

the behaviour is like 26.2 and, as alredy reported, on master (and
correct).

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Rolf Ade <rolf <at> pointsman.de>
Cc: 37521 <at> debbugs.gnu.org, Allin Cottrell <cottrell <at> wfu.edu>
Subject: Re: bug#37521: breakage in emacs 26.3 + nxml
Date: Wed, 02 Oct 2019 19:40:48 -0400

retitle 37521 26.3; breakage for <x> a > 'b </x> in nxml-mode
found 37521 26.3
tags 37521 + confirmed fixed
close 37521 27.1
quit

Rolf Ade <rolf <at> pointsman.de> writes:
>
> the behaviour is like 26.2 and, as alredy reported, on master (and
> correct).

Yes, it was one of the cases brought up in Bug#33887.  For the 26.3
release, we were juggling several bugs, fixes, and fixes which caused
bugs.  This case ended up broken.  We're not planning any more 26.x
releases, so I don't think there is anything more to do about this bug
now.

https://debbugs.gnu.org/33887#76

Previous Next

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