🚀 go-pugleaf

I recently started using epoch (v4.0 patchlevel 2, under X11R5 on a Sun4
running SunOS4.1.1) instead of GNU emacs (18.57) and noticed that some of the
status messages printed when doing extended dired (Sebastian Kremer's dired,
revision 5.120) commands are incorrect.  For example, when marking a single
file for deletion ('d'), then executing the deletion ('x'), the message in the
minibuffer says something like "8 deletions done." even though only one file
was deleted.  Similar errors occur when doing other operations on multiple
files.

I attempted to trace through the code for doing deletions (in spite of the
fact that lisp is greek to me, and I don't understand greek), and the problem
there seems to be in the function dired-internal-do-deletions:

  (defun dired-internal-do-deletions (l arg)
    ;; ...
    (let ((files (mapcar (function car) l))
          (count (length l))
          (succ 0))
    ...
             (message "%d deletion%s done."
                      count (dired-plural-s count)))))

For some reason 'count' usually gets set to 8 or 9, regardless of the number
of files being deleted.  At first I thought it was getting set to the length
of the filename being deleted, but that turned out not to be the case.  I
realize that the problem could be with the dired stuff, but it worked fine
under emacs 18.57, and we are using the exact same dired lisp files for emacs
and epoch.

Any ideas?  (Upgrade to the latest version of everything, right? ;-))

While I am in a posting mood....  I also have been having an occasional (but
most irritating) problem with epoch core dumping.  Unfortunately, I don't seem
to be able to determine what sequence of events causes the core dump, nor
can I do much with the core dump.  If I run gdb on the core file I get the
following:

  Core was generated by `epoch'.
  Program terminated with signal 4, Illegal instruction.
  Couldn't read input and local registers from core file
  #0  0x9b0b4 in bcopy ()
  (gdb)

I'm sure that epoch was compiled with the -g switch and the executable is not
stripped, but I still can't get any stack info.  Any clues on how I figure out
_what_ bcopy it died in?


Thanks,
------------------------------------------------------------------------------
Steve Hawkes                             General Dynamics, Fort Worth Division
                                         Mail Zone 5982
uunet!texsun!gdfwc3!kuwait!hawkes        P.O. Box 748
gdfwc3!hawkes@central.sun.com            Fort Worth, TX 76101
------------------------------------------------------------------------------

--
Steve Hawkes                             General Dynamics, Fort Worth Division
                                         Mail Zone 5982
uunet!texsun!gdfwc3!kuwait!hawkes        P.O. Box 748
gdfwc3!hawkes@central.sun.com            Fort Worth, TX 76101