xml.el produces incorrect sexp for empty element.

xml.el produces incorrect sexp for empty element.

[Mark A. Hershberger]

Previous patches that I sent on this weren't accepted, I assume,
because they didn't apply cleanly.  I fixed my CVS, so this should
work.

2003-05-30  Mark A. Hershberger  <mah@everybody.org>

	* xml.el (xml-parse-tag): Fixed incorrect handling of empty elements.

*** xml.el.~1.18.~	Thu Mar 20 12:01:04 2003
--- xml.el	Fri May 16 21:24:11 2003
***************
*** 222,228 ****
        (if (looking-at "/[ \t\n\r]*>")
  	  (progn
  	    (forward-char 2)
! 	    (nreverse (cons '("") children)))
  
  	;; is this a valid start tag ?
  	(if (eq (char-after) ?>)
--- 222,228 ----
        (if (looking-at "/[ \t\n\r]*>")
  	  (progn
  	    (forward-char 2)
! 	    (list children))
  
  	;; is this a valid start tag ?
  	(if (eq (char-after) ?>)

Re: xml.el produces incorrect sexp for empty element.

[Thien-Thi Nguyen]

mah@everybody.org (Mark A. Hershberger) writes:

   * xml.el (xml-parse-tag): Fixed incorrect handling of empty elements.

because i'm not an xml expert i don't understand what was incorrect
before.  could you reword this in the sense of:

  * xml.el (xml-parse-tag): Handle empty elements [IN CORRECT WAY].

w/ a touch more detail on the correction made?  this would allow an xml
expert to easily validate the change (so that us non-experts who depend
on them can update the repo w/ confidence).  if you're already an xml
expert, consider this a chance to educate a non-expert.

thi

Re: xml.el produces incorrect sexp for empty element.

[Mark A. Hershberger]

Thien-Thi Nguyen <ttn@glug.org> writes:

> mah@everybody.org (Mark A. Hershberger) writes:
>
>    * xml.el (xml-parse-tag): Fixed incorrect handling of empty elements.
>
> because i'm not an xml expert i don't understand what was incorrect
> before.  could you reword this in the sense of:
>
>   * xml.el (xml-parse-tag): Handle empty elements [IN CORRECT WAY].
>
> w/ a touch more detail on the correction made?

I did this with my previous patches, but since I made a mistake in
that last patch, thank you for the opportunity to fix my mistake.

    The old xml-parse-region parses the following two bits of XML into
    different sexps.

        "<xml/>" is parsed to ((xml nil ("")))

    while

        "<xml></xml>" is parsed to ((xml nil))

    <URL: http://www.w3.org/TR/2000/REC-xml-20001006#sec-starttags>
    states that "An element with no content is said to be empty.] The
    representation of an empty element is either a start-tag
    immediately followed by an end-tag, or an empty-element tag."

    So, "<xml/>" is equivilent to "<xml></xml>", but they don't parse
    the same in xml.el.
    
The following patch and changelog fix the problem.

mah@everybody.org (Mark A. Hershberger) writes:                         
                                                                         
   * xml.el (xml-parse-tag): Fixed handling of empty elements so that
     "<x/>" parses the same as "<x></x>".

*** xml.el.~1.18.~	Thu Mar 20 12:01:04 2003
--- xml.el	Fri May 30 15:37:12 2003
***************
*** 221,228 ****
        ;; is this an empty element ?
        (if (looking-at "/[ \t\n\r]*>")
  	  (progn
! 	    (forward-char 2)
! 	    (nreverse (cons '("") children)))
  
  	;; is this a valid start tag ?
  	(if (eq (char-after) ?>)
--- 221,228 ----
        ;; is this an empty element ?
        (if (looking-at "/[ \t\n\r]*>")
  	  (progn
! 	    (goto-char (match-end 0))
! 	    (nreverse children))
  
  	;; is this a valid start tag ?
  	(if (eq (char-after) ?>)



-- 
As long as you have mystery you have health; when you destroy mystery
you create morbidity.			     -- G.K. Chesterson

Re: xml.el produces incorrect sexp for empty element.

[Thien-Thi Nguyen]

   From: mah@everybody.org (Mark A. Hershberger)
   Date: Fri, 30 May 2003 15:38:57 -0500

   [two "empty element" representations]

cool, now i understand.

looks like Stefan Monnier has made the change in xml.el and graciously
(?) left the ChangeLog for me to fill in.  everything is synched in cvs
HEAD now.  thanks for your persistence.

thi