Re: XML-based text editor: a proposal
> I have posted a paper on the possible use of XML and XSLT/XPath as a > base for a general purpose programmable text editor (not a specialized > XML editor): > > http://www.kirsanov.com/te/te.html > > I will greatly appreciate comments from anyone, especially from > developers. The ideas look attractive to me, but the extent to which > they are implementable and workable is a matter for discussion. <quote> Some quarter-century ago, Richard M. Stallman was fascinated with Lisp, and he needed a good text editor. He decided to synchronize these two seemingly unrelated motives, and Emacs was born as a result. </quote> ... that was possible, because LISP was a general-purpose programming language ... <quote> Nowadays there is a community of people fascinated with all things XML, and many of us are still in search of a perfect text editor. It is natural to try to envision a new editor to which XML is what Lisp is to Emacs. </quote> ... The number of people who ( by mistake ) tried using XSLT for tasks that are better to be done in general-purpose programming language is very big. For example, long time ago I've written the XSLScript http://www.pault.com/pault/prod/XSLScript, that allows writing *very* complex XSLT stylesheets using terse notation and in parallel, I've written Ux ( http://www.pault.com/pault/old/Ux ) which was some kind of re-implementation of UNIX sh. I've stopped that branch after pushing XSLT to it's limits. <quote> Hopefully, this editor may ultimately become every bit as powerful as Emacs - and even go further. </quote> Nope. It would never happen, because XSLT just [expletive deleted] as a general purpose programming language. Honest. Not only because it is verbose. When I read your paper, I have a flashback. You try bulding on piped transfromations ( "two transforms working together" ), you try to use XSLT when ( I'm serious ) CSS model would make *much*better*design* ('properties inheritance' is kinda general mechanizm, which is in my oppinion underestimated) I'd suggest the following design approach: 1. Think about the document as if it is a tree that you can access by ( not existant ) XPath--. 2. Your XPath has to be bi-directional, you should be able not only to get some propreties, but to set them as well. 3. Properties should be cascaded ( CSS ). 4. In fact, when saying 'property' I'm talking not only about the properties presented in the document, but also about the properties, 'attached' to the tree by the editor itself. 5. Try to use XSLT-izms for processing of mixed context only, because that's the best use for XSLT. 6. Open the framework described above to plugins that could be possibly written in *any* language. ( Java [expletive deleted] for text processing. Perl or Python would do much better job ). I agree that XML and XPath can give new life to text editing, so in principle, I think that your idea is interesting. I just wanted to say that from my experience, building on XSLT would be the biggest possible mistake, because supporting big number of XSLT transformations playing together is a pain. For many reasons. For example, piping transformations were not supported in XSLT by initial design ( hardcoded 'xt:node-set' is rather 'recent' stuff, in original XSLT design there was no support for chaining transformations. Oh, those sweet days of 'Result Tree Fragment' ) When saying 'supporting a big number of XSLT transformations I'm not talking about supporting 100 'hello-world' XSLT transformations. I don't think emacs modules are as simple as 'hello-world' and if it was hard for LISP it would be still hard for XSLT, right? Rgds.Paul.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format