Lists Home |
Date Index |
On Fri, 2004-04-09 at 18:49, Amelia A Lewis wrote:
> On Fri, Apr 09, 2004 at 05:08:37PM +0200, Henrik Martensson wrote:
> >I do agree that something like that would be annoying. But I would not
> >consider an editor that allows malformed tags like that to be a real XML
> >editor at all. It is a text editor with XML syntax highlighting, which
> Oh, horsefeathers. You're either not reading what I'm writing, or not
> understanding how and why it works, or so involved in strait-jacket editors
> that you can't imagine any other use case. As it happens, that's behavior
> I've seen repeatedly. It's because my fingers keep typing to the end of the
> thought, whether the stupid software is inserting something or not.
> If I type element attribute, some editors will insert ="", either not moving
> the caret, or placing it between the added quotes. If I'm typing at speed,
> this likely means <element attribute="="value" >" by the time I finish
> typing what I meant to type.
With a "straitjacket" editor, you would not have that problem. Let's
look at the character sequence required to create a document fragment
XMetaL has the following escape sequences:
<ctrl>+i - Move focus to the element window
<f6> - Move focus to the attribute window
and we get:
<ctrl>+i l <return> <f6> o <return> <ctrl>+i l <return> f i r s t
Or, if I have configured the system to use ordered lists by default, and
to have at least one item in a list:
<ctrl>+i l <return> f i r s t
Either way, I can type as fast as I want, or am able to, and the editor
will never mess up the markup. With Publisher, the escape sequences
would be different, but the same principle applies.
> I don't know how you expect an editor to prevent this. If I get to <element
> attribute="=" (I've just typed my open quote, which it considers a close
> quote), is it supposed to recognize that I've typed over something that it
> typed in? Interesting if so; should it also identify attribute= " and
> attribute = " and attribute =" ? (spacing variants). If not, how am I ever
> going to put the symbol "=" into an attribute?
We are talking about software that use very different models for
entering data. I am not using a text editor, so I have no need to enter
markup character by character.
I never need to enter an opening or closing quote. I do not enter the
I do not edit attributes inline, or even see them inline. (Unless I
configure the editor that way.)
> The same thing happens at the end of an element. I type </element>, but
> because it's auto-completing, I get </element>element>. Doesn't matter
> whether it's moved the caret after its inserted element> or whether it left
> the caret after the /, I get the same effect.
I don't type end tags. Inserting them is the job of the editor, and the
editor creates the end tag when it creates the start tag. Therefore, I
do not have the same problem.
> If I'm to believe that a "real XML editor" would not permit this, how does
> it stop it? Lock up and refuse to let me enter text at the point that it's
> decided that it has already finished typing for me?
No. The editor does not stop you from entering text. It does stop you
from messing up the markup. These are different things.
> If that's a real editor, I don't want one. I want an editor that lets me
> use my knowledge, and if the editor's author is determined to believe that
> they know more about my documents than I do, then they can go find different
> customers. I'll send them to you, if you like.
You wrote that you have a problem with markup that gets trashed. I am
merely pointing out that with a better editor, there would be no trashed
markup, no matter what your typing speed.
> >is a different thing. (Just as a text editor with RTF or MIF
> >highlighting would not be a word processor.)
> >> typing. Give me a key to tap on if I need help. *However*, several of my
> >> colleagues absolutely cannot comprehend this attitude, and profess
> >> themselves unable to survive without automatic code-completion sorts of
> >> facilities (most of them type slow, too, she sneered).
> >My favourite XML editor has code completion, but creating a malformed or
> >otherwise messed up tag is impossible.
> Do you actually type at speed, including markup and content together? Or do
> you expect to pause at every markup boundary? Perhaps that's the
I am not a very fast typist, but the software can handle typists much
faster than I am with no problem at all. And I do not stop at markup
boundaries, at least not for reasons connected with the markup. Why
should I? (When I do stop, it is to consider what I am going to write,
and how to express myself.)
> difference. I fail to see the point of "markup" based on binary insertions
> that require alt-cokebottle-meta-shift-infinity; it's *text-based*. I can
> handle typing text, thanks very much. Markup is just certain kinds of text.
Learning a few control sequences in return for always having correct
markup is a very good tradeoff. For features that are used less often,
there is always the mouse and menus.
You yourself pointed out that the markup gets trashed, so obviously you
can't handle typing text. At least not without turning off the features
that are provided to give you, among other things, the typing speed you
say you want.
Are you really arguing that because XML is text based, markup must be
handled character by character? That does not hold. PDF, RTF and MIF
markup are also text. So is Postscript for that matter. If XML markup
should be handled character by character because it is text, it follows
that those other text formats should be edited in text editors too.
> My fingers are trained to stuff in certain forms of markup without
> interacting with my brain, and typically without looking at either the
Perhaps you should try connecting your fingers with your brain when you
write sometimes. You might be surprised at the improvement, XML editor
or no XML editor.
> keyboard or the screen. If there's some automated completion happening in
> the middle of this, it is *not* making my life easier, it's a close
> approximation to hell, and that is *not* my idea of what a "real xml editor"
> is supposed to do.
That is because you are making erroneous assumptions. You assume that
you must enter elements and attributes character by character. You
assume that you have to enter end tags yourself.
In reality, you do not. It is just the way your particular editor
happens to work. There are other ways. Some are better, some are worse.
> BTW, I switch fairly freely between "document-oriented" and "data-oriented"
> styles, depending upon need (and I've got the xhtml dtd printed on the
> insides of my retinas, I think, since it doesn't require any lookup; xmlspec
> dtd and parts of docbook as well).
I find it odd that you are prepared to learn several DTDs by heart, and
yet balk at learning two or three control sequences so that you can
improve your efficiency when using an XML editor, and get rid of most
tagging mistakes as a bonus.
> I want my editor to highlight mistakes
> (like <element attribute="="value> and </element>element>, if I happen to
Given a choice between not making a mistake, and making the mistake but
being given a hint about it so that you can find it and correct it
afterwards, you choose the latter.
I prefer the former.
> somehow type in something that awful (usually, what they catch are missing
> >, missing / in a close, and missing " in attributes), and to give me
> validation advice when asked for. I like it if I can type </[some-key] and
> get a proper close tag, although I forget that half the time if I'm in the
> flow. I do not, not, not, not *ever* want an editor to decide to change
So, you trash half the markup by forgetting end tags. Since you
sometimes trash a start tag too, that evens out to a bit more than half
the time, at least when you are in the flow, i.e. when you are doing
your best writing, and everything goes smoothly.
Do not those trashed tags interrupt the flow?
I wouldn't know, because I do not mess up my markup the way you do,
ever. (There are other ways, of course. Pobody is nerfect.) I suspect
though, that when I am "in the flow" I can remain there a longer than
you, not by virtue of being a better writer, but simply because I have a
writing tool that prevents that kind of mistakes being made in the first
If you do write faster and better than I do (which is quite possible, of
course, especially given my somewhat sedate typing speed), imagine how
much better you would do if you never had to worry about correcting a
misspelled element name, fix a broken attribute, or skip back a bit to
enter a forgotten end tag.
> *anything* in my document *at all* unless I have explicitly pressed a key,
> or clicked a button, for which the contract is: "you know more than I do,
> fix it." In general and as a rule of thumb to be printed on the foreheads
> of everyone related to programmers writing an editor: "You do not know more
> about a document than its author does."
The programmer wouldn't know more about the document. However, the
programmer is expected to know more about editing XML, and about GUIs,
and about human-computer interaction.
The purpose of XML is to enable as much automation as possible. Using a
text editor to write XML documents is missing the point of using XML in
the first place!
I do not think we will come to an agreement in this thread. However, I
do have a suggestion:
I use several different XML editors, of widely different types: Komodo
for XSLT, an Eclipse plugin for Ant, XMetaL for general purpose XML
editing. In addition I have used, or at least tried, older SGML/XML
editors, such as WP (with the plugin of course), and Documentor, as well
as more modern offerings like oXygen and XMLBuddy.
Why don't you do the same thing: try one of the "straightjacket" editors
for awhile. I recommend XMetaL. I think there is a 30 day demo
available. It is very different from what you are used to, so you
probably won't like it at first, but give it two or three weeks anyway.
I think you would grow to like the editing features. XMetaL isn't
perfect, by a long shot, and switching editors will always mean making
tradeoffs of some kind. However, I think you might come to agree that
there is a great deal of worth in the approach XMetaL takes to editing
XML documents, even if you personally decide not to switch over.