OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Re: Auto-completion in editors

[ Lists Home | Date Index | Thread Index ]

>-----Message d'origine-----
>De : Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
>Envoye : mercredi 30 janvier 2002 15:37
>A : xml-dev@lists.xml.org
>Cc : ricko@allette.com.au
>Objet : [xml-dev] Re: Auto-completion in editors


>I believe this is a situation that somewhat parallels the use 
>of IDE's in the 
>programming world.  Most experienced and highly productive 
>developers (in 
>my observations) use a decent editor (emacs, JPadPro, 
>SlickEdit, or even vi) 
>coupled with a debugger.  Graphical IDE's tend to be slow, 
>bulky and just get 
>in the way for experienced developers (having built many 
>development teams).  IDE's hold out the marketing promise of turning a 
>junior/intermediate/less experienced developer into a veteran 
>Unfortunately the marketing hype does not deliver in the real 
>world. Caveat 
>Emptor reins supreme.
>My two cents worth....
>Andrzej Jan Taramina
>Chaeron Corporation: Enterprise System Solutions

Though I hope I'm not a junior (more than ten years of programming
experience), I still find recent IDEs very interesting. I do GUI development
approx. once a year (most of the stuff I do is architectural and
server-side), so I don't give a buck for the RAD modules. But there is now a
killer feature in JBuilder, VC++, Netbeans/Forte, IDEA/J, etc. :
Intellisense/Codesense/etc, that is to say context-sensitive code
completion. I think it exists in emacs, too, but I'm not the emacs kind of

Anyway, was does matters is that there is a great, great difference between
a glorified editor with all the feature that you want (graphical editing,
etc.) and an editor that may not have bell and whistles but which goes a
step further by "understanding" the structure of your code, providing code
completion. It is even better if it provides some refactoring tools,
provided that it has crossen the Rubicon [1]. I'm still dreaming about an
editor leveraging on its knowledge of the code to provide search and replace
functionalities in the spirit of James Gosling's ace [2], but for Java or

I don't know if an editor can turn a newbie into anything other than a
newbie with an editor, but I'm sure that "intelligent" editors do increase
the productivity of their users, and that this has nothing to do with the
nice GUI and pizzaz.

It is the same for XML editors : I don't care about the magical grid display
or graphical schema editor of some tools, especially if the latter is
limited to XML Schema. But I do care about the editor giving me hints of
tags that can be inserted there (not all the tags defined in the DTD/schema,
damn !) or closing the last opened tag when I type '</', because it will
make my users, my team and me increase our productivity.

I'd love to have tools that enable me to bind a toolbar button or a key
shorcut to a particular XML transformation of the selected content (e.g.
select some text, press Ctrl+B and the selected text is surrounded by

I'd love to have helpful generic XML editors with the possibility of
configure them for special purpose (editing always the same set of document
types), then give the editor to developers or content editors and appreciate
the increase in productivity and data quality.

If there are such tools, at less than $150 per user, tell me. I'll buy it


P.S. there is another funny thing in XML editors. Some people have yet to
learn that editing XML documents with a tree interface is useful in maybe at
most 5% of the cases. It reminds me the crazy idea of people developing
calculator sofwtare by reproducing the awkward interface of desktop
calculators, yes, with the buttons appearing on screen, a stack capacity of
1 and all (an interesting alternative for Win32 is freely available at
[3])... It's not because an XML document is a tree that editing an XML
document has to be done through a tree ! It's sometimes useful, for some
very specific documents, and then again there should not be any attribute in
it, because things start to get awkward immediatly.

[1] http://www.martinfowler.com/articles/refactoringRubicon.html
[2] http://java.sun.com/people/jag/ace/ace.pdf
[3] http://www.analogx.com/contents/download/program/pcalc.htm


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS