HDTenEightyP/NetNews huggingface dataset:
From: sjg@zen.void.oz.au (Simon J. Gerraty)
Subject: problems with emacs-18.58 on Pyramid (MIPS,SysVr4)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 19:15:57 GMT

etc/MACHINES mentions that it is unknown whether emacs will work
on the MIPS based Pyramid systems.  It _almost_ does...

Sorry for the lack of detail, this system is at a site that has
no outside links.  Also I have not yet seen any documentation
for this system so can't be more specific yet.


Anyway, for the interested, I used

s-usg5-4.h, m-pyramid.h and added these to config.h

#define SYSTEM_MALLOC
#define HAVE_ALLOCA
#define CANNOT_DUMP

The first two reduced the frequencey of memory faults and bus
errors. 

Emacs compiled with only ONE warniing about garbage after a
pre-processor directive.

Use make CPP=/usr/ccs/lib/cpp as cc -E gets it all wrong.

(producess muck like $ { XXXX } vs. ${XXX})

At this point, xemacs works pretty well, but re_search etc does
not work.

I noticed this when dired mode claimed there were no files to be
found.  Debugging dired.el showed that it was a RE search
failing.

Doing the same search manually showed (in a dired buffer).

"\\(Oct\\|Mar\\)[ ]"

matches ok but

"\\(Oct\\|Mar\\)[ ]+"

or

"\\(Oct\\|Mar\\)[ ]*"

failed.

In fact I still get core dumps from re_seach() causing recursive
calls to re_match_2().

I'm sure there will be something simple.

