NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/mail/elm/3881

Internet Message Format | 1992-12-29 | 5.2 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!gateway
From: [e-mail] (Scott Ophof)
Newsgroups: comp.mail.elm
Subject: Re: List of enhancements
Date: 29 Dec 1992 03:17:22 -0600
Organization: CS Dept, University of Texas at Austin
Lines: 118
Sender: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: cs.utexas.edu


On 28 Dec 1992 17:37:51 GMT [e-mail] (Steve Simmons) said:
>[e-mail] (Scott Ophof) writes:
...
>>What about allowing invocation of "elm" from within itself?
>Eh?  This works now.  Just a few minutes ago I was reading mail
>and needed to go look at a different folder - "!elm -f =name"
>worked fine.

Sorry.  I already "oops"ed when Syd updated me on this point in
private mail.  I probably only tried it on the same folder as I was
already accessing...


>>Unix boasts being able to be used from almost any terminal
>>imaginable.  It's strange then that no application I've come across
>>up to now realizes that when a user wants to skip straight to (say)
>>the 4th page by hitting SPACE 4 times, one still needs to wait for
>>each of those pages to be laboriously built and displayed onscreen . . .

>Yes, it's probably possible, no, probably not portably.  If you know
>of a generally available UNIX pager that does this, let me know.  I've
>never seen one.  But why hit space 4 times?  Use the message number
>commands.

Huh?  I'm referring to the built-in pager, ie. when reading an item,
not to the index display.

As a general comment, I feel that where possible, standard system
utilities should be used.  But from the (actually quite meager)
experience I have with Unix systems, I'd say that pagers with a
decent (and *friendly*) set of commands are not "standard Unix".
So IMHO it's either a question of implementing a new utility with
the required commands (Oh no!  Not *another*!), or improving the
existing facilities (much to be preferred!).


>>As to aliases, how about enhancing that facility to allow users to
>>include such things like which folder to store items in related to a
>>specific alias, phone numbers, surface addresses, user-definable
>>...
>There are a zillion of these available.

As standard Unix utility?  If so, which?  I'll grab any chance to
increase my knowledge of Unix.

>                                         Selecting any one would be
>the wrong answer for everyone else; building the facility into elm
>would be an equally bad idea.

So what about offering interfaces to the most "popular" ones?
At least to those that offer the best/friendliest user-interface and
possibilities.

>                               What would be more useful would be a
>method to (a) automaticly rebuild the elm aliases database from some
>outside utility and db format (rolo_to_elm, etc) and (b) invoke a
>general interface to rotodex utilities from inside elm.

Sounds good to me!  Again, please point me to some preferably
standard Unix utilities of this kind, and I'll find a corner to do
some quiet studying and playing around.  :-)

>                                                         Elm aliases
>are built the way they are for (a) speed and (b) reliability.  Any
>solutions which depend on outside fromats sacrifice one or both of
>those two.

Extract from that outside format what "elm" needs.  OK, so it may be
a bit slower.  So?  Index-rebuilding takes up much more time for me,
though I use aliases *very* much and try to do as much as I can
within one folder before even considering the switch to another
folder...


..[retaining the index as disk-file whenever possible]...
>Absolutely.  This is a wider problem than elm; mh and most other
>mailreaders have the same problem.  In fact, it's the same problem that
>trn and nn try to address.  It's a difficult problem but not unsolvable.
>The big issues are detecting external changes which would require the
>index be rebuilt.

Betcha that the whole concept of being able to spawn a protected
child process is one of the main sources of problems...  >;-)
Like when one does "!elm...." from within "elm".  Which could be
circumvented by allowing more than 1 item in a folder to be
accessed at any one moment.  Look on your desk; how many manuals are
open at the same time, *next* to each other?  And you don't put your
writing paper away when you pen a quick memo, do you?  :-)


>We're always looking for people willing to pitch in, send mail to
>Syd and join the developers group.

(OOPS!)  I'm not posting to the wrong group, am I?  'Cause if I am,
and comp.mail.elm is meant for bug-reports or such, then please tell
me which group I should be posting to.
As to pitching in, I'll gladly suggest and discuss enhancements to
"elm".  Even write/modify documentation to help those not used to
the Unix envir to understand "elm" and use it correctly.

BTW, a pointer to a list and description of other Unix MUAs would be
much appreciated.  If ftp-able, then please be very specific and
thorough re address and path; I can't seem to stop the dir-listing
from scrolling past relevant areas.  My PC and Unix don't seem to
like each other...  :-(

>--
>"When Dexter's on the Internet,
> can Hell be far behind?"

(um..  no comment...  >;->  )


Regards.
$$/    (F. Scott Ophof  <[e-mail]>)