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

[Lucien Pullen <drurowin@gmail.com>]

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.