I've looked at the regex.c code briefly and can't see any reason
for it not to work.   I'm guessing that the problem is caused by
recursion (all of the core files I've looked at showed it).

Please e-mail any suggestions, as I have little time just now
for scanning news.

Simon J. Gerraty        <sjg@zen.void.oz.au>

#include <disclaimer>   /* imagine something _very_ witty here */

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: terminal-emulator should print a msg on startup
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 22:11:28 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

saying at least what the escape character is, so the user
knows how to get out of it.

It should also be documented in the emacs manual.

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: "cd" in shell mode should report errors
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 04:06:19 GMT

   Newsgroups: gnu.emacs.bug
   References: <9210142122.AA14324@napa.TELEBIT.COM>
   From: chris ross <cjross@BBN.COM>
   Date: Wed, 14 Oct 92 23:42:50 EDT
   Sender: cjross@BBN.COM

   In gnu.emacs.bug you write:

   >When change directories in a subshell, Emacs tries to notice, so
   >that find-file etc. do the right thing.  But if the current dir
   >has a subdir called "foobar-frobozz-pastafazoola" and I type
   >"cd foo*" to change into it, Emacs doesn't track it properly.
   >It is maybe too much to ask for Emacs to expand "foo*", but
   >if it tries to cd to "foo*" and fails, it should display
   >some message in the mode line saying that this has happened.
   >Then I can notice and do something about it if necessary.

   Check out the doc for the variable 'shell-set-directory-error-hook'.
   You can use it to issue a warning message, or write your own super-
   intelligent directory tracker.

Thanks.  This should go in the mode help message for shell mode.

Newsgroups: gnu.emacs.bug
From: js9s@helga2.acc.virginia.edu (Jiangeng  Sun)
Subject: M-x next-error won't work
Reply-To: js9s@helga2.acc.virginia.edu (Jiangeng  Sun)
Organization: University of Virginia
Distribution: gnu
Date: Thu, 15 Oct 1992 04:53:45 GMT

I  recently  moved from ultrix-3.0 to ultrix4.2a. I recompiled
emacs-18.58. Everything works fine except when I do
M-x next-error,  it always tells me no more errors. Why it
won't find errors?   My suspicion is that the error message
syntax in the new compiler has changed, so emacs could not
match the expression. If that is the case, where should I 
look?  Does any body have any ideas?

thanks.

j.g.

Newsgroups: gnu.emacs.bug
From: dominic@smallworld.co.uk (Dominic Prior)
Subject: intermittent emacs crashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 20:55:25 GMT

Some of my colleagues have been having crashes in Emacs-18.55 and
Emacs-18.57 once or twice a week and I was wondering if there is
anything that you can recommend.

The funny thing is that most of us *never* have crashes, and those
that do always claim not to have been doing anything unusual at the
time.  For a while, it was only people running a particular program
under their shell-mode shell.  Is it possible for badly behaved
sub-processes to crash Emacs?

We've not touched the C source-code at all, are not running out of
swap-space (although we do get close) and manage to get crashes
equally on all three of our unix platforms (sparc, decstation and
rs/6000).  I've added quite a lot (7000 lines) of Lisp extensions,
including some elaborate filters and mouse-handling stuff, but,
presumably, I shouldn't be able to crash Emacs from Lisp.

According to the core-dumps, the crashes are happening in `alloc.c'.

I admire Emacs greatly and will continue using it (and recommending
it!) and so would be very grateful for any advice that you can give me.

Dominic Prior  (dominic@smallworld.co.uk)

Newsgroups: gnu.emacs.bug
From: MAJERCIK@ucsvax.ucs.umass.EDU
Subject: vms problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 09:42:54 GMT

HI,

  I've been trying to get emacs to compile correctly on a VMS
 system.  It works, but I have a few problems.  The M-x
 shell command produces the error "Symbol's function definition
  is void: vms-system-info".  Also, when C-z is hit to interupt
  the process I get a similiar error  ---void: get-buffer-process.
 
  I was hoping you could tell me what needs to be changed to
  get these problem fixed.   Where are the variable located that
  need to be changed for temp files?

  thsnks,

  Andrew 
  UCSVAX operator at UMASS

   (student)


Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: info bug
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 16:43:00 GMT

In the Regexp Search node of the emacs info:

   Note that adding characters to the regexp in an incremental regexp
search does not make the cursor move back and start again.  Perhaps it
ought to; I am not sure.  As it stands, if you have searched for `foo'
and you add `\|bar', the search will not check for a `bar' in the
buffer before the `foo'.

My emacs (18.58) does it instead.

		    Francesco Potorti`	| pot@cnuce.cnr.IT (Internet)
				 	| 39369::pot       (DECnet)
					| +39-50-593203    (voice)

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: info tutorial has no up pointers
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 21:06:28 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

The Info tutorial's nodes should have Up pointers, as appropriate.
You should always be able to get back to the (DIR) node by hitting
"u" enough times.

Newsgroups: gnu.emacs.bug
From: smg@surf.cis.ufl.edu (Scot M. Gardner)
Subject: mh-e sometimes does not send mail
Reply-To: Scot Gardner <smg@cis.ufl.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 04:18:07 GMT

Please note, I'm NOT a lisp hack. Nor am I an emacs guru of any 
sort.

I use emacs mh-e to read my mail using mh. I noticed in the past 
that mh-e would not send a message once in a while (reply or otherwise
started in mh-e). It would tell you it was sent, but it would still
be in the drafts directory and would never get sent. This problem 
became more frequent when we upgraded (emacs 18.57.2 and the OS is 
SunOS 4.1.2). To fix this I found that I could change mh-exec-cmd-daemon
to mh-exec-cmd in mh-send-letter and mail would always get sent.
Is this a known bug, or does anyone have any idea why this is happening?

|Scot Gardner Inet: smg@cis.ufl.edu UUCP: ...!gatech!uflorida!smg             |
|"Warning, For external use only. If taken internaly severe gastric           |
| disturbance will result"                                                    |

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: shell mode should have "update cwd" command
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 21:27:40 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

This is a followon to the previous message.

I suggest adding an "update current working directory" command
to shell mode.  It could be M-x update-cwd or it could be
on a key like "C-c .".  It would figure out the current directory
of the running shell and make Emacs notice.  It could work by sending
"pwd" to the shell, then reading and erasing the output from the buffer.

Newsgroups: gnu.emacs.bug
From: Damian.Cugley@comlab.ox.ac.UK (Damian Cugley)
Subject: texinfo 2.16: Developing new texinfo docs is still a pain
Organization: Computing Laboratory, Oxford University, UK
Distribution: gnu
Date: Thu, 15 Oct 1992 21:08:56 GMT

Summary: There is no easy way to proofread info files.
	This makes it difficult to produce texinfo documentation.

The main problem is that it is hard to add temporarily a new info file
to the info tree if you don't have write access to the top-level info
directory.  To read a new file in info, I have to specify its full name.
If I am editing a texinfo file, there is no way to tell info to reread
the file when I change it, which means I have to kill info (or at least
switch to a different file) and specifiy the file again ... and again
and again and again...

* makeinfo program is undocumented.  There should be an entry in the
texinfo docs at least.  Maybe "makeinfo" has options specifying useful
things, but how can I find out?

* The "info" program itself is undocumented (there is no info or man
page for it; what sort of an advertisement for info is this supposed to
be?).  Grepping the source I find it has an undocumented INFOPATH
variable.  Groovy.  This still doesnt quite address the problem of
specifying THIS FILE HERE tho.

* Xinfo is undocumented.  It has no INFOPATH so far as I can tell but
"strings" tells me that it probably has a resource called "infoPath".
Wonderful.  Now I have to make sure I keep two bits of customization --
in completely different files -- up to date in parallel.  (Maybe Emacs's
info mode also has an info-path.  Who can tell?)  I wonder what format
this undocumented resource is supposed to be in.  Too bad "info",
"Xinfo" and Emacs info-mode can't all use INFOPATH (overriding an X
resource or lisp variable respectively).

