[
Lists Home |
Date Index |
Thread Index
]
> 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 sucks 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 sucks 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.
|
