Re: [ELPA] Update package: psgml (discard patch)

[Lucien Pullen]

Also sprach Stefan Monnier on 2017-04-21:
>>> In the specific case of psgml, I think the real fix should be to make
>>> psgml interact more normally with font-lock.  I haven't looked into it
>>> hard enough yet, tho.
>> PSGML only understands the reference concrete syntax, so, with a few
>> exceptions such as for fontifying Null End Tags only when they can occur
>> and using the value of parameter entities for marked sections, it should
>> be able to use font lock using regular expressions.
>
> From a cursory look at how it currently works, I got the impression that
> it can be made to use font-lock without changing fundamentally how it's
> done.  Using regexps would probably be more painful, less efficient,
> and/or less reliable (luckily, font-lock is not limited to regexps).

I'm experimenting with converting it to regular font lock.  I set up 
sgml-set-face-for to check for font-lock-mode, and I'm thinking of aliasing 
sgml-fontify-buffer to font-lock-fontify-buffer.  Also playing with custom 
faces using defface instead of using sgml-markup-faces.

I tried using the syntax-table text property to syntactically fontify attribute 
values like how sgml-mode does and either made emacs spin or erased all 
fontification.  I'm sure if I try doing that when more awake it'll work better. 
 The answer probably involves not using the syntax-table text property.

I figured out where the default faces come from!  It's the font lock keywords 
that builtin sgml-mode uses.

>>> This makes me feel like you indeed have a multi-major-mode situation, in
>>> which case sgml-set-face is probably just one part of the problem (and
>>> using indirect buffers would just add more problems).
>> I've run into multi-major-mode a lot while doing SGML stuff.
>
> [ Side note: given the goal of SGML/XML to provide a kind of "universal
>   syntax", the frequency with which even things specifically designed
>   for XML/SGML end up using a completely different syntax (e.g. CSS,
>   RNC, DSSSL, etc...), seems to be a strong indication of failure.
>   Of course, that's just the opinion of someone who's never much liked
>   the SGML/XML tags because of their verbosity.  ]

I hate XML's verbosity with a passion.  I'm a big fan of all those minimization 
features that XML turned off.

I've been looking at using SGML as a structured container, like how DSSSL uses 
it, so most of the document is written in some format better suited to whatever 
it represents.  It doesn't reek of failure too much then.

>> I do miss MuMaMo integration with nHTML,
>
> Did MuMaMo disappear?

No, I just don't find myself using nHTML any more.

> BTW, Tom Tromey has recently added a new mhtml-mode to Emacs, which
> "simply" combines Emacs's html-mode js-mode and css-mode.  It won't
> directly help your dsssl-mode, but maybe you could try to see if his
> approach could be used for your SGML+DSSSL case.  I don't see any strong
> reason why sgml-mode + dsssl-mode would be harder than what he did.
> I think making it work with psgml rather than the plain html-mode could
> be a fair bit of work, OTOH.

Thanks, I'll look into it if I can find it.

> While talking about ideas, I'd like to "merge" psgml-mode and sgml-mode.
> What "merge" means here is not completely clear, but most likely it
> means that psgml-mode would derive from sgml-mode, a bit like js2-mode
> derives from js-mode nowadays.

I'm actually a bit curious about the differences between the two modes.  They 
basically do the same thing, but psgml uses its own buffer walker and builtin 
SGML uses syntax tables and regular expressions... lots of functions and 
variables named the same, so much so that I deleted sgml-mode.el because they 
kept stepping on each other.

I'm scrolling through builtin sgml-mode, and it looks like writing the builtin 
in terms of psgml would be easier than writing psgml in terms of the builtin.  
I like the comment about what a valid comment is (though, I haven't read 
psgml's parse-comment to know if it's correct either... I assume it's better 
than builtin).

>> but I hardly write directly in HTML any more and I don't use PHP,
>> so...  There's something about the NOTATION attribute giving the
>> editor access to which major mode element content is in that lends
>> itself to multi-major-mode.
>
> I must admit that I don't know what you mean by "NOTATION attribute".

Basically, it specifies the syntax of content, like Emacs Lisp or C++.  When 
you feed your document to the application, the NOTATION attribute lets you 
communicate what program should parse the element instead of the SGML parser.

Back to your CSS comment, the TYPE attribute on the HTML LINK element would be 
a NOTATION attribute that lets you specify either CSS or (ugh) XSLT.

Also, psgml doesn't record notations.  I can get the public identifier for an 
entity, but not a notation.

>> At least, that's how I'd like to use psgml, but I need to learn a lot
>> more about modes before I tried something like making emacs SGML-aware.
>
> The SGML/XML support in Emacs is indeed in need of work.  Partly because
> of the amount of distinct solutions reinventing the wheel slightly
> differently (e.g. between sgml-mode, psgml-mode, nxml-mode, ...).

Well, they're good for different things.  nHTML gives you MuMaMo, which is a 
godsend for HTML-CSS-PHP-JS development.  sgml-mode is super fast and I find 
its html-mode and xml-mode almost too good.  psgml parses the document type 
definition similar to a full SGML parser, so it offers a lot of interactive 
editing help.

Too bad there's no Grand Unified SGML Library.