* Xinfo doesn't understand tilde in file names -- so I have to use my
full directory name each time I try to read a file.

* The slot for entering node names in on the Xinfo panel does not resize
and has no scrollbar -- so typing long node names has to be done blind!
(And if I am hacking an info file in /users/me/somedir/somepackage then
the node name is pretty long.)  If I press RET in the little window,
Xinfo usually dies with a segmentation fault.

* A few quibbles: The info documentation does not state that nodes must
begin with

        NEWLINE ^_ [ ^L ] NEWLINE

I tried making an info file starting with "^_" and all the info-reading
programs could not find the first node.  Very frustrating.

The info documentation assumes you are reading in Emacs's info-mode and
can see the "Node: foo" line at the top of the screen.  In Xinfo this
information is replaced by the button labels.  The info info node should
give an example node head line or something.

texinfo.tex gives ENORMOUS values to \parskip.  Why?


Newsgroups: gnu.emacs.bug
From: wohler@sap-ag.DE (Bill Wohler)
Subject: Re: mh-e sometimes does not send mail
Reply-To: Bill Wohler <wohler@sap-ag.de>
Organization: SAP AG, Walldorf, Germany
Distribution: gnu
Date: Fri, 9 Oct 1992 11:34:15 GMT

smg@surf.cis.ufl.edu (Scot M. Gardner) writes:
>I noticed in the past 
>that mh-e would not send a message once in a while

>To fix this I found that I could change mh-exec-cmd-daemon
>to mh-exec-cmd in mh-send-letter and mail would always get sent.
>Is this a known bug, or does anyone have any idea why this is happening?

  yes, this bug has existed (and only on suns) since at least '86 or
  so.  if anyone had any idea what was happening, it would be fixed by
  now (i have not observed the behavior on hps, decs or ibms).

  you found the correct solution by not using the -daemon variant--the
  send -push was failing on the sun for some reason.  you can achieve
  the same behavior without modifying the sources by sending with "C-u
  C-c C-c".

  heres an alias that i used to use to send the unsent drafts:
  
	alias senddead	'send -draftf drafts'


Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler>
Heidelberg Red Barons Ultimate Frisbee Team

