HDTenEightyP/NetNews huggingface dataset:
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: emacs info
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 16 Dec 1992 14:12:00 GMT

In emacs 18.59 info New Commands node this sentence:

`M-x super-apropos'
     This command is like `apropos' except that it searches for a
     regular expression instead of merely a substring.

does not make clear if the `merely' refers to the emacs 18 apropos
command--in which case the statement is false--or to the emacs 19
apropos command--in which case a sentence for the new apropos command
is also needed.

Newsgroups: gnu.emacs.bug
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: mail-send incorrectly resets modified status
Organization: Martin Marietta Western Internal Systems, Technical Operations
Distribution: gnu
Date: Wed, 16 Dec 1992 16:52:32 GMT

In article <1810@idacrd.UUCP> desj@idacrd.UUCP (David desJardins) writes:
>Emacs mail-mode uses the modified bit to determine whether the message
>being composed has been sent.  However, this generates incorrect
>behavior when the buffer is visiting a file.
>
>Visit a file, and type M-x mail-mode to enter mail mode.  Now type some
>text into the buffer (in the format of an emacs mail message), and type
>C-c C-s (mail-send).  The message will be mailed, and the buffer status
>will be toggled to unmodified, even though the contents of the buffer do
>not match the file on disk.
>
>I would find either of the following solutions acceptable:
>
>   (1) If the buffer is visiting a file, mail-send does not clear the
>       modified bit.
>
>   (2) If the buffer is visiting a file, mail-send saves the file.

Or both:

  (if buffer-file-name
      (if (or noninteractive
	      (y-or-n-p (format "Save file %s? " buffer-file-name)))
	  (save-buffer))
    (set-buffer-modified-p nil))
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!

Newsgroups: gnu.emacs.bug
From: desj@idacrd.UUCP (David desJardins)
Subject: mail-send incorrectly resets modified status
Organization: IDA Center for Communications Research, Princeton
Distribution: gnu
Date: Mon, 14 Dec 1992 04:41:35 GMT

Emacs mail-mode uses the modified bit to determine whether the message
being composed has been sent.  However, this generates incorrect
behavior when the buffer is visiting a file.

Visit a file, and type M-x mail-mode to enter mail mode.  Now type some
text into the buffer (in the format of an emacs mail message), and type
C-c C-s (mail-send).  The message will be mailed, and the buffer status
will be toggled to unmodified, even though the contents of the buffer do
not match the file on disk.

I would find either of the following solutions acceptable:

   (1) If the buffer is visiting a file, mail-send does not clear the
       modified bit.

   (2) If the buffer is visiting a file, mail-send saves the file.

                                        David desJardins

Newsgroups: gnu.emacs.bug
From: pereira@sgiharrar.research.ATt.COM (Fernando Pereira)
Subject: SGI Emacs subshell bug
Reply-To: pereira@research.research.att.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Dec 1992 13:56:41 GMT

When running Emacs 18.59 in shell mode on a SGI Indigo (IRIX version
4.0.5F), often (but not always) interactive programs executed from the
subshell will not operate correctly. More specifically, prompts will
not appear and a C-c C-d will exit the subshell instead of just
exiting the program running under the subshell. Here is an example. A
fresh Emacs was started, with no .emacs file. The following key
sequence was pressed:

	M-x shell RET sh RET date C-c C-d

The following appeared on the *shell* buffer

	sgiharrar:pereira$ sh
	date
	Mon Dec 14 18:40:17 EST 1992
	sgiharrar:pereira$ 

	Process shell finished

The mode line showed "run" status for the subshell until the C-c C-d
was typed, and afterwards "no process" status.

When an Emacs invocation starts behaving this way, it seems to
continue doing the same for subsequent subshells. When it does not,
subshells behave normally. The problem occurs with any of "sh", "csh"
and "ksh" as shell.

Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, PO Box 636
Murray Hill, NJ 07974-0636
pereira@research.att.com


Newsgroups: gnu.emacs.bug
From: dodd@roebling.poly.edu (Lawrence R. Dodd)
Subject: typo (?) in emacs-18.59 info pages
Reply-To: dodd@roebling.poly.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Dec 1992 05:15:13 GMT

GNU Emacs 18.59.3 of Mon Nov  2 1992 on roebling (berkeley-unix)

In the node `Version Headers' (in `Version Control' in `Version 19 Antenews')
in the info pages for emacs v18.59, I think `$ld$' should be `$Id$' (?)

