10:07 p.m.
Adrian, could you elaborate a bit on why it is necessary to put
html-font-lock-keywords into effect when one is editing an XML file [1]?
Those keywords contain stuff that is plain wrong in XML, such as
fontifying stuff inside the <strong> tag in bold.
Fontification in psgml is certainly a Very Good Thing, but I think the
current approach is not correct. Additionally, psgml-parse.el already
has some fontification stuff (not font-lock), and mixing font-lock with
it might produce weird side effects. At least my XEmacs behaves pretty
unexpectedly when editing HTML files nowadays, try it out like this:
1) Start XEmacs, C-x C-f doesnt_exist.html RET
2) Fill in the document title
3) Note the colours
4) Go down below the <h1> tag, hit TAB
5) Watch the colours change
I think this is because psgml's own fontification kicks in when one hits
the TAB in the above. Doing M-x font-lock-fontify-buffer RET brings
back a consistent state (ie. the one that psgml-html and its font-lock
does), but editing the buffer after that again changes the colours.
As you already note in [1], this is the first cut and most likely work
in progress, but could you give any estimates how/when/if you're
planning to continue the work? I'm afraid that we'll start receiving
bug reports about this soon...
[1] <http://list-archive.xemacs.org/xemacs-patches/200112/msg00169.html>
--
\/ille Skyttä
ville.skytta at xemacs.org
12:06 a.m.
On 06 Sep 2002, ville.skytta(a)xemacs.org wrote:
Adrian, could you elaborate a bit on why it is necessary to put
html-font-lock-keywords into effect when one is editing an XML file [1]?
There were several complaints on the mailing lists about xml mode not
fontifying.
(put 'xml-mode 'font-lock-defaults '(html-font-lock-keywords nil t))
The problem is that without the above html-font-lock hack, xml-mode
does not do font locking. xml-mode does some sort of font locking if
you have set various configuration variables sgml-auto-activate-dtd
and sgml-set-face. If these variables are set, then xml code will be
fontified according to sgml-markup-faces.
For example, here was my effort at getting something without the
html-font-lock-keywords hack.
(setq-default sgml-auto-activate-dtd t)
(setq-default sgml-set-face t)
(setq-default sgml-markup-faces
'((start-tag . font-lock-keyword-face)
(end-tag . font-lock-keyword-face)
(ignored . font-lock-string-face)
(ms-start . font-lock-other-type-face)
(ms-end . font-lock-other-type-face)
(shortref . font-lock-reference-face)
(entity . font-lock-reference-face)
(comment . font-lock-comment-face)
(pi . custom-changed-face)
(sgml . font-lock-function-name-face)
(doctype . font-lock-emphasized-face)))
sgml-auto-activate-dtd causes other things to happen. Anyway,
Eventually, you get some sort of font locking. I gave up the
markup-faces and went back to using the html font lock keywords.
Those keywords contain stuff that is plain wrong in XML, such as
fontifying stuff inside the <strong> tag in bold.
Maybe. If you have xhtml stuff mixed in it would be correct?
Fontification in psgml is certainly a Very Good Thing, but I think
the
current approach is not correct. Additionally, psgml-parse.el already
has some fontification stuff (not font-lock), and mixing font-lock with
it might produce weird side effects. At least my XEmacs behaves pretty
unexpectedly when editing HTML files nowadays, try it out like this:
1) Start XEmacs, C-x C-f doesnt_exist.html RET
2) Fill in the document title
3) Note the colours
4) Go down below the <h1> tag, hit TAB
5) Watch the colours change
I think this is because psgml's own fontification kicks in when one hits
the TAB in the above. Doing M-x font-lock-fontify-buffer RET brings
back a consistent state (ie. the one that psgml-html and its font-lock
does), but editing the buffer after that again changes the colours.
I've noticed that as well. This xml-mode font-lock hack wouldn't
explain this particular problem though? html-mode doesn't call
xml-mode? Right?
As you already note in [1], this is the first cut and most likely
work
in progress, but could you give any estimates how/when/if you're
planning to continue the work? I'm afraid that we'll start receiving
bug reports about this soon...
[1]
<http://list-archive.xemacs.org/xemacs-patches/200112/msg00169.html >
-jeff
12:32 a.m.
On Fri, 2002-09-06 at 02:06, Jeff Mincy wrote:
[...]
(put 'xml-mode 'font-lock-defaults
'(html-font-lock-keywords nil t))
The problem is that without the above html-font-lock hack, xml-mode
does not do font locking. xml-mode does some sort of font locking if
you have set various configuration variables sgml-auto-activate-dtd
and sgml-set-face. If these variables are set, then xml code will be
fontified according to sgml-markup-faces.
[...]
Ok. I wasn't quite up to date how the built-in fontification in psgml
works, thanks for the explanation. It looks a bit hairy indeed,
especially with the requirement for sgml-auto-activate-dtd.
> Those keywords contain stuff that is plain wrong in XML, such
as
> fontifying stuff inside the <strong> tag in bold.
Maybe. If you have xhtml stuff mixed in it would be correct?
Yes, for the XHTML parts of it. But I'm against blindly applying it to
*all* XML documents.
Additionally, it might be pretty hard to implement the fontification for
arbitrary XML docs containing XHTML inside, along with other namespaces,
properly. Doable, but IMHO not worth it. Instead, the HTML keywords
could be used if the DTD of the doc says it's XHTML. Hmm, maybe
detecting this requires auto-activation of the DTD... :(
> I think this is because psgml's own fontification kicks in
when one hits
> the TAB in the above. Doing M-x font-lock-fontify-buffer RET brings
> back a consistent state (ie. the one that psgml-html and its font-lock
> does), but editing the buffer after that again changes the colours.
I've noticed that as well. This xml-mode font-lock hack wouldn't
explain this particular problem though? html-mode doesn't call
xml-mode? Right?
Right, kind of. It isn't related to xml-mode, but sgml-mode and the
assumption that the built-in fontification of sgml-mode and the
font-lock stuff in psgml-html don't play together well. sgml-mode is
related, because html-mode derives from it.
> As you already note in [1], this is the first cut and most
likely work
> in progress, but could you give any estimates how/when/if you're
> planning to continue the work? I'm afraid that we'll start receiving
> bug reports about this soon...
Hmm, on a second look, this has been in CVS since last December, and at
least I don't remember seeing bug reports about this.
Nevertheless, this obviously needs some work. I'll see if I can come up
with a plan and/or patches soon.
Cheers,
--
\/ille Skyttä
ville.skytta at xemacs.org
1:22 p.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Fri, 2002-09-06 at 02:06, Jeff Mincy wrote:
Ville> [...]
> (put 'xml-mode 'font-lock-defaults
'(html-font-lock-keywords nil t))
>
> The problem is that without the above html-font-lock hack, xml-mode
> does not do font locking. xml-mode does some sort of font locking if
> you have set various configuration variables sgml-auto-activate-dtd
> and sgml-set-face. If these variables are set, then xml code will be
> fontified according to sgml-markup-faces.
Ville> [...]
Ville> Ok. I wasn't quite up to date how the built-in fontification in psgml
Ville> works, thanks for the explanation. It looks a bit hairy indeed,
Ville> especially with the requirement for sgml-auto-activate-dtd.
> > Those keywords contain stuff that is plain wrong in XML,
such as
> > fontifying stuff inside the <strong> tag in bold.
>
> Maybe. If you have xhtml stuff mixed in it would be correct?
Ville> Yes, for the XHTML parts of it. But I'm against blindly applying it to
Ville> *all* XML documents.
Ville> Additionally, it might be pretty hard to implement the fontification for
Ville> arbitrary XML docs containing XHTML inside, along with other namespaces,
Ville> properly. Doable, but IMHO not worth it. Instead, the HTML keywords
Ville> could be used if the DTD of the doc says it's XHTML. Hmm, maybe
Ville> detecting this requires auto-activation of the DTD... :(
> > I think this is because psgml's own fontification kicks
in when one hits
> > the TAB in the above. Doing M-x font-lock-fontify-buffer RET brings
> > back a consistent state (ie. the one that psgml-html and its font-lock
> > does), but editing the buffer after that again changes the colours.
>
> I've noticed that as well. This xml-mode font-lock hack wouldn't
> explain this particular problem though? html-mode doesn't call
> xml-mode? Right?
Ville> Right, kind of. It isn't related to xml-mode, but sgml-mode and the
Ville> assumption that the built-in fontification of sgml-mode and the
Ville> font-lock stuff in psgml-html don't play together well. sgml-mode is
Ville> related, because html-mode derives from it.
> > As you already note in [1], this is the first cut and most
likely work
> > in progress, but could you give any estimates how/when/if you're
> > planning to continue the work? I'm afraid that we'll start receiving
> > bug reports about this soon...
Ville> Hmm, on a second look, this has been in CVS since last
Ville> December, and at least I don't remember seeing bug reports
Ville> about this.
Ville> Nevertheless, this obviously needs some work. I'll see if
Ville> I can come up with a plan and/or patches soon.
Hi Ville,
I agree with your findings.
I don't have time to work on this in the near future and look forward
to your patches.
Best regards,
Adrian
Ville> Cheers,
Ville> --
Ville> \/ille Skyttä
Ville> ville.skytta at xemacs.org
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8109
days inactive
8115
days old
3 comments
3 participants
participants (3)
-
Adrian Aichner -
Jeff Mincy -
Ville Skyttä