Blocking DTD usage with PSGML-mode
Phillip Lord
Can anyone tell me how I can switch off psgml-modes
dependency on having a DTD present, and stop it giving me lots of
warnings about this.
The problem is this. I use psgml with a DTD lots of the
time and find it very useful. On the other hand there are lots of XML
documents for which I have no DTD. I would like psgml to just do
syntax highlighting, and indentation, which it appears to be capable
of without a DTD.
In particular I want to get rid of the log message...
External entity tagname not found
and the error...
No document type defined by prolog
Of course I realise that I will loose a lot of psgml
functionality when I don't have a DTD. This is okay.
I could probably just use emacs' standard sgml mode
but the problem is of course that it name clashes with psgml-mode, so
I can't use both.
Any help gratefully received.
Phil
Kevin Rodgers
>
> Can anyone tell me how I can switch off psgml-modes
> dependency on having a DTD present, and stop it giving me lots of
> warnings about this.
>
> The problem is this. I use psgml with a DTD lots of the
> time and find it very useful. On the other hand there are lots of XML
> documents for which I have no DTD. I would like psgml to just do
> syntax highlighting, and indentation, which it appears to be capable
> of without a DTD.
File: psgml.info, Node: Invoke, Next: Entity manager, Prev: Install, Up: Top
How to invoke PSGML
*******************
PSGML defines a major modes called `sgml-mode' and `xml-mode'.
Files with extensions `.sgml', `.sgm' or `.dtd' will automatically be
edited in SGML mode. To edit some other file in SGML mode, type `M-x
sgml-mode <RET>' after finding the file. To edit XML files, type `M-x
xml-mode <RET>'.
--
Kevin Rodgers <kev...@ihs.com>
Kai Großjohann
> File: psgml.info, Node: Invoke, Next: Entity manager, Prev: Install, Up: Top
>
> How to invoke PSGML
> *******************
>
> PSGML defines a major modes called `sgml-mode' and `xml-mode'.
> Files with extensions `.sgml', `.sgm' or `.dtd' will automatically be
> edited in SGML mode. To edit some other file in SGML mode, type `M-x
> sgml-mode <RET>' after finding the file. To edit XML files, type `M-x
> xml-mode <RET>'.
Hm?
None of the above helps at all when the DTD is missing.
kai
--
Symbol's function definition is void: signature
Phillip Lord
Kai> Kevin Rodgers <kev...@ihs.com> writes:
>> File: psgml.info, Node: Invoke, Next: Entity manager, Prev:
>> Install, Up: Top
>>
>> How to invoke PSGML *******************
>>
>> PSGML defines a major modes called `sgml-mode' and `xml-mode'.
>> Files with extensions `.sgml', `.sgm' or `.dtd' will
>> automatically be edited in SGML mode. To edit some other file in
>> SGML mode, type `M-x sgml-mode <RET>' after finding the file. To
>> edit XML files, type `M-x xml-mode <RET>'.
Kai> Hm?
Kai> None of the above helps at all when the DTD is missing.
Is it possible to rebind all of the function definitions of
normal sgml mode to some other name space? Then I wouldn't have the
name clash problem. I could use normal sgml mode when without DTD.
Of course this goes beyond the limits of normal sanity,
and well into the realm of complete hackery. Still it would be
useful. The sgml- name clash is not the only one out there. Normal
latex mode, and Auctex clash also, and I am sure that there are others
(not that I want to use anything other than auctex but...)
Phil
Stefan Monnier <foo@acm.com>
> Is it possible to rebind all of the function definitions of
> normal sgml mode to some other name space? Then I wouldn't have the
> name clash problem. I could use normal sgml mode when without DTD.
Not that I know, although I agree that psgml should use `psgml-' as
a prefix so as to avoid this name clash. I think the reason was that
it was assumed that psgml was so superior that it made the other
mode completely unnecessary.
> Of course this goes beyond the limits of normal sanity,
> and well into the realm of complete hackery. Still it would be
> useful. The sgml- name clash is not the only one out there. Normal
> latex mode, and Auctex clash also, and I am sure that there are others
> (not that I want to use anything other than auctex but...)
I believe that AucTeX is fairly well behaved and doesn't clash too badly
with tex-mode. It does redefine `latex-mode' and `tex-mode' and
`plain-tex-mode', but the rest uses `TeX-' or `LaTeX-' prefixes so it
doesn't collide with the `tex-' and `latex-' prefixes of tex-mode.el.
Stefan
Per Abrahamsen
> I believe that AucTeX is fairly well behaved and doesn't clash too badly
> with tex-mode. It does redefine `latex-mode' and `tex-mode' and
> `plain-tex-mode', but the rest uses `TeX-' or `LaTeX-' prefixes so it
> doesn't collide with the `tex-' and `latex-' prefixes of tex-mode.el.
Actually, it is Emacs that is well behaved ;-)
Originally standard tex-mode.el used "TeX-" and "LaTeX-" prefixes, but
this was changed for some reason beyond me.
One reason AUC TeX defines tex-mode and latex-mode is that otherwise
files staring with -*- latex -*- would load the wrong LaTeX mode.
While the type of the file is a property of the file, the prefered
mode for editing such files is a property of the user.
Phillip Lord
>>>>> "Phillip" == Phillip Lord <p.l...@russet.org.uk> writes:
>> Is it possible to rebind all of the function definitions of
>> normal sgml mode to some other name space? Then I wouldn't have
>> the name clash problem. I could use normal sgml mode when without
>> DTD.
Stefan> Not that I know, although I agree that psgml should use
Stefan> `psgml-' as a prefix so as to avoid this name clash.
I guess I could just do a search and replace on all
of the source. You never know it might even work.
Stefan> I think the reason was that it was assumed that psgml was so
Stefan> superior that it made the other mode completely unnecessary.
There is a certain amount of sense in this. I guess the key
problem is that I am using PSGML mode to edit XML, and it just does
not support that at the moment, because of its dependency on DTD
rather than schema.
I guess this situation is likely to remain for a while. I
guess that its one of the problems with the more complex emacs modes,
which is that ultimately they are less adaptable.
>> Of course this goes beyond the limits of normal sanity, and well
>> into the realm of complete hackery. Still it would be useful. The
>> sgml- name clash is not the only one out there. Normal latex
>> mode, and Auctex clash also, and I am sure that there are others
>> (not that I want to use anything other than auctex but...)
Stefan> I believe that AucTeX is fairly well behaved and doesn't
Stefan> clash too badly with tex-mode. It does redefine
Stefan> `latex-mode' and `tex-mode' and `plain-tex-mode', but the
Stefan> rest uses `TeX-' or `LaTeX-' prefixes so it doesn't collide
Stefan> with the `tex-' and `latex-' prefixes of tex-mode.el.
Ah okay. I'd seen that it rebound "latex-mode", and
assumed that there were more clashes.
Phil
Phillip Lord
Per> "Stefan Monnier <f...@acm.com>"
Per> <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:
>> I believe that AucTeX is fairly well behaved and doesn't clash
>> too badly with tex-mode. It does redefine `latex-mode' and
>> `tex-mode' and `plain-tex-mode', but the rest uses `TeX-' or
>> `LaTeX-' prefixes so it doesn't collide with the `tex-' and
>> `latex-' prefixes of tex-mode.el.
Per> Actually, it is Emacs that is well behaved ;-)
Per> Originally standard tex-mode.el used "TeX-" and "LaTeX-"
Per> prefixes, but this was changed for some reason beyond me.
I guess its just that lower case is the standard for
emacs lisp.
Per> One reason AUC TeX defines tex-mode and latex-mode is that
Per> otherwise files staring with -*- latex -*- would load the wrong
Per> LaTeX mode.
Per> While the type of the file is a property of the file, the
Per> prefered mode for editing such files is a property of the user.
File variables, and magic cookie lines contradict this
anyway. The same problem exists with cperl/perl modes. Some people
insist on putting "perl" identifiers at the top, and then cperl user
get the wrong mode. And vice versa.
Its a tricky one...
Phil
Stefan Monnier <foo@acm.com>
Per> otherwise files staring with -*- latex -*- would load the wrong
Per> LaTeX mode.
There are indeed plenty of reasons for doing it. And it's really
not too bad a conflict: as long as tex-mode is loaded after AucTeX,
you can choose between LaTeX-mode and latex-mode.
Ideally the (defalias 'latex-mode 'LaTeX-mode) could be in tex-site.el
but the difference is really minor.
> File variables, and magic cookie lines contradict this
> anyway. The same problem exists with cperl/perl modes. Some people
> insist on putting "perl" identifiers at the top, and then cperl user
> get the wrong mode. And vice versa.
The correct way is to put `perl' (after all, that's the kind of
file it is). After all, CPerl users should already have something
like (defalias 'perl-mode 'cperl-mode) somewhere.
Stefan
Phillip Lord
>> File variables, and magic cookie lines contradict this
>> anyway. The same problem exists with cperl/perl modes. Some
>> people insist on putting "perl" identifiers at the top, and then
>> cperl user get the wrong mode. And vice versa.
Stefan> The correct way is to put `perl' (after all, that's the kind
Stefan> of file it is). After all, CPerl users should already have
Stefan> something like (defalias 'perl-mode 'cperl-mode) somewhere.
I'm a little bit confused when anyone would put anything
at all. Emacs works it out fine anyway. I guess if someone is doing a
lot of prolog and a little bit of perl....
Phil
Kevin Rodgers
>
> >>>>> "Stefan" == "Stefan Monnier <f...@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:
>
> >>>>> "Phillip" == Phillip Lord <p.l...@russet.org.uk> writes:
> >> Is it possible to rebind all of the function definitions of
> >> normal sgml mode to some other name space? Then I wouldn't have
> >> the name clash problem. I could use normal sgml mode when without
> >> DTD.
>
> Stefan> Not that I know, although I agree that psgml should use
> Stefan> `psgml-' as a prefix so as to avoid this name clash.
>
> I guess I could just do a search and replace on all
> of the source. You never know it might even work.
Here's a crazy way to do that: evaluate this after psgml is loaded (but
before sgml-mode is loaded):
(mapatoms (lambda (symbol)
(if (string-match "\\`sgml\\>" (symbol-name symbol))
(let ((psgml-symbol (intern (concat "p" (symbol-name symbol)))))
(if (boundp symbol)
(set psgml-symbol (symbol-value symbol)))
(if (fboundp symbol)
(fset psgml-symbol (symbol-function symbol)))
(setplist psgml-symbol (symbol-plist symbol))
(unintern symbol)))))
Even crazier: I tried advising `intern' to return a "psgml-" symbol instead
of an "sgml-" symbol (while psgml is being loaded), but didn't have any luck.
--
Kevin Rodgers <kev...@ihs.com>
Phillip Lord
Kevin> Phillip Lord wrote:
>> >>>>> "Stefan" == "Stefan Monnier <f...@acm.com>"
>> <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:
>>
>> >>>>> "Phillip" == Phillip Lord <p.l...@russet.org.uk> writes: >>
>> Is it possible to rebind all of the function definitions of >>
>> normal sgml mode to some other name space? Then I wouldn't have
>> >> the name clash problem. I could use normal sgml mode when
>> without >> DTD.
>>
Stefan> Not that I know, although I agree that psgml should use
Stefan> `psgml-' as a prefix so as to avoid this name clash.
>> I guess I could just do a search and replace on all of the
>> source. You never know it might even work.
Kevin> Here's a crazy way to do that: evaluate this after psgml is
Kevin> loaded (but before sgml-mode is loaded):
Kevin> (mapatoms (lambda (symbol) (if (string-match "\\`sgml\\>"
Kevin> (symbol-name symbol)) (let ((psgml-symbol (intern (concat "p"
Kevin> (symbol-name symbol))))) (if (boundp symbol) (set
Kevin> psgml-symbol (symbol-value symbol))) (if (fboundp symbol)
Kevin> (fset psgml-symbol (symbol-function symbol))) (setplist
Kevin> psgml-symbol (symbol-plist symbol)) (unintern symbol)))))
Kevin> Even crazier: I tried advising `intern' to return a "psgml-"
Kevin> symbol instead of an "sgml-" symbol (while psgml is being
Kevin> loaded), but didn't have any luck.
Ah this is just the sort of insanity that I was looking for.
It almost works too. I got it working fine (ie I could switch
between sgml and psgml mode), so long as there was nothing in the
buffer. Other wise it balked on some of the common lisp code, whilst
fontifying.
Still intellectually you feel that it deserved to work....
I guess the search and replace might be the better solution.
Perhaps I shall try it sometime when I am bored.
Actually I've realised that its not such a good solution,
because the standard sgml-mode is of course not name-space aware, and
the ":" screw up all of the fontification.
Ho hum....
Phil
Kevin Rodgers
>
> >>>>> "Kevin" == Kevin Rodgers <kev...@ihs.com> writes:
>
> Kevin> Here's a crazy way to do that: evaluate this after psgml is
> Kevin> loaded (but before sgml-mode is loaded):
>
> Kevin> (mapatoms (lambda (symbol) (if (string-match "\\`sgml\\>"
> Kevin> (symbol-name symbol)) (let ((psgml-symbol (intern (concat "p"
> Kevin> (symbol-name symbol))))) (if (boundp symbol) (set
> Kevin> psgml-symbol (symbol-value symbol))) (if (fboundp symbol)
> Kevin> (fset psgml-symbol (symbol-function symbol))) (setplist
> Kevin> psgml-symbol (symbol-plist symbol)) (unintern symbol)))))
>
> Kevin> Even crazier: I tried advising `intern' to return a "psgml-"
> Kevin> symbol instead of an "sgml-" symbol (while psgml is being
> Kevin> loaded), but didn't have any luck.
>
> Ah this is just the sort of insanity that I was looking for.
That's what I'm here for. :-)
> It almost works too. I got it working fine (ie I could switch
> between sgml and psgml mode), so long as there was nothing in the
> buffer. Other wise it balked on some of the common lisp code, whilst
> fontifying.
Could you describe what happens in more detail?
--
Kevin Rodgers <kev...@ihs.com>
Phillip Lord
Kevin> That's what I'm here for. :-)
>> It almost works too. I got it working fine (ie I could switch
>> between sgml and psgml mode), so long as there was nothing in the
>> buffer. Other wise it balked on some of the common lisp code,
>> whilst fontifying.
Kevin> Could you describe what happens in more detail?
Here are two stack traces. You get this if you hit
tab someway down the document which fontifies down to that point. This
happens after you have run your code, and whether or not normal sgml
mode has been loaded.
Phil
Debugger entered--Lisp error: (void-function extent-property)
(extent-property e (quote sgml-type))
(if (extent-property e (quote sgml-type)) (progn (cond ... ...)))
(when (extent-property e (quote sgml-type)) (cond (... ...) (t ...)))
(progn (when (extent-property e ...) (cond ... ...)))
(lambda (e G98106) (progn (when ... ...)) nil)(#<overlay from 3 to 6 in identifier.xsd> nil)
cl-map-overlays((lambda (e G98106) (progn (when ... ...)) nil) nil 1 39)
apply(cl-map-overlays ((lambda (e G98106) (progn ...) nil) nil 1 39))
cl-map-extents((lambda (e G98106) (progn (when ... ...)) nil) nil 1 39)
(catch (quote --cl-block---cl-finish----) (cl-map-extents (function ...) nil start end))
(cl-block-wrapper (catch (quote --cl-block---cl-finish----) (cl-map-extents ... nil start end)))
(block --cl-finish-- (cl-map-extents (function ...) nil start end))
(catch (quote --cl-block-nil--) (block --cl-finish-- (cl-map-extents ... nil start end)) nil)
(cl-block-wrapper (catch (quote --cl-block-nil--) (block --cl-finish-- ...) nil))
(block nil (block --cl-finish-- (cl-map-extents ... nil start end)) nil)
(loop for e being the extents from start to end do (when (extent-property e ...) (cond ... ...)))
(let ((face ...) o) (loop for e being the extents from start to end do (when ... ...)) (cond (o ...) (face ... ... ... ... ...)))
sgml-set-face-for(1 39 pi)
sgml-set-markup-type(pi)
(if in-declaration nil (sgml-set-markup-type (quote pi)))
(unless in-declaration (sgml-set-markup-type (quote pi)))
sgml-do-processing-instruction(nil)
sgml-parse-prolog()
sgml-load-doctype()
sgml-need-dtd()
sgml-parse-to(2145)
sgml-find-context-of(2145)
byte-code(" B #
sgml-indent-line()
sgml-indent-or-tab()
* call-interactively(sgml-indent-or-tab)
Debugger entered--Lisp error: (void-function make-extent)
(make-extent start end)
(setq o (make-extent start end))
(cond (o (set-extent-endpoints o start end)) (face (setq o ...) (set-extent-property o ... type) (set-extent-property o ... face) (set-extent-property o ... t) (set-extent-face o face)))
(let ((face ...) o) (loop for e being the extents from start to end do (when ... ...)) (cond (o ...) (face ... ... ... ... ...)))
sgml-set-face-for(1 39 pi)
sgml-set-markup-type(pi)
(if in-declaration nil (sgml-set-markup-type (quote pi)))
(unless in-declaration (sgml-set-markup-type (quote pi)))
sgml-do-processing-instruction(nil)
sgml-parser-loop(nil)
sgml-parse-to(1264)
sgml-find-context-of(1264)
byte-code(" B #
sgml-indent-line()
sgml-indent-or-tab()
* call-interactively(sgml-indent-or-tab)
Kai Großjohann
> Debugger entered--Lisp error: (void-function extent-property)
Extents are an XEmacs thing. Did you create the *.elc files for PSGML
with XEmacs? Maybe the beginning of the files tells you.
Or are you using a version of PSGML which was changed to work with XEmacs?
kai
--
Abort this operation? [OK] [Cancel]
Phillip Lord
Kai> Phillip Lord <p.w....@cs.man.ac.uk> writes:
>> Debugger entered--Lisp error: (void-function extent-property)
Kai> Extents are an XEmacs thing. Did you create the *.elc files
Kai> for PSGML with XEmacs? Maybe the beginning of the files tells
Kai> you.
As far as I know I compiled the .elc files with Gnu Emacs,
although I suppose the configure script could have done something
wacky when I wasn't looking.
Kai> Or are you using a version of PSGML which was changed to work
Kai> with XEmacs?
Again not as far as I know.
BTW just in case you have forgotten the earlier part of the
thread, its worth mentioning here, that I have done something very
very strange to psgml mode, so it wouldn't be surprising if it got
somewhat confused....
Phil
Kai Großjohann
> BTW just in case you have forgotten the earlier part of the
> thread, its worth mentioning here, that I have done something very
> very strange to psgml mode, so it wouldn't be surprising if it got
> somewhat confused....
Ah, thanks for the reminder. I've now reread your description. Yes,
quite possibly PSGML got confused as to whether it was running on
Emacs or XEmacs. You never know.
Can you try searching the psgml code to see where it tries to
distinguish between Emacs and XEmacs, or where it tries to figure out
whether the Emacs groks extents? Can you see something that might
provoke problems, together with your hack?
Phillip Lord
Kai> Phillip Lord <p.l...@russet.org.uk> writes:
>> BTW just in case you have forgotten the earlier part of the
>> thread, its worth mentioning here, that I have done something
>> very very strange to psgml mode, so it wouldn't be surprising if
>> it got somewhat confused....
Kai> Ah, thanks for the reminder. I've now reread your description.
Kai> Yes, quite possibly PSGML got confused as to whether it was
Kai> running on Emacs or XEmacs. You never know.
Kai> Can you try searching the psgml code to see where it tries to
Kai> distinguish between Emacs and XEmacs, or where it tries to
Kai> figure out whether the Emacs groks extents? Can you see
Kai> something that might provoke problems, together with your hack?
I'll try and have a pick through the code sometime. I find the
psgml code base fairly confusing though so I'm not sure how successful
I'll be!
Phil
Kevin Rodgers
>
> Phillip Lord <p.l...@russet.org.uk> writes:
>
> > BTW just in case you have forgotten the earlier part of the
> > thread, its worth mentioning here, that I have done something very
> > very strange to psgml mode, so it wouldn't be surprising if it got
> > somewhat confused....
>
> Ah, thanks for the reminder. I've now reread your description. Yes,
> quite possibly PSGML got confused as to whether it was running on
> Emacs or XEmacs. You never know.
But his *Backtrace*s show the PSGML functions being invoked via sgml- symbols,
not psgml- symbols, which indicates that my mapatoms hack didn't have its
intended effect. I suspect that's because it didn't take care to change all
the references to the sgml- symbols within the (byte-compiled) function
definitions (and variable values and property lists).
> Can you try searching the psgml code to see where it tries to
> distinguish between Emacs and XEmacs, or where it tries to figure out
> whether the Emacs groks extents? Can you see something that might
> provoke problems, together with your hack?
psgml.el defvars sgml-running-lucid, and requires either psgml-lucid (which
uses XEmacs' extent functions) or psgml-other (which doesn't) at load time
depending on its value. That variable is only consulted at run time by
sgml-mouse-region and sgml-mode, neither of which uses extent functions.
--
Kevin Rodgers <kev...@ihs.com>
Stefan Monnier <foo@acm.com>
> symbols, not psgml- symbols, which indicates that my mapatoms hack didn't
> have its intended effect. I suspect that's because it didn't take care to
> change all the references to the sgml- symbols within the (byte-compiled)
> function definitions (and variable values and property lists).
I'm disappointed then: you're not really aware of the cleverness of
your code: your code moves all the functions/variables from sgml-foo to
psgml-foo but doesn't redirect references to those psgml-foo symbols.
Instead it uninterns the original sgml-foo symbols. This last step
is rather clever because it means that when a psgml function calls sgml-foo
it will get the psgml version of that function even if sgml-foo is now
bound to something else (because you now have an uninterned `sgml-foo'
(from psgml-mode) and an interned one (from sgml-mode)). Both symbols
are printed as `sgml-foo' but they are different.
I.e. as long as psgml-mode itself doesn't do "clever" tricks like
constructing symbols on the fly (using `intern'), it should work
rather well.
Stefan