Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!haven!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: Rich Text and comp.sys.next
Message-ID: <1990Dec4.141122.1679@ni.umd.edu>
Date: 4 Dec 90 14:11:22 GMT
References: <130125@gore.com> <1990Dec4.045426.28457@ni.umd.edu> <12266@milton.u.washington.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland, College Park
Lines: 95
Nntp-Posting-Host: sayshell.umd.edu

In article <12266@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:

>That is, I feel that NeXT should provide this functionality as part of
>the Appkit and that application developers should not be required to
>implement custom NextStep EMACS or vi interfaces.  I don't think that
>customers should have to do NeXT's work for them in providing a basic
>functionality.

This is an interesting thought; it is, perhaps, a bit more ambitious
than I would have thought necessary for a mail application, but
certainly would be welcome.

>I would like to have a true EMACS interface in MailManager.  My
>requirements is that it:

> 1) must not depend upon any non-NeXT-supplied software (in other
>    words, I can't call the Emacs NextStep application since it is
>    not distributed by NeXT)
> 2) must be in a View in a window I own.  I allow many simultaneous
>    windows of many different types, each of which may have editing
>    going on.
> 3) must allow cut/paste between windows.  Should allow mouse-based
>    editor operations *in addition to* normal EMACS/vi/whatever.
> 4) RTF editing is nice, but not essential; it would be alright as an
>    interim measure to restrict this to fixed-width single font texts.

Good set of goals, sounds very difficult to provide without a great
deal of work.  In fact, this sounds like the basis for a fine
replacement for Edit for those Emacs weenies amoung us.  I find that
my fingers are too well trained in Emacs to make effective use of
Edit, other than to browse RTF file.  Converting from Emacs to Edit is
not an option since I use Emacs varients on *all* the other systems
that I edit text on.

>Ideally, I would like a replacement to the Text object that interacts
>with EMACS, and in which each separate invocation talks to a separate
>EMACS buffer.  Something similar should be done for vi, but I'm not a
>vi hacker so I don't know what that would entail.

The rumours that I've heard of how Emacs version 19 from the FSF will
work might make it more appropriate than the existing version of emacs, but
we'll only know that for sure once its available.

>Can we as a community get together a reasonable desiderata of what we
>need and give it to NeXT as a "must implement"?  I can't believe that
>we really want to keep on reinventing the wheel on giving users a
>decent editor interface in our applications.

This is an excellent idea.  Perhaps now that 2.0 is released and the
new hardware is on its way, they'll have time do deal with stuff like
this.

>Footnote to Mr. Mamakos: MailManager addresses the compatibility
>issues you raise.  Contact me by e-mail if you're interested.  Don't
>worry about "lip service" kinds of silliness -- MailManager works hard
>to provide function, not "cute."

Mark, I've played with earlier versions of MailManager.  I didn't use
it at the time because of the mail file format compatibility issues
that I mentioned before.  I understand that the latest version
addresses this point, and I have fetched it but have not had the time
yet to install it and give it a try.  I will definately have to do so.
I really liked what I saw before, but couldn't give up compatibility
with MH.

Perhaps we need a little discussion of what people would like to see
in a Mail application.  The reason that I hold so tightly to MH is
because of its tool based approach; many small programs to format,
display, select and manage mail messages.  MH messages are just UNIX
files, and "folders" are directories.  I have shell aliases, scripts
and other tools to help manage the dozens of messages that I receive
every day.  Without a similar capability in a visually based mail
application, my productivity goes *DOWN* rather than being improved.

That's why is suggested that mail applications have to be compatible
with existing mail storage formats.  If I can't have the extension
capabilities in the Mail application, then at least I can invoke shell
scripts and other processes to cull incoming mail, seperate it in to
multiple folder or message sequences and highlight the messages that I
MUST SEE.  Then perhaps I can use the Mail application to present them
to me a bit more pleasently.

Having little pictures of the sender doesn't really help ME all that
much; I either already know what the person looks like who works in my
organization or they are strangers and don't have any "faces" online.
Is that *really* an aid to productivity?  How about this "lip server"
that I mentioned in a previous message?  It's pretty spiffy, but
before including that in an application, there are many more critical
feature that I need, like the file inclusion capability.

The Mail application is cute and usable for a great many folks.  But
is it definately *not* a heavy duty tool usable for some of us that
deal with large volumes of mail daily as a routing part of our work.

louie