diff -cv emacs.texi.~1~ emacs.texi
GNU diff version 2.0
*** emacs.texi.~1~	Fri Oct 30 20:22:07 1992
--- emacs.texi		Sun Dec 13 10:09:26 1992
***************
*** 16906,16912 ****
  
  @vindex vc-header-string @r{(V19)}
  @c ??? Currently the name is vc-header-strings
! The default header string is @samp{$ld$} for RCS and @samp{%W%} for
  SCCS.  You can specify other headers to insert by setting the variable
  @code{vc-header-string}.  Its value (if non-@code{nil}) should be the
  string to be inserted.  You can also specify a list of strings; then
--- 16906,16912 ----
  
  @vindex vc-header-string @r{(V19)}
  @c ??? Currently the name is vc-header-strings
! The default header string is @samp{$Id$} for RCS and @samp{%W%} for
  SCCS.  You can specify other headers to insert by setting the variable
  @code{vc-header-string}.  Its value (if non-@code{nil}) should be the
  string to be inserted.  You can also specify a list of strings; then
From: harley@shr.dec.com (Harley Privitera)
Newsgroups: gnu.emacs.vms
Subject: Re: EMACS on ALPHA ?
Date: 17 Dec 92 16:43:21
Organization: Digital Equipment Corporation
Reply-To: harley@shr.dec.com (Harley Privitera)
NNTP-Posting-Host: alphabits.shr.dec.com
In-reply-to: larry@eco.twg.com's message of Thu, 17 Dec 92 03:55:53 GMT

I dunno about VMS, but I'm posting this from a DEC 4000 system running
OSF/1 AXP.

/harley
--
Harley Privitera			Internet: harley@shr.dec.com
Digital Equipment Corp.			UUCP:     ...!decwrl!shr.dec.com!harley
333 South St				Voice:	  (508) 841-2087
Shrewsbury, MA 01545-4112		#include  std.disclaimer

	2020DELTA2030ALPHA2040JSYS2050MOLSEN2060HIKE
Newsgroups: gnu.emacs.vms
From: LEVITTE@e.kth.se (Richard Levitte)
Subject: Re: Annoying problem with 18.58 on VMS 5.5; can it be fixed?
Organization: Department of TeleTransmission Theory
Date: Sun, 20 Dec 1992 23:13:19 GMT

>>>>> On Fri, 18 Dec 92 14:17:05 GMT, stevef@bony1.bony.com (Steve Faiwiszewski) said:

SF> In article <BzD9vv.440@world.std.com> dwh@world.std.com (Denis W Haskin) writes:
>I've built and installed Gnu Emacs 18.58 on a VMS 5.5 system and it is
>mostly working alright, with one minor but fairly annoying problem.
>
>It appears that Emacs isn't keeping up with keystrokes, and if I use the
>arrow keys (i.e. multi-byte keystrokes) at any decent speed, it
>misinterprets them and I get garbage, including deleted text, inserted
>text, random capitalizations, etc.