Newsgroups: gnu.emacs.bug
From: rsm@math.arizona.edu (Robert S. Maier)
Subject: stdout vs. stderr in called processes?
Organization: Mathematics Department, University of Arizona
Distribution: gnu
Date: Sat, 10 Oct 1992 01:23:23 GMT

The function `call-process', which is coded in C in callproc.c, doesn't
distinguish between output sent by the process to stdout, and output sent
by the process to stderr.  Both get sent into the same pipe, and inserted
into the same (specified) buffer.

Is this a bug or a feature?  A bug, I think.  There should be a way of
specifying different buffers for stdout and stderr.

Does anyone agree with me on this?

-- 
Robert S. Maier   | Internet: rsm@math.arizona.edu, rsm@cs.arizona.edu
Dept. of Math.    | UUCP: uunet!arizona!amethyst!rsm
Univ. of Arizona  | Bitnet: maier@arizvms
Tucson, AZ  85721 | FAX: +1 602 621 8322
U.S.A.            | Voice(POTS): +1 602 621 6893  /  +1 602 621 2617

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: Re: stdout vs. stderr in called processes?
Organization: Boston University Computer Science Department
Distribution: gnu
Date: Sun, 11 Oct 1992 03:00:31 GMT

In article <RSM.92Oct9182323@coral.math.arizona.edu> rsm@math.arizona.edu (Robert S. Maier) writes:

   The function `call-process', which is coded in C in callproc.c, doesn't
   distinguish between output sent by the process to stdout, and output sent
   by the process to stderr.  Both get sent into the same pipe, and inserted
   into the same (specified) buffer.

   Is this a bug or a feature?

A bug of course.  Intentional, but a bug none the less.

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details

Newsgroups: gnu.emacs.vm.bug
From: weigert@etlhit.etl.go.jp (Thomas Weigert)
Subject: VM crashes emacs
Reply-To: weigert@mcs.anl.gov
Organization: Electrotechnical Laboratory, Tsukuba-shi, Japan
Date: Tue, 13 Oct 1992 06:15:10 GMT


For quite a while I am experiencing sudden emacs crashes for no apparent
reason. Until recently I had not checked, since it happened only a few
times a week. But now it happens aggrevatingly often. 

I am convinced that the culprit is VM. In particular, it appears that once
your mail-files are sufficiently large (> 100 messages), then the tiniest
network timeout sends emacs down the tubes. I am using VM 5.31.

Does anybody else experience this problem, and if so, how are you working
around it. Might upgrading to VM 5.32 help?

Thanks for any help.

Thomas.
--
Note: The address below is valid until Jan 15, 1993.

+--------------------------------+---------------------------------+
| Thomas Weigert                 |                                 |
| Machine Inference Section      |                                 |
| Electrotechnical Laboratory    |                                 |
| Umezono 1-1-4, Tukuba-shi      | weigert@{mcs.anl.gov,etl.go.jp} |
| Ibaraki 305, Japan             | +81-298-58-5918 (phone+fax)     |
+--------------------------------+---------------------------------+
Newsgroups: gnu.emacs.vm.bug
From: fox@cs.nyu.edu (David Fox)
Subject: Re: VM crashes emacs
Organization: Courant Institute of Mathematical Sciences
Date: Thu, 15 Oct 1992 02:42:09 GMT
X-Posted-From: graphics.cs.nyu.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <WEIGERT.92Oct13151510@etlhit.etl.go.jp> weigert@etlhit.etl.go.jp (Thomas Weigert) writes:

   For quite a while I am experiencing sudden emacs crashes for no apparent
   reason. Until recently I had not checked, since it happened only a few
   times a week. But now it happens aggrevatingly often. 

   I am convinced that the culprit is VM. In particular, it appears that once
   your mail-files are sufficiently large (> 100 messages), then the tiniest
   network timeout sends emacs down the tubes. I am using VM 5.31.

   Does anybody else experience this problem

I experience it.

   and if so, how are you working around it.

