From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lucien Pullen Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] Update package: psgml (discard patch) Date: Wed, 26 Apr 2017 04:50:31 -0600 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493204033 23543 195.159.176.226 (26 Apr 2017 10:53:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Apr 2017 10:53:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (darwin) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 26 12:53:49 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3KZv-0005zl-DH for ged-emacs-devel@m.gmane.org; Wed, 26 Apr 2017 12:53:47 +0200 Original-Received: from localhost ([::1]:54235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3Ka1-0003YN-2q for ged-emacs-devel@m.gmane.org; Wed, 26 Apr 2017 06:53:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3KWv-0001F7-3b for emacs-devel@gnu.org; Wed, 26 Apr 2017 06:50:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d3KWq-0007S9-5y for emacs-devel@gnu.org; Wed, 26 Apr 2017 06:50:41 -0400 Original-Received: from mail-oi0-x242.google.com ([2607:f8b0:4003:c06::242]:35012) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d3KWp-0007Rs-V3 for emacs-devel@gnu.org; Wed, 26 Apr 2017 06:50:36 -0400 Original-Received: by mail-oi0-x242.google.com with SMTP id m34so33957117oik.2 for ; Wed, 26 Apr 2017 03:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:references:mail-followup-to:date:in-reply-to :message-id:user-agent:mime-version; bh=bsrflk0MG8QlD4N36/gCz5bOakez/rHymRn6Mz2nvjs=; b=RbDP2VORkq4B/YMeqJJAxL2BLak6V4rLSxr4bCKHSizbynKsFuh5qwqR/NGNy6Gi7S WyBmA7JubbAv2MJgu9M6fhZ6+Ybpjb7TZ2R9t5MySO50/4rV8mlFaxapNKPT5EUE8oLt SgVPNRfBFbgehPQXdAYZDCoqAXsK1x262SnorEz5Ic+AOjwQI3fLl0tVxIcdGhx8fecu rtLs8KNa7ReP3zj/HlO/xCERrTbxpdbe2IywE54fC3nR/3isUQsvE3/FrUIBChLyv1xs n6gM0/YuciGoo3hceGbcd2mkSTOBZgHuMm9OhRdfkiRhheqFbLoaDvFpMrXOz01ro7pL j+kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:references:mail-followup-to:date :in-reply-to:message-id:user-agent:mime-version; bh=bsrflk0MG8QlD4N36/gCz5bOakez/rHymRn6Mz2nvjs=; b=EC+wvxJD9TPIlLDP4VKqfTjGd0HZsCxD94m/yd9FrKtUghdFmdd/ykD1UEB6t3ggiU WeWgZwM18KS3ZuupEL4iH5nq5DpzNyPFfcv/eqx4gBk14AfDR2tD1RDosPQDK9Q9e5Lb aUKpVABwSe6gQXUA5cYNQ2ysz3+i93XxQtYam0iiZEb0diy7PQ8VXcdK25fUplHAdP9q Q4JsU4gmwcFbCH7OIv6GTRHsAzmtiwt6VS0dQyXbLSjHgF5OHnx4Knc9LBR/RiJ4UOdO Qxrtwl1Ld0x+4xmtMvHMw/WKphOMBQDhL3MZdf/noZo3k9lazKBK9Uk58u/7txlVgXM9 1HXg== X-Gm-Message-State: AN3rC/7QoNdctHXmTmC3tzzTvFDrAiX5dCeBhYEsAQfdYiQwiHiKdQVt 3TiD74EIAVlKWg== X-Received: by 10.157.41.194 with SMTP id g2mr11369482otd.268.1493203834872; Wed, 26 Apr 2017 03:50:34 -0700 (PDT) Original-Received: from lucien.drurowin.org (c-71-56-236-181.hsd1.co.comcast.net. [71.56.236.181]) by smtp.googlemail.com with ESMTPSA id j16sm5027291oth.12.2017.04.26.03.50.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Apr 2017 03:50:33 -0700 (PDT) Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Fri, 21 Apr 2017 10:00:49 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::242 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214301 Archived-At: 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.