SF> The problem manifests itself mostly when Emacs is used via vt tubes
SF> (vt220, 240, 320, etc.) which are connected thru DEC terminal servers.
SF> But, I've seen Emacs dropping keys even when running as an X11 client.
SF> Whenever it drops a key when run under X11 it will issue a beep (so
SF> I notice right away and thus it's not so bad), which makes me wonder
SF> how it "knows" it lost a key, and if it does, why can't it just keep
SF> up.

Emacs does NOT know... And does NOT beep. This is done by the whatever server.

I got another suggestion. Keys are fetched by Emacs using ASTs. If you type
fast, you might get more active ASTs than you process' ASTLIM. The answer
might be to increase ASTLIM, either on per-user basis, or by increasing
PQL_MASTLM in SYSGEN.

SF> I always hoped that later versions will correct that.  I see that as
SF> of 18.58 it's still a problem. :-(

I have the same problem. I haven't tried the ASTLIM thingy... it's just
a theory so far.

>Actually, while we're at it, I find that my 'forward session' character
>for the terminal server also comes in and out of commission when I use
>Emacs; that is, Emacs seems to disable it.  Any ideas here?

True, Emacs switches the terminal to PASTHRU.

--
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, System manager         ! tel: int+46-8-790 64 23           !
! Royal Institute of Technology           ! fax: int+46-8-791 76 54           !
! Department of Telecommunication Theory  ! Internet: richard@ttt.kth.se      !
! S-100 44 Stockholm, Sweden              !                                   !
!-----------------------------------------------------------------------------!
Newsgroups: gnu.emacs.vms
From: mcgee@travel.mot.com (Randy McGee)
Subject: Re: Annoying problem with 18.58 on VMS 5.5; can it be fixed?
Reply-To: Randy_McGee@EMail.Mot.Com
Organization: Motorola
Date: Thu, 17 Dec 1992 21:01:23 GMT


In article <BzD9vv.440@world.std.com>, dwh@world.std.com (Denis W
Haskin) writes:
>Actually, while we're at it, I find that my 'forward session'
>character
>for the terminal server also comes in and out of commission when I use
>Emacs; that is, Emacs seems to disable it.  Any ideas here?

If your terminal server works the same as a DECserver 300, then I would guess
that Emacs is turning pasthru or passall mode on and off. I haven't used Emacs
on VMS in years, but the version I used put the terminal in passall mode for 
the duration of the Emacs session.

---
Randy_McGee@EMail.Mot.Com
Motorola CIO Distributed Systems Support Group
From: LEVITTE@e.kth.se (Richard Levitte)
Newsgroups: gnu.emacs.vms
Subject: Re: EMACS 18.59 installation problem
Date: 20 Dec 92 22:59:29 GMT
Distribution: gnu
Organization: Department of TeleTransmission Theory

>>>>> On 16 Dec 92 13:05:36, rid@nta.no (Robert I Danielsen) said:

RID> Hello everyone,

RID> I'm trying to get emacs-18.59 up on a VAX with VMS 5.5.
RID> I've followed the installation procedures, and I've managed to compile
RID> and link. When I run BUILD.COM which runs temacs.exe and dumps temacs.dump
RID> I get an error when temacs loads the Lisp files:

RID>   . 
RID>   .
RID>   Loading c-mode...
RID>   Loading isearch...
RID>   Loading replace...
RID>   Pure Lisp storage exhausted

Look in MALLOC.C. VMS_ALLOCATION_SIZE probably needs to be increased.

If that's not the case, try increasing PURESIZE inf CONFIG.H

--
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, System manager         ! tel: int+46-8-790 64 23           !
! Royal Institute of Technology           ! fax: int+46-8-791 76 54           !
! Department of Telecommunication Theory  ! Internet: richard@ttt.kth.se      !
! S-100 44 Stockholm, Sweden              !                                   !
!-----------------------------------------------------------------------------!
Newsgroups: gnu.emacs.vms
From: dwh@world.std.com (Denis W Haskin)
Subject: Annoying problem with 18.58 on VMS 5.5; can it be fixed?
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 16 Dec 1992 19:23:53 GMT

I've built and installed Gnu Emacs 18.58 on a VMS 5.5 system and it is
mostly working alright, with one minor but fairly annoying problem.

It appears that Emacs isn't keeping up with keystrokes, and if I use the
arrow keys (i.e. multi-byte keystrokes) at any decent speed, it
misinterprets them and I get garbage, including deleted text, inserted
text, random capitalizations, etc.

If I;m careful about not using the arrow keys too quickly, things are
generally alright, but it is very sensitive.

I seem to remember once reading something about this somewhere (how's that
for amazing generalities?) but...

I *think* (but haven't proved) that the problem is worse when our system
has more of a CPU load on it.

VMS 5.5 on a VAX 8550 (or is it an 8530?); the terminal is a VT420 and is
connected via a Datability Vista terminal server.

Actually, while we're at it, I find that my 'forward session' character
for the terminal server also comes in and out of commission when I use
Emacs; that is, Emacs seems to disable it.  Any ideas here?

Thanks,

would-rather-be-hacking-emacs-but-have-other-work,

Denis Haskin
Ziff Information Services
Newsgroups: gnu.emacs.vms
From: rid@nta.no (Robert I Danielsen)
Subject: EMACS 18.59 installation problem
Organization: Norwegian Telecom Research, Norway
Distribution: gnu
Date: 16 Dec 92 13:05:36

Hello everyone,

I'm trying to get emacs-18.59 up on a VAX with VMS 5.5.
I've followed the installation procedures, and I've managed to compile
and link. When I run BUILD.COM which runs temacs.exe and dumps temacs.dump
I get an error when temacs loads the Lisp files:

  . 
  .
  Loading c-mode...
  Loading isearch...
  Loading replace...
  Pure Lisp storage exhausted

What does this mean? I've tried increasing quotas on my VMS account. There
is plenty of memory left in the system, and on page and swapfiles.

Thanks for any help,
--
   __0 
  / /\/ Robert I Danielsen        |Internet: rid@spiff.nta.no
_  /    Norwegian Telecom Research|X.400:    robert.danielsen@forskning.nta.no
 \/\    P.O.Box 83                |Tel.:     + 47 6 809 828
    |_  N-2007 KJELLER, NORWAY    |Fax:      + 47 6 810 076
Newsgroups: gnu.emacs.vms
From: stevef@bony1.bony.com (Steve Faiwiszewski)
Subject: Re: Annoying problem with 18.58 on VMS 5.5; can it be fixed?
Organization: Lost in NYC
Date: Fri, 18 Dec 92 14:17:05 GMT

In article <BzD9vv.440@world.std.com> dwh@world.std.com (Denis W Haskin) writes:
>I've built and installed Gnu Emacs 18.58 on a VMS 5.5 system and it is
>mostly working alright, with one minor but fairly annoying problem.
>
>It appears that Emacs isn't keeping up with keystrokes, and if I use the
>arrow keys (i.e. multi-byte keystrokes) at any decent speed, it
>misinterprets them and I get garbage, including deleted text, inserted
>text, random capitalizations, etc.


We've been having this problem since 18.54 and VMS 5.  Emacs simply
doesn't seem to be able to keep with fast character input.  I've made
inquiries about this in the past, and received a few suggestions for
patches (though don't remember what they were at the moment), but
nothing seems to help.

The problem manifests itself mostly when Emacs is used via vt tubes
(vt220, 240, 320, etc.) which are connected thru DEC terminal servers.
But, I've seen Emacs dropping keys even when running as an X11 client.
Whenever it drops a key when run under X11 it will issue a beep (so
I notice right away and thus it's not so bad), which makes me wonder
how it "knows" it lost a key, and if it does, why can't it just keep
up.

I always hoped that later versions will correct that.  I see that as
of 18.58 it's still a problem. :-(

Sorry I couldn't be more of a help.

>Actually, while we're at it, I find that my 'forward session' character
>for the terminal server also comes in and out of commission when I use
>Emacs; that is, Emacs seems to disable it.  Any ideas here?

It's probably because Emacs switches the terminal session to passthru
mode, so all characters are passed to it instead of being grabbed by
the terminal server.  To forward session while in Emacs, try hitting
break (which puts you back into local on DEC's servers) and then the
forward-session char.

		- Steve -
-- 
Internet: stevef@bony1.bony.com   | / If you could turn on the lights \
bang : {uupsi,uunet}!bony1!stevef ||| quickly enough, you could see   ||
                                  ||| what the dark looks like...     ||
  Opinions? What opinions?        | \_________________________________/
Newsgroups: gnu.emacs.vms
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: EMACS on ALPHA ?
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Thu, 17 Dec 92 03:55:53 GMT


Anyone got EMACS running on ALPHA (VMS of course) yet ? 

-Larry.
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Wed, 16 Dec 1992 15:25:03 EST
Date: Wed, 16 Dec 1992 13:31:17 MST
From: rao@parikalpik.eas.asu.edu (Subbarao Kambhampati)
Subject: problems with vm-search mode
Reply-To: rao@asuvax.asu.edu
Newsgroups: gnu.emacs.vm.bug
I am running vm from lucid-emacs. Lucid emacs uses the newer
isearch-mode package and vm-search-mode seems to be dependent on the
old isearch mode (in particular, it seems to depend on variables like
search-repeat-char, search-reverse-char etc. which are not defined as
variables in the new isearch mode. Is there an easy way to make
vm-search work under these conditions?

rao
From: scott@igc.apc.org (Scott Weikart)
Newsgroups: gnu.emacs.vm.bug
Subject: Re: INBOX file saved with wrong user na
Date: 18 Dec 92 03:26:00 GMT
Nf-ID: #R:CYRIL.92Nov27115952@mercure.cosm:1663849568:cdp:1400600001:000:884
Nf-From: cdp.UUCP!scott    Dec 17 19:26:00 1992


> I am using VM version 5.32 beta and I noticed the following problem : 
> While reading my mail as "su", VM opens my INBOX file and gets my new mail
> (if any), but when exiting, the INBOX file and modified folders are saved
> under name "root".

Here's my modified version of vm-move-mail, with a chown to fix the ownership
of folders when I'm "su root".  Note that I'm running VM 4.41, so vm-move-mail
could have changed substantially (or even disappeared!).

   (defun vm-move-mail (source destination)
     (let ((dest (expand-file-name destination)))
       (call-process "movemail" nil nil nil (expand-file-name source) dest)
       (if (eq (user-uid) 0)
	   (call-process "chown" nil nil nil (user-login-name) dest))))

Scott Weikart			Community Data Processing (CdP): 415-322-9069
Internet: scott@igc.apc.org	Bitnet: scott%igc.apc.org@stanford
UUCP Mail Net: uunet!cdp!scott
From: hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs)
Newsgroups: gnu.emacs.vm.bug
Subject: Bug with strange buffer name
Date: 18 Dec 92 11:02:41
Organization: Karlsruhe University, Germany
NNTP-Posting-Host: whyaduck.telematik.informatik.uni-karlsruhe.de

I think I've found a bug in either buffer-menu or in VM itself.
Sometimes I get mail with a From: line like that:

  From: "NAME, LOCATION  18-Dec-1992 0906" <MAILADDRESS>

(changed to protect the innocent). Don't tell me it's stupid to
generate such a From: line; I know.
Anyway, when I want to reply to such a mail, VM generates a buffer
with the following name:

  sent reply to "NAME, LOCATION  17-Dec-1992 1018"

When I afterwards call buffer-menu, move the cursor to this entry and
hit 'q' to get the buffer on the screen, Emacs tells me

  No buffer named "sent reply to "NAME, LOCATION"

Apparently someone truncates the buffer name after LOCATION.
When I use buffer name completion in the minibuffer, everything works
fine.
Sorry if this is a bug in buffer-menu and not in VM, but I tried to
generate _long_ buffer names, even with double quotes in them, and
buffer-menu didn't choke.
--

Harald Fuchs <hf@telematik.informatik.uni-karlsruhe.de>
Newsgroups: gnu.emacs.vm.info
From: kpc@pluto.arc.nasa.gov (k p c)
Subject: Re: Replying to the To: field
Originator: kpc@zog.arc.nasa.gov
Reply-To: kpc@ptolemy.arc.nasa.gov
Organization: NASA Ames Research Center AI Research and Aero Branches;
	Sterling.
Date: Thu, 17 Dec 1992 02:05:18 GMT

i think what he's getting at goes half of the way toward my partially
composed message suggestion.  all you'd need to do is have a vm mail
mode command to change to to x-to, bcc to x-bcc, and cc to x-cc, set a
flag like x-vm-5-partially-composed: t, and mail it to oneself.

then when you get the message a command will put you back in vm mail
mode, change x-to etc. back to to, etc., and give you the opportunity
to finish composing the message and send it with c-c c-c.

he might have had something different in mind, of course.
-- 
i'm open to comparing research career notes with other young cogsci people.
Newsgroups: gnu.emacs.vm.info
From: shutton@fokker.union.indiana.edu (Scott K. Hutton)
Subject: Re: compilation, paging problems with vm 5.32 beta
Organization: /home/scepimu/shutton/.organization
Date: Fri, 18 Dec 1992 03:34:13 GMT

   From: Neal_McBurnett@ATT.COM (Neal McBurnett)
   Date: Thu, 17 Dec 1992 11:49:11 MDT

   I use vm-5.32 beta.  For a while I have seen the following symptoms:

	   "space" command from summary buffer pages too far down - about
	   1.5 screenfuls.  Works fine in msg buffer.  Bound to
	   vm-scroll-forward in both buffers.

Verified.  It appears that VM thinks it needs to scroll down the
number of lines that would be correct if the narrowed INBOX were the
only window.  Scrolling is correct when the summary window is removed.

-Scott
x-gateway: rodan.UU.NET from info-vm to gnu.emacs.vm.info; Wed, 16 Dec 1992 18:09:05 EST
Date: Wed, 16 Dec 1992 18:09:26 -0500
From: kyle@crystal.wonderworks.com (Kyle Jones)
Subject: Re: parsing the To: field
	<MBN.92Dec16110332@greyskul.hf.intel.com>
	<MELLAN.92Dec15175122@syst06.acri.fr>
Newsgroups: gnu.emacs.vm.info
Mike Northam writes:
 > I think he may have a (broken) mailer such as mine which sends addresses
 > of the form:
 > 
 >   Firstname Lastname <username@domain.com>
 > 
 > into a giant bit bucket somewhere, whereas mail addressed as:
 > 
 >   username@domain.com (Firstname Lastname)
 > 
 > gets sent OK.

Ah, yes, I remember this bug.  The variable vm-strip-reply-headers was
added to VM to addresss this problem.  Try setting this variable to t
and see if it helps.  You might want to use "feedmail" anyway though;
I've only heard good things about it.
From: steinarb@idt.unit.no (Steinar Bang)
Newsgroups: gnu.emacs.vm.info
Subject: Replying to the To: field
Date: 16 Dec 92 21:24:57 GMT
Organization: Norwegian Institute of Technology, Trondheim, Norway

I'm using VM 4.41

I usually BCC to myself outgoing messages I wish to keep. Is there a
way to make VM check the From: field to see if the sender is myself
and then set the To: field of the reply message as the same as the To:
field of the message I'm replying to.

I seem to recall that this was possible in RMAIL. I haven't found a
similar mechanism in VM (haven't looked too hard though...:-)

Thanx!

- Steinar
Newsgroups: gnu.emacs.vm.info
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: How to reply in folder window?
Reply-To: kevin@traffic.den.mmc.com
Organization: Martin Marietta Western Internal Systems, Technical Operations
Date: Tue, 15 Dec 1992 23:30:14 GMT


vm-reply and vm-reply-include-text use the same window from which they
are invoked to display the reply message buffer, so when I've got both a
summary and folder window displayed and invoke vm-reply[-include-text]
from the summary buffer, I'm editing my reply message in a window that's
only 25% (by default) of my screen height.

What I'm trying to do is define a new pair of reply commands that when
invoked from the summary window instead use the folder window to display
the reply message buffer (if vm-mail-percentage is greater than 50).  If
the folder window isn't displaying the current message, it should first
be made to do so so that the reply message buffer is given the
appropriately proportioned window.  (I have vm-mutable-windows set to
t.)

It's the last bit that's giving me trouble: vm-show-current-message
calls vm-text-end-of with a nil argument, causing a "Wrong type
argument: arrayp, nil" error message to be displayed.  Here's what I've
got so far:


(defun vm-reply-in-folder-window ()
  "*If the current major mode is vm-summary-mode, and vm-mail-window-
percentage is greater than 50, then ... before calling vm-reply."
  (interactive)
  (if (and (eq major-mode 'vm-summary-mode)
	   (> vm-mail-window-percentage 50))
      ;; switch to vm-mail-buffer:
      (vm-show-current-message t))
  (vm-reply))

(And similarly for vm-reply-include-text-in-folder-window.)  What is the
correct way to assure that the current message is displayed in the
appropriately proportioned folder window, and that the folder buffer is
the current buffer?
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!