This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Best tool for DocBook


I apologize if I've insulted anyone's preferred software tool set.

You may recall that what I originally said was:

> Well, Holger, it may be just that some of us find Emacs a clumsy,
> cumbersome editor. If that sounds harsh, you should hear what some of the
> other writers in my group have to say about Emacs.
>
> I actually prefer writing and editing in markup, but Emacs--even with
> psgmlx and the Windows settings--is a drag. I agree that Emacs+psgml (or
> psgmlx) offers a solution, especially for those who can't or don't want
to
> work in Windows, but I certainly wouldn't classify the combination as one
> of the "best tools for DocBook."

In response, Bob McIlvride says,

<snip Bob's history>
At first I felt crippled, like I couldn't move.  Using Emacs in
X-windows, I could still use the mouse and at least do something.  But I
soon discovered the power of the control keys, and Emacs psgml mode.
It's really fast.  By writing a few simple macros you can mark up huge
regularly formatted tables or dozens of pages of reference entries in an
hour or two.

>>>>
I would argue that (1) a good tool doesn't require the user to write a set
of macros to make it user friendly, and (2) the Emacs/psgml control key
functions are stone knives and bear skins compared to the tags-on markup
modes of XMetal and Epic.
<<<<

Bob also notes,

At the same time, using Emacs helped me change my mind set from semantic
markup to structural markup.  Could it be that some people who demand a
WYSIWYG editor for DocBook are those who haven't yet internalized this
paradigm?

>>>>
I realize Bob did not accuse me of preferring WYSIWYG editors, but I wanted
to state the point clearly. I am not claiming that emacs/psgml is clumsy
and cumbersome simply because it is not WYSIWYG. I can see that a WYSIWYG
view is useful, but I personally prefer to see the tags. Emacs/psgml offers
a tool for accomplishing this kind of editing. I am still not convinced
that Emacs/psgml offers one of *the best* tools for this.
 <<<<

Bob closes with,

Of course I frequently process my work into HTML and PDF to view it and
proofread it.  And it would be nice to be able to make text edits from
one of those views.  But for fast editing of both text and markup, I
think Emacs is a very good editor for DocBook documents.

>>>>
I can see your point, Bob, but I can't see how you can claim that
Emacs/psgml is fast in comparison with XMetal or Epic. The tag selection
and insertion methods available in XMetal and Epic are faster and more
obvious.

Greg LeBlanc responds to my post with:

I don't see where you've suggested anything better... (even just checked
the archives, and can't find anything)

>>>>
So I'm not allowed to disagree with a post without offering alternatives?

No, I had not posted an opinion. Others had already posted information on
XMetal and Epic, which would both be at the top of my best of list. I've
always considered me-too posts rather pointless. I was responding to
Holger's placement of Emacs/psgmlx in the "best of" category. I work in
Emacs with psgml, and I realize (though I do not understand) that some
people actually like working in Emacs/psgml, but I don't see how anyone can
argue that this tool is one of the "best" available for DocBook editing.
<<<<

Greg further explains:

As for Emacs+psgml...  I work with a rather large team of writers and
even the ones who have been working with DocBook using psgml for 3 or 4
years haven't learned half of the tricks with it.  More than half of
them are unaware that it can do anything other than syntax highlighting
and calling an external validation tool (well, they may know it can do
more than that, just not how to do it).  It's not so much how good your
editor is, as how good the docs for your editor are.

>>>>
I find that most software tools are only as good as their documentation and
interface. The fact that, in three or four years, most of your writers
haven't figured out half of what Emacs can do just makes my case against
Emacs. Emacs documentation is a nightmare, and the interface is thoroughly
counter-intuitive. The control and meta key functions may be powerful, but
that's over a hundred key combinations. Yes, I'm sure quite a few of the
brilliant minds on this list can spare the grey matter to store that
information, but I think those cells can be put to better use. I also don't
like Quick Reference pages cluttering up my desk.

Here's one tiny example (I can offer dozens), of the kind of problems I see
with Emacs. We put a new author on Emacs/psgml a few weeks ago, and after
going through the tutorial she couldn't figure out how to open a new
document. She's young, and she has very little UNIX experience, but she's
an intelligent woman. I grant that she may have gone through the tutorial
too quickly, but the Emacs help system is a disorganized mess. She pulled
down the *Help* menu, and she simply could not find anything that said, "To
start a new document in Emacs,...." What the tutorial actually says is,
"You can also find a file which does not already exist. This is the way to
create a file with Emacs;...." For a vi user, this makes perfect sense, to
a Windows or Mac user, it's gibberish. I'm sure this information is also
available elsewhere, but it's not clearly or readily available. (Please
don't send me notes telling me all the places I might find this
datum--that's not my point). I admit also that I'm spoiled by GUIs. I want
a button or a menu item that clearly says *New*. I also want a Help menu
that offers help. Emacs offers neither.

Dennis Grace

IBM Information Developer
(512) 838-3937  T/L 678-3937  cell: (512)-296-7830
dgrace@us.ibm.com

If you try to fail, and succeed, which have you done?



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]