* bug#4950: `xml-parse-file' returns incorrect results strings after `>' before `<' when CR\LF TAB+
@ 2009-11-17 22:12 MON KEY
2012-07-01 11:22 ` Chong Yidong
0 siblings, 1 reply; 2+ messages in thread
From: MON KEY @ 2009-11-17 22:12 UTC (permalink / raw
To: bug-gnu-emacs
`xml-parse-file' returns incorrect results strings after `>' before
`<' when CR\LF TAB+
`xml-parse-file' fails to retrun correct results when there are ^C-j
(e.g. CR\LF)
followed by \t+ e.g TAB+ after a tag's trailing `>' and before the next tag's
leading `<'. IOW the following:
,----
| <ELEMENT attr1="a1" attr2="a2" attr3="a3" attr4="a4" attr5="a5">CR\LF
| TAB TAB TAB <NEXT-NODE>
`----
Returns (:NOTE with my pp-ing to help clarify the problem):
,----
| (ELEMENT nil
| ((attr1 . "a1")
| (attr2 . "a2")
| (attr3 . "a3")
| (attr4 . "a4")
| (attr5 . "a5") "
| " ;; <-i.e. (mapconcat #'char-to-string '(32 10 9 9 9) "")
| (NEXT-NODE nil (...
`----
Is it if fair/safe to assume that where these types of sequences occur they are
not part of the XML and can be removed with a regexp? E.g. :
,----
| (while (search-forward-regexp "\"\)\n[\[:blank:]]+\"\)" nil t)
| (replace-match ""))
`----
or perhaps:
,----
| (defun cln-xml<-parsed (fname &optional insertp intrp)
| "Strip non-sensical strings created by xml-parse-file because of
| CR\LF TAB+ following tags/elements.
| FNAME is an XML filename path to parse and clean.
| When INSERTP is non-nil or called-interactively insert pretty printed lisp
| representation of XML file at point. Does not move point."
| (interactive "fXML file to parse: \ni\np")
| (let (get-xml)
| (setq get-xml
| (with-temp-buffer
| (prin1 (xml-parse-file fname) (current-buffer))
| (goto-char (point-min))
| (while (search-forward-regexp
| "\\( \"\n[\[:blank:]]+\\)\"\\(\\(\\()\\)\\|\\(
(\\)\\)\\)" nil t)
| ;;^^1^^^^^^^^^^^^^^^^^^^^^^^^^2^^3^^^^^^^^^^^^4^^^^^^^^^^^^
| (replace-match "\\2"))
| (pp-buffer)
| (buffer-substring-no-properties (point-min) (point-max))))
| (if (or insertp intrp)
| (save-excursion
| (newline)
| (princ get-xml (current-buffer)))
| get-xml)))
`----
:SEE-ALSO
(URL `http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-11/msg00052.html')
s_P
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#4950: `xml-parse-file' returns incorrect results strings after `>' before `<' when CR\LF TAB+
2009-11-17 22:12 bug#4950: `xml-parse-file' returns incorrect results strings after `>' before `<' when CR\LF TAB+ MON KEY
@ 2012-07-01 11:22 ` Chong Yidong
0 siblings, 0 replies; 2+ messages in thread
From: Chong Yidong @ 2012-07-01 11:22 UTC (permalink / raw
To: MON KEY; +Cc: 4950
MON KEY <monkey@sandpframing.com> writes:
> <ELEMENT attr1="a1" attr2="a2" attr3="a3" attr4="a4" attr5="a5">CR\LF
> TAB TAB TAB <NEXT-NODE>
>
> Returns (:NOTE with my pp-ing to help clarify the problem):
>
> (ELEMENT nil
> ((attr1 . "a1")
> (attr2 . "a2")
> (attr3 . "a3")
> (attr4 . "a4")
> (attr5 . "a5") "
> " ;; <-i.e. (mapconcat #'char-to-string '(32 10 9 9 9) "")
> (NEXT-NODE nil (...
>
> Is it if fair/safe to assume that where these types of sequences occur
> they are not part of the XML and can be removed with a regexp?
No.
XML 1.0 Recommendation, Section 2.10 White Space Handling:
"An XML processor MUST always pass all characters in a document that are
not markup through to the application."
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-07-01 11:22 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-17 22:12 bug#4950: `xml-parse-file' returns incorrect results strings after `>' before `<' when CR\LF TAB+ MON KEY
2012-07-01 11:22 ` Chong Yidong
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.