I suffer with it.  I try to keep my mailboxes small, but that is
difficult.  Doing things with summary buffers that are re-ordered
seems to aggravate it.  Unfortunately re-compiling emacs is not an
option for me.  But I haven't given up VM.  Yet.
Newsgroups: gnu.emacs.vm.bug
From: kpc@pluto.arc.nasa.gov (k p c)
Subject: Re: Buffer position bug with VM 5.32 and Emacs 18.58
Followup-To: gnu.emacs.vm.bug
Reply-To: kpc@ptolemy.arc.nasa.gov
Organization: NASA Ames Research Center AI Research Branch; Sterling.
Date: Wed, 7 Oct 1992 22:03:39 GMT

these are vm bugs, i think.  i think that there is no fix to #1, but
that jwz has a fix to #2.
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Thu, 8 Oct 1992 18:02:08 EDT
From: kyle@uunet.uu.net (Kyle Jones)
Date: Thu, 8 Oct 1992 18:01:46 -0400
Subject: Re: vm-isearch-forward
	<9209270745.AA03339@banach>
Newsgroups: gnu.emacs.vm.bug
Len Weisberg writes:
 > Oliver Schoett writes:
 > Kyle> Maybe the attribute should be "exposed" instead of "read".
 > Kyle> That's generally what VM means by "read".  It can't really know
 > Kyle> wheyther you've read the message of course.
 > 
 > > That's one of my pet peeves with vm and gnus as compared to rn.  They
 > > mark a message read when it is first exposed.  But this is simply
 > > wrong, as I have not yet read it (for example, I might get
 > > interrupted).  I prefer the approach of rn, where an article is marked
 > > 'read' upon leaving it with a command whose meaning is "I've read this
 > > one, go to the next one".
 > 
 > Hear, Hear!  Thanks for not giving up at the phrase "of course" .
 > So there is a natural way of telling vm that a message has been read.

Well, this is the way I originally implemented it, but I had
lotsa trouble deciding which commands should mark a message as
read and in what contexts.

Marking a message as read after it's been exposed seems natural
to me.  But perhaps VM is being too presumptious to even hope to
get this right.  I hate programs that are too smart for their own
good.  Maybe VM should lose this feature altogether.
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Thu, 15 Oct 1992 07:19:02 EDT
Date: Thu, 15 Oct 1992 07:19:02 -0400
From: kyle@uunet.uu.net (Kyle Jones)
Subject: Re: VM crashes emacs
	<WEIGERT.92Oct13151510@etlhit.etl.go.jp>
Newsgroups: gnu.emacs.vm.bug
Not much I can do about the Emacs crashing phenom.  In the past I
have coded around known Emacs problems (like bugs in the regex
code) that caused crashes, but I can't do that here until the
problem is narrowed further.  All I can advise is to upgrade to
18.58 and if the problem persists start sending bug reports and
stack traces to bug-gnu-emacs@prep.ai.mit.edu.
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Mon, 12 Oct 1992 13:38:45 EDT
From: kyle@uunet.uu.net (Kyle Jones)
Date: Mon, 12 Oct 1992 12:41:43 -0400
Subject: mailbox buffer messed up after followup
Newsgroups: gnu.emacs.vm.bug
Joe Lammens writes:
 > Often (but not always) after following up (F) or replying (R) to a message
 > in a vm box (e.g. INBOX), the mailbox buffer is messed up when I am
 > returned to it. Point seems to be at the beginning of the file, and all the
 > headers and things that usually don't show do. Hitting "p" followed by "n"
 > fixes things. I haven't detected any pattern in when it does or does not
 > happen. 

This is a clipping region display problem that appeared in
post-18.55 Emacs releases.  I believe it is fixed in 18.58l I
haven't noticed it since upgrading.
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Thu, 8 Oct 1992 18:56:01 EDT
From: kyle@uunet.uu.net (Kyle Jones)
Date: Thu, 8 Oct 1992 18:41:52 -0400
Subject: Re: vm-confirm-quit should have value meaning ask if folder > some size
	<9210021722.AA05654@wendy-fate.UU.NET>
	<JBW.92Oct3193217@bigbird.bu.edu>
	<RENS.92Oct5190542@lorax.shearson.com>
Newsgroups: gnu.emacs.vm.bug
Rens Troost writes:
 > In article <JBW.92Oct3193217@bigbird.bu.edu> jbw@bigbird.bu.edu (Joe Wells) writes:
 > 
 >    In article <9210021722.AA05654@wendy-fate.UU.NET> kyle@uunet.uu.net (Kyle Jones) writes:
 >       Good idea.  I think size should be in number of messages rather
 >       than bytes, though.
 > 
 >    What is the relative effect of number of messages vs. number of bytes on
 >    how long it takes VM to load a folder?
 > 
 > It should really allow either setting dependent on the symbol's
 > variable value. In fact, I'd like to see it execute the symbol's
 > function cell, and act on the result. That way I could set my own test
 > function.

Too complicated for the typical user, I think.  Size in messages
is the best approximation I think.
From: diecph@ucunix.ucunix.san.uc.edu (TheDrivenOne)
Newsgroups: gnu.emacs.vm.bug
Subject: Re: Makefile suggestion
Date: 9 Oct 92 00:47:24 GMT
	<9210082248.AA15282@wendy-fate.UU.NET>
Organization: University of Cincinnati

In article <9210082248.AA15282@wendy-fate.UU.NET> kyle@uunet.uu.net (Kyle Jones) writes:

   x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Thu, 8 Oct 1992 18:55:48 EDT
   From: kyle@uunet.uu.net (Kyle Jones)
   Date: Thu, 8 Oct 1992 18:48:21 -0400
   References: <1992Oct6.132122.160242@eratu.rz.uni-konstanz.de>
   Newsgroups: gnu.emacs.vm.bug
Path: ucunix.san.uc.edu!babbage.ece.uc.edu!news.cs.indiana.edu!usenet.ucs.indiana.edu!sol.ctr.columbia.edu!caen!uunet!wendy-fate.uu.net!bug-vm
   Sender: bug-vm-request@uunet.uu.net
   Lines: 3

   I'm going to give VM a better Makefile.  I can't just change *.el
   to vm-*.el because VM comes with some non VM auxiliary Lisp files
   that need to be compiled.

*blink* non-vm auxilliary files?  In which version?  In the vm5.32beta
file I just ftp'd from ftp.uu.net, the following files are contained:
vm-delete.el
vm-digest.el
vm-edit.el
vm-folder.el
vm-group.el
vm-license.el
vm-mark.el
vm-message.el
vm-misc.el
vm-motion.el
vm-page.el
vm-reply.el
vm-save.el
vm-search.el
vm-summary.el
vm-undo.el
vm-vars.el
vm-version.el
vm-virtual.el
vm-window.el
vm.texinfo
vmcard.tex
COPYING
README
Makefile
(as outputed from a 'gnutar xzvf vm-5.32beta.tar.Z' shell-command)
Now except for the texinfo, all of these files appear to be vm-related.
If you could clarify what exactly you meant, this would be most
appreciated.

diecph@ucunix.san.uc.edu
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Wed, 7 Oct 1992 03:36:53 EDT
From: Ulf.Westermark@eua.ericsson.se (Ulf Westermark)
Date: Wed, 7 Oct 1992 08:36:44 +0100
Subject: Startup message
Newsgroups: gnu.emacs.vm.bug
Hi,

I got vm 5.23 Beta from ftp.uu.net.

When I start VM on my Sun Sparc with SUN OS 4.1.1, Open Windows and 
Emacs 18.55 I get the following message:

can't support numeric vm-flush-interval without interval timers... sorry.

What does it mean ?

When do you plan to release the first real version of VM 5.32 (not beta) ?

Regards
Ulf Westermark
Ellemtel Development Inc