Re: Text processor

[Tim Allen <timallen godzilla zeta org au>]

On Sun, 20 Jun 1999, sungod wrote:

> Well, see, look at that: you've gone and offended us AGAIN in the very 
> process of apologizing!

<snip rightful ticking off>

OK, I don't agree with that.

I'm a computer science student, second year. Been using Linux for most of
that time, and things are pretty functional. Personally, I'm a vi fan. For
email, code, usenet, occasional essays, HTML, that kind of thing, it
rocks. 

However, this author whose name has currently slipped my mind is asking
for a different category of editor - one for structured text & long
documents. We're talking articles, thesies, research papers, legal
documents, that kind of thing. Documents with a lot of structure. The kind
of thing LaTeX is good at. Now, if you got a 50,000 word legal document
and were asked to start moving the sections into a more logical order,
wouldn't you like to have some kind of document outline, a tree structure,
do play around with, drag and drop, instead of having to race around the
document with cut and paste? Well, I certainly would.

vi and emacs are programmers' editors in that they excel in having one big
homogenous buffer for text, and maniupulating it. This is good for code
(including HTML), config files, and stuff like that. But communicative
text is a different idea. You don't run into the differences with just
email & usenet & short stories, but you do when you get to the kind of
document styles this guy is trying to make.

AFAI can tell, he doesn't want to specify formatting, he doesn't want to
muck with codes, he doesn't care about internal representation. The
*structure* is almighty.

The interface, be it vi, emacs, lyx, or whatever else, is unimportant.
These suggestions of "You want user friendly? Learn emacs, then it'll be
friendly to you" aren't useful because they don't address the problem.

Once we define the problem ("structured text management"), we can get
around to hacking on it. Note that implementation and user interface are
seperate issues. We could extend emacs, write our own new editor, store as
XML/SGML, store as pickled Python objects, have a tree view, have a
3D-oesophagus-navigation view, anything.

Just accept that for what he wants to do, native vi or emacs doesn't cut
it.

Personally, If I were doing this, I'd have an editor window (with vi or
emacs keybindings) which contains all or a selected subportion of the text
(depending on memory/speed issues), and a "treeview" window as well -
think like the tree/directory view in gmc. Edit text, have your outline
beside you. Drag and drop sections around. Drag a paragraph in the editor
onto a heading in the outline, and it's moved there. Each section has a
heading - when you make a new section, the first paragraph you type is
marked as the heading, the rest are body text. That kind of thing.

Then, when the document is nicely sorted, export to RTF, Word, HTML,
LaTeX, and hack the code and insert pictures and the like.. OK, maybe we
should put that kind of thing (.ps file insertion?) into the editor, but
that makes it more complex...

Stream of consciousness mode off. Sheesh.

Tim Allen