iwelch@agsm.ucla.edu (Ivo Welch) (11/05/90)
Subject: MailManager Summary: Expires: Sender: Followup-To: Distribution: Organization: UCLA, Anderson Graduate School Of Management Keywords: MailManager Omissions I have recently pulled MailManager from purdue. It is a great program, but misses one or two features sorely. Particularly, I miss the ability to transfer a set of messages from the current mailbox (or Inbox) to another mailbox by simply clicking on the list of other mailboxes that I had to pre-select anyway. Instead of giving the list of mailboxes, transfer/move appears to want me to type in the path and name of the file. Is there a way for transfer/move/copy to prompt the list of mailboxes? (or is there a newer version?) Another omission is Emacs-type elementary editing. I wish I could type c-f, c-b, c-n, and a bunch of other elementary editing characters. Does anybody have a fix for this? Finally, a minor curiosity is that the recipient name of a message requires a CR at the end. Incidentally, does anybody know how MM keeps track of what messages have been read, answered to, etc. ? /ivo welch ivo@next.agsm.ucla.edu
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (11/05/90)
In article <670@mara.cognet.ucla.edu> iwelch@agsm.ucla.edu (Ivo Welch) writes: >I have recently pulled MailManager from purdue. It is a great program Thank you for your comments. By the way, the official repository of MailManager and friends is on FTPHOST.CAC.WASHINGTON.EDU (IP address 128.95.112.1) via anonymous FTP under the "imap" directory. >but >misses one or two features sorely. > >Particularly, I miss the ability to transfer a set of messages from the >current mailbox (or Inbox) to another mailbox by simply clicking on the list >of other mailboxes that I had to pre-select anyway. Instead of giving the >list of mailboxes, transfer/move appears to want me to type in the path and >name of the file. Is there a way for transfer/move/copy to prompt the list >of mailboxes? (or is there a newer version?) This is something that is on the list of things to implement in the future. The problem is that MailManager supports much more than local mailboxes; it also supports remote mailboxes via the IMAP protocol. There are two general "destinations" for a message in a copy/move operation -- another mailbox on the same machine the mailbox is on (a proxy copy/move via IMAP) or a mailbox on the local machine. The underlying push in MailManager was support for remote mailboxes, since a personal workstation is generally a terrible place to store mail or any other backup-critical data (how many of you back up your NeXTs with any regularity?). The problem is that to do things right, you have to allow transfer from a remote mailbox to another remote mailbox, perhaps on an entirely different machine! I don't believe in half-assed solutions that only handle one specific aspect of the problem. This will exist in the future, as a full functionality. >Another omission is Emacs-type elementary editing. I wish I could type c-f, >c-b, c-n, and a bunch of other elementary editing characters. Does anybody >have a fix for this? I have been asking NeXT for a long long time to support VI and EMACS within Text objects. I consider this to be an Application Kit missing feature. I consider it to be wrong for every single program to implement its own EMACS emulator (or interface into EMACS) with its own pecularities. Also, doing an EMACS interface without a VI one is bound to annoy VI fanatics, and vice versa. Help me by bugging NeXT to put a general editor interface into Text objects! >Finally, a minor curiosity is that the recipient name of a message requires a >CR at the end. In composing a message, you are entering text into a TextField object. This is an object that receives text and upon activation with RETURN or TAB passes it to a parser. The parser examines the text in the field, replaces the current data structure for that field with the parsed results of the new text, and writes back an reversed-parse version of those structures into the field. You will notice that what you type in is not what is ultimately generated (e.g. host-less addresses have the host name filled in). >Incidentally, does anybody know how MM keeps track of what >messages have been read, answered to, etc. ? MailManager, EasyMail, MacMS, MS, Pine, and other components of the IMAP family of mailers maintain a set of flags associated with each message. The exact form of these flags depends upon the type of mailbox: . For IMAP mailboxes, it is a function of the server. However, all IMAP servers support the \Recent, \Seen, \Flagged, \Deleted, and \Answered flags. . For /usr/spool/mail/$USER (Berkeley format) mailboxes, the R and O flags of the Status: line are used (compatible with /usr/ucb/Mail) along with DAF fields of an X-Status: line used by IMAPware. . For ~$USER/mail.txt (Tenex format) mailboxes, flags are stored in the out-of-band flags field of the message in a compatible way to the MM style programs used on DEC-20's, VAX/VMS with Multinet, and Columbia MM for Unix. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin." /|\ | |/\| _______ / \ MRC@CAC.Washington.EDU "Iie, boku ha nihonjin." / | \ | |__| / \ / \ Lumchan ga suki ja!! "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (11/05/90)
A major new release of MailManager (and the rest of the IMAP software
package) will be made available sometime between now and the end of
the year.
The major functional change in this new version is support for file
attachments using the encoding scheme described in RFC-1154. You can
now mail binary or other files other than pure 7bit text -- e.g. Frame
documents, RTF files, InterfaceBuilder NIB files, executables(!).
This new version also has some extensive internal changes, including a
rewrite to the /usr/spool/mail/$USER file reading logic to work around
a serious NeXT NFS bug which causes damage to NFS-mounted mail files
(basically, you get nulls instead of data when new mail comes in --
details on request).
A beta test version of the new MailManager only is available for FTP
as imap/MailManager.new on FTPHOST.CAC.WASHINGTON.EDU. Although this
version is what I am presently running on my machine and is believed
to be working and bug-free, I must emphasize that it is beta test and
not yet formally blessed for distribution or use in our community.
Along with this new release will be a new release of IMAPware,
including support for attachments in the C-client and POP2/POP3
servers that can act as IMAP clients -- thus allowing the use of POP
clients with IMAP servers using these servers as POP/IMAP converters.
The release is presently awaiting final testing of the beta test
MailManager and the completion of a new IMAP server which supports
attachments.
_____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
_|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?"
|_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin."
--|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin."
/|\ | |/\| _______ / \ MRC@CAC.Washington.EDU "Iie, boku ha nihonjin."
/ | \ | |__| / \ / \ Lumchan ga suki ja!! "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.dennisg@kgw2.bwi.WEC.COM (Dennis Glatting) (11/05/90)
In article <10577@milton.u.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: |> In article <670@mara.cognet.ucla.edu> iwelch@agsm.ucla.edu (Ivo Welch) writes: |> >I have recently pulled MailManager from purdue. It is a great program |> |> |> I have been asking NeXT for a long long time to support VI and EMACS |> within Text objects. I consider this to be an Application Kit missing |> feature. I consider it to be wrong for every single program to |> implement its own EMACS emulator (or interface into EMACS) with its |> own pecularities. Also, doing an EMACS interface without a VI one is |> bound to annoy VI fanatics, and vice versa. |> |> Help me by bugging NeXT to put a general editor interface into Text |> objects! why don't you just write one? subclass Text or create an new object. call it TermcapText. -- ..!uunet!kgw2!dennisg | Dennis P. Glatting dennisg@kgw2.bwi.WEC.COM | X2NeXT developer
pclark@SRC.Honeywell.COM (Peter Clark) (11/06/90)
>|> In article <670@mara.cognet.ucla.edu> iwelch@agsm.ucla.edu (Ivo Welch) writes: >|> I have been asking NeXT for a long long time to support VI and EMACS >|> within Text objects. I consider this to be an Application Kit missing >|> feature. I consider it to be wrong for every single program to >|> implement its own EMACS emulator (or interface into EMACS) with its >|> ... >|> Help me by bugging NeXT to put a general editor interface into Text >|> objects! > > why don't you just write one? subclass Text or create an new object. call >it TermcapText. > I believe that some emacs keybindings (basic ones, like ctrl-f, ctrl-b, etc...) are part of the 2.0 Text object. Pete Clark
declan@romulus.rutgers.edu (Declan McCullagh/LZ) (11/06/90)
In article <1990Nov5.204606.11740@src.honeywell.com>, pclark@SRC.Honeywell.COM (Peter Clark) writes: >I believe that some emacs keybindings (basic ones, like ctrl-f, >ctrl-b, etc...) are part of the 2.0 Text object. > >Pete Clark Edit has a fairly complete set of keybindings now, but I can't seem to find any in the vanilla RTF object (Ctrl-Y does select all the text in that object, though). -Declan -------------------------------------------------------------------- Declan McCullagh / NeXT Campus Consultant \ declan@remus.rutgers.edu --------------------------------------------------------------------
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (11/06/90)
In article <1873@kgw2.bwi.WEC.COM> dennisg@kgw2.bwi.WEC.COM writes: > >In article <10577@milton.u.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >|> I have been asking NeXT for a long long time to support VI and EMACS >|> within Text objects. I consider this to be an Application Kit missing >|> feature. I consider it to be wrong for every single program to >|> implement its own EMACS emulator (or interface into EMACS) with its >|> own pecularities. Also, doing an EMACS interface without a VI one is >|> bound to annoy VI fanatics, and vice versa. > > why don't you just write one? subclass Text or create an new object. call >it TermcapText. Please re-read my paragraph, and in particular the third sentence -- the one beginning with "I consider it to be wrong for every single program..." _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin." /|\ | |/\| _______ / \ MRC@CAC.Washington.EDU "Iie, boku ha nihonjin." / | \ | |__| / \ / \ Lumchan ga suki ja!! "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
dan@gacvx2.gac.edu (11/06/90)
In article <10625@milton.u.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > In article <1873@kgw2.bwi.WEC.COM> dennisg@kgw2.bwi.WEC.COM writes: >> >>In article <10577@milton.u.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >>|> I have been asking NeXT for a long long time to support VI and EMACS >>|> within Text objects. I consider this to be an Application Kit missing >>|> feature. I consider it to be wrong for every single program to >>|> implement its own EMACS emulator (or interface into EMACS) with its >>|> own pecularities. Also, doing an EMACS interface without a VI one is >>|> bound to annoy VI fanatics, and vice versa. >> >> why don't you just write one? subclass Text or create an new object. call >>it TermcapText. > > Please re-read my paragraph, and in particular the third sentence -- > the one beginning with "I consider it to be wrong for every single > program..." You could be doing the whole NeXT programming community a favor by writing a good text object (well only if you stick it on an FTP site when you are done.) The whole point of object oriented programming is the reusability of code. Once you have written a good text object, you can use it in all your programs. It is not a matter of every single program implementing its own text object, unless someone writes a good one and makes it available, it is a matter of every programmer implementing his/her own. Before you start, check out the text object in 2.0 it may be what you want. Your local sales office should be able to arrange a demo. -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)931-7596
rca@cs.brown.edu (Ronald C.F. Antony) (11/12/90)
In article <10625@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >In article <1873@kgw2.bwi.WEC.COM> dennisg@kgw2.bwi.WEC.COM writes: >> >>In article <10577@milton.u.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >>|> feature. I consider it to be wrong for every single program to >>|> implement its own EMACS emulator (or interface into EMACS) with its >> why don't you just write one? subclass Text or create an new object. call >>it TermcapText. >Please re-read my paragraph, and in particular the third sentence -- >the one beginning with "I consider it to be wrong for every single >program..." Can you spell PD like in PD software? If you write the object and put it into the archives not every single program hast to... Just in case you have some spare time :-) Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Bernhard Shaw | rca@cs.brown.edu or antony@browncog.bitnet