wollman@kira.UVM.EDU (Garrett Wollman) (02/26/91)
Sorry ``YASMSF'' isn't pronounceable... I recently realized that I would be nice if the ``Explain what it is'' option in Messages (and dirinfo in cui) gave, in addition to the number of messages, some accounting of the size of the folder. For example, I recently noticed that I had two copies (different versions) of the RTF-to-ATK converter (thanks, Fred!), which were wasting quite a bit of space. While I'm at it, a slightly easier request. How about a ``GnuTranspose'' preference for text which would allow the user to select the (much more familiar) GNU convention for ^T, namely, exchange @point and @(point-1), rather that the (Gosling?) convention currently employed. For example, take the phrase "th eegret." To correct it in GNU Emacs, the flavor that everyone here knows, one would position the point at the first `e' and press ^T. ATK presently wants users to position the point after the first `e', causing no end to confusion. I imagine this should only mean adding two conditionals to whatever code implements ^T. [My sources are offline right not, so I can't be more specific than that.] -GAWollman -- Garrett A. Wollman - wollman@sadye.uvm.edu Disclaimer: I'm not even sure this represents *my* opinion, never mind UVM's, EMBA's, EMBA-CF's, or indeed anyone else's.
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (02/26/91)
Excerpts from internet.info-andrew: 25-Feb-91 Yet Another Suggested Messa.. Garrett Wollman@griffin. (1297) > I recently realized that I would be nice if the ``Explain what it is'' > option in Messages (and dirinfo in cui) gave, in addition to the number > of messages, some accounting of the size of the folder. For example, I > recently noticed that I had two copies (different versions) of the > RTF-to-ATK converter (thanks, Fred!), which were wasting quite a bit of > space. I'm not sure exactly what you mean -- do you mean the equivalent of the "du" command on the folder directory, but not recursing into subdirectories? This will be somewhat costly, as it will involve a stat call for each message in the folder, unless there's a way to do it that I'm not thinking of. > While I'm at it, a slightly easier request. How about a > ``GnuTranspose'' preference for text which would allow the user to > select the (much more familiar) GNU convention for ^T, namely, exchange > @point and @(point-1), rather that the (Gosling?) convention currently > employed. This an MIT vs CMU style issue. I believe that Bill Cattey implemented MIT-style ^T long ago, perhaps he can tell us how you can get it. (Personally, like all right-thinking people, I've long since customized Gnu Emacs to use CMU-style ^T, the way Andrew does.)
jgk@osc.COM (Joe Keane) (02/28/91)
In article <QbmKOBm4lU410Jplwb@kira.uvm.edu> wollman@kira.UVM.EDU (Garrett Wollman) writes: >I recently realized that I would be nice if the ``Explain what it is'' >option in Messages (and dirinfo in cui) gave, in addition to the number >of messages, some accounting of the size of the folder. For example, I >recently noticed that I had two copies (different versions) of the >RTF-to-ATK converter (thanks, Fred!), which were wasting quite a bit of >space. It seems like this is something you'd only want occasionally. It's fairly expensive, so maybe there should be a script which gives you this information. What i'd really like to see is a hook in AMS to support compressed message directories. I used to compress my message directories, but if i'd forget to uncompress one before appending to the folder, then it'd be in a weird state. So if AMS sees a file, say `.AMS_directory_is_compressed', then it should shell out to some script which puts the directory back the way it should be. Compressing mail works pretty well since it's most English text with some common headers. If you have rasters in your mail it doesn't work so well, since ATK raster are already sort-of compressed. >I imagine this should only mean adding two conditionals to whatever code >implements ^T. [My sources are offline right not, so I can't be more >specific than that.] I think this is better solved by rebinding than a preference option. In article <0bmatgC0M2Yt817nhd@thumper.bellcore.com> nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) writes: >(Personally, like all right-thinking people, I've long since customized >Gnu Emacs to use CMU-style ^T, the way Andrew does.) Yes, this is the second most stupid thing about GNU Emacs key bindings. The first is, of course, that backspace is the help key. Brilliant.
wjh+@ANDREW.CMU.EDU (Fred Hansen) (02/28/91)
Excerpts from internet.info-andrew: 27-Feb-91 Re: Yet Another Suggested M.. Joe Keane@decwrl.dec.com (1814) > What i'd really like to see is a hook in AMS to support compressed message > directories. I used to compress my message directories, but if i'd forget to > uncompress one before appending to the folder, then it'd be in a weird state. > So if AMS sees a file, say `.AMS_directory_is_compressed', then it should > shell out to some script which puts the directory back the way it should be. If this is really wanted, I can get it done with a simple Ness script. Fred Hansen
wjh+@ANDREW.CMU.EDU (Fred Hansen) (03/01/91)
Excerpts from andrew.kermit: > I was thinking of a shell script, but maybe a Ness script would be more > convenient. I think the important thing is to get a hook in the right place > in AMS so the uncompression can happen automatically and AMS won't notice it. My message could have been clearer. What I was proposing is Ness code to reinterpret the menu items in Messages so the shell script gets called. However, the shell script could easily be incorporated within the Ness script. Sigh. It just occurs to me that clicking on a folder name or message caption are situations where decompression might take place--and there is not a good way to intercept this in Ness. What we can intercept are the menu options "Read By Name" or any menu option which directly reads a folder. If there is enough call for it, we can add "events" to messages for clicks on folder names and these can then be intercepted appropriately with Ness code. Fred Hansen
bill@allegra.att.com (Bill Schell) (03/01/91)
I like the compressed message idea too. I would imagine that a framework to apply an arbitrary program X to X-ize and un X-ize messages in a directory could be used in a lot of ways. Encryption/decryption for example. Bill Schell AT&T Bell Labs, Murray Hill, NJ bill@allegra.att.com