[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: DreamWords [was: pipe dreams]



Harrison, Shawn wrote:
>
> Several people have expressed that such a discussion as what we would
> like in an editor *is* appropriate for the list. So here goes, for those
> who are interested. Annie might want to rev up her nifty e-mail filter at
> this point.
>
> Leslie Bialler said:
> ≪it seems to me that devising a word processor that
> emulates XyWrite when we already have XyWrite reminds me very much of
> the Borges story in which a cartographer attempts to draw a map of his
> region on a scale of 1:1.≫
>
> T. Baehr said:
> ≪ What am I missing here? ≫
>
> Very good points. Tim, your not missing much. XyWrite is an outstanding
> editing tool. In particular, it is fast, clean, easily customizable,
> powerful, and has those two marvelous features, the command line and the
> expanded/visual view modes. But Leslie, we're not just talking about
> emulating XyWrite. Here are a few thoughts about what XyWrite is missing.

Shawn:

But I believe Rafe _was_ talking about precisely that, an emulator,
and my reference to Borges was addressed to Rafe's point.

For those of you who haven't read the Borges story I offer a second
analogy: I have read somewhere that a remake of Psycho is being filmed.
This time Anne Heche gets to take the shower. This is an endeavor that,
at least to me, seems perfectly pointless, except as a way to capitalize
on the Actress of the Moment.
>

However, since _you_ have raised some interesting points, I'll
intersperse some comments below.

> 1) An interface which integrates more naturally with a GUI operating
> system.

This is precisely what Smart Words will do.

> The XyWin interface is not a fully integrated windows interface.

No.

> For instance, it is constrained to 8.3 naming.

I still believe in keeping filenames as short as possible. It's nice to
have nine or ten, from time to time; but if they get bigger than that,
you're probably not consise enough.

> The taskbar icon doesn't
> work as expected. At heart XyWrite is a DOS program.

Quite so, and many here seem to prefer that.

> The ideal editor
> would be a native GUI program, albeit with powerful command-line
> functionality available.
>
Any GUI functionality will slow down the system, I would imagine.


> 2) Cross-platform. I want to be able to use the same editing tool on
> whatever platform I happen to be working on.

Certainly.

> I don't necessarily mean the
> exact same program code should execute, as Sun would like Java to do;
> ports will do nicely. (I'm thinking of GNU Emacs, which has been ported
> everywhere -- but the interface! ugh.)

Oh? Does it have one? ;-)

> The same editing tool would also
> mean the same macro/scripting language.
>

Quite so.

> 3) Extensibility and Usability with other tools. In the dream editor you
> could create a new menu or a new set of dialog boxes with corresponding
> commands, hotkeys,

For those GUI-ers among us, yes; for the rest of us, ho hum. As for
hotkeys, maybe it's just me, but how many hotkeys can you remember?
Especially after a long day spent at the computer, which seems to cause
other parts of the brain, such as the old memory banks, to cease to
function.

> and menu-accelerator keys as easily as writing and
> running a macro. You could also very transparently run external programs
> -- other tools -- and use the results of those programs directly.

That would be nice.

> Some of
> the discussion recently has had to do with the inability to use XyDOS to
> spawn a separate DOS session.

?

> In general, it is difficult to integrate
> XyDOS with other tools. As an example, I run TeX frequently, which
> involves compiling an ASCII document with formatting into a binary file
> and then launching a viewer to look at it. I would like to be able to set
> a hotkey which does this whole sequence with one simple CTRL-t. XyDOS
> can't handle doing those things from a macro.
>

I'll bet our magnificent minister of education, Sir Robert Holmgren,
knows how to do _that_!

> 4) User-friendly macro language, with a full set of flow-control
> structures (if/then/elseif, while, for, foreach, switch, procedures which
> take arguments and return values, recursion, etc.), and the ability to
> define new commands -- to extend the macro language itself. It is
> difficult to extend XPL itself, and as powerful as it is there are some
> very unfriendly things about it.
>

Good one!

> 5) Syntax highlighting. This is a standard feature in programmer's
> editors. In the dream editor, formatting syntax would be highlighted in
> expanded mode, while the results would be shown (as in XyWrite) in
> "visual" mode. (Of course, we're talking about formatted text -- in a
> *writer's* editor. If the file is a computer program, the code would be
> highlighted using standard syntax highlighting patterns.)
>

?

> 6) Flexibility in terms of the underlying formatting tags. I would like
> an editor in which you could define new sets of tags for it to use in
> creating its onscreen formatting. So that, if you choose "HTML format,"
> it'll create text which is formatted as an HTML file -- the underlying
> formatting tags are HTML markup -- but you see the results, as in a web
> browser.

Sounds good to me.

> If in a different document you specify "TeX format," and it'll
> use TeX formatting tags and show you results.

Ditto!

> You could also define a set
> of tags according to an SGML DTD, or even a "Xy format," which reads,
> displays, and edits XyWrite documents naturally.

Nice.

> Combine this with
> expanded/visual view modes (available in no other editor but XyWrite so
> far), and you've got a powerful tool for directly editing files with
> various formatting/markup languages. In XyWrite presently, or in most any
> other editor, I can create sets of key-bindings for other formatting
> languages. But there isn't an editor available in which I can specify the
> formatting tags that the editor will use to generate what I see in
> "visual" mode. This great feature would not be impossible, as it may
> sound (I can think of how to do it in Tool Command Language (Tcl), for
> instance).
>
?

> 7) Background running of macros. I'd like to be able to edit a file with
> a macro without having to see it happening, or even to wait for it while
> it happens. -- a multi-tasking editor (that should really be another
> item).
>

Well, yeah: but sometimes there are times I _want_ to see it happen,
just to make sure it's not doing something unexpected.

> 8) Able to be used in a non-interactive manner. I'd like to be able to
> tell the operating system "edit  " and have it run my
> editor in the background and perform the  on whatever  or
>  I have specified. I imagine this function is related to
> the previous one.
>

Quite possibly. I couldn't say.

> 9) Open source. With openly available sources, those power users who want
> to extend the program (people like Robert, Annie, and Tim) could easily
> do so -- they could get into the guts of the thing and change it if they
> wanted to. They wouldn't have to overlay patches on something that is not
> satisfactory -- they could rewrite it! No need any longer for frustration
> that the people who own the software aren't responsive to the requests of
> its users. No more grumbling about TTG or anyone else. If you want a
> feature, you can write it. That is the intrigue of the software
> development process that open source software generates. I have
> benefitted very much from the open source software that is available.
>

I'm cool with that.

> There are a lot of editors available, and several of them come close to
> this wish list. But none of them gets the prize. TextPad is an
> outstanding editor for some purposes. XyWrite is still the best for
> day-to-day work, in terms of its mix of power and features. NoteTab has a
> great user interface. I would love to be able to take one of those
> editors as a starting place and build on it --- why should I reinvent the
> wheel? But the sources are not available, so neither I nor anyone else
> (except the editors' owners) can do that.
>

Noted.



--
Leslie Bialler
Columbia University Press
lb136@xxxxxxxx