Get the patches from:
ftp//gatekeeper.dec.com:/pub/GNU/emacs-19.26-alpha-patch.gz and
                                 emacs-19.28-alpha-patch.README

The 19.26 patch works for 19.28, too.

  If any key other than a cursor movement or history retrieval key
  is typed, the contents of the buffer will be erased and the key
  typed will become the first character in the buffer.

I'm using GNU EMACS 19.27.1 for OS/2 and I'm very happy with it -
except for M-x manual-entry. My shell is sh.exe (yes, I set SHELL to
f:/bin/sh.exe), which runs fine in shell mode. 'man' runs both in
native OS/2 as well as in an Emacs-Shell, so I'm pretty sure, my
installation is ok.

When I try M-x manual entry I get:

error: SYS3175 (access violation exception) from OS/2

and:
Process terminated by SIGSEGV
core dumped

process exited abnormally with code 5

by Emacs.

Any hints?!

Michael.

bogoe...@rbg.informatik.th-darmstadt.de

thanks,
dion

Hello

We have a setup, where we use the vi editor for everything.
When I asked my SysMgr, to install emacs, I ran into a problem:

The standard distribution takes some 40MB of HD memory, and
I dont know haw many bytes to compile.

So my SysMgr was really surprised (and terrified) to hear this
requrements. He couldnt allocate the ammount of memory for me,
neither could he give me amachne to compile the editor.

Since I dont need (at first) all possible emacs extensions,
my question:

-> What is the absolute minimum setup for emacs. (which files
   exactly, and what are the limitation, e.g no macros)

-> How much memory does it take on HD, and while running.

-> How many new directories has my SysMgr to define e.g.
   /usr/local/bin/emacs (this is a problem, because we have more
   machines, some of them share HD other dont, so the ammount of
   work to install is a concern)

-> Where do I find an already compiled emacs for HP 712/60 with PARISC

The other objection to the use of emacs was the relative slowliness
(compared to the responsitivity of the old and small vi) and the need
to 'instruct and mantain' a new editor for the people working here.

Any advice?

   We have a setup, where we use the vi editor for everything.
   When I asked my SysMgr, to install emacs, I ran into a problem:

   The standard distribution takes some 40MB of HD memory, and
   I dont know haw many bytes to compile.

You end up having about 20 MB all together after compiling and
removing the sources.

   So my SysMgr was really surprised (and terrified) to hear this
   requrements. He couldnt allocate the ammount of memory for me,
   neither could he give me amachne to compile the editor.

What? You have tons of HP's and nowhere maybe 60MB left. That would
slow your systems down a lot.

   Since I dont need (at first) all possible emacs extensions,
   my question:

   -> What is the absolute minimum setup for emacs. (which files
      exactly, and what are the limitation, e.g no macros)

If you remove all *unnecessary* Lisp files maybe about 10 MB or even
less. Sure, vi is smaller. But removing things (not the wrong one's)
are sometimes more expensive than paying some more MB for a disk -
that's why all workstations have big disks ;-)

   -> How much memory does it take on HD, and while running.

Disk see above. Mem on HP:
 F S     UID   PID  PPID  C PRI NI     ADDR   SZ    WCHAN    STIME TTY      TIME COMD
 1 S  fietze   504   503  0 154 20  43dda40  633   1eee20 13:07:43 ?        0:00 /usr/local/bin/emacs

   -> How many new directories has my SysMgr to define e.g.
      /usr/local/bin/emacs (this is a problem, because we have more
      machines, some of them share HD other dont, so the ammount of
      work to install is a concern)

You end up having the binary in /usr/local/bin or wherever you want
and the rest under /usr/local/lib/emacs or wherever you want (easy to
tell Configure at the beginning. make install creates the dirs for you.

   -> Where do I find an already compiled emacs for HP 712/60 with PARISC

Sorry. Don't know. But it's no problem to compile for a real Sysadm:
./Configure;make;make install

   The other objection to the use of emacs was the relative slowliness
   (compared to the responsitivity of the old and small vi) and the need
   to 'instruct and mantain' a new editor for the people working here.

Emacs is faster to learn for newcomers (esp. the X version). I'm Unix
sysadm for years now and know only very little about vi (just enough
to edit some small files to get the system and emacs running).

If you don't maintain Emacs you get a working version w/ many many
features already and maintenance is again "ftp
...;...;./Configure;make;make install". No big deal except if you want
to write own ELisp programs.

   Any advice?

Try to get it.

  Matija> The standard distribution takes some 40MB of HD memory, and
  Matija> I dont know haw many bytes to compile.

As hard disk space is cheap nowadays, that shouldn't be too much of a
problem.

  Matija> The other objection to the use of emacs was the relative
  Matija> slowliness (compared to the responsitivity of the old and
  Matija> small vi) and the need to 'instruct and mantain' a new
  Matija> editor for the people working here.

Well, machines get faster and faster, and I don't notice any speed
deficiency with Emacs, except for the startup time.  But with Emacs,
you start it when you log in and exit just before you log out, so that
time penalty is incurred rather seldomly.

And there are many more things that Emacs can do which vi can't, and
once people learn Emacs, they do not have to adapt to a new
environment for any number of things (like reading and writing mail,
like reading and posting news, like running a debugger and many more
things).  Further, Emacs has color support (on machines with a
windowing system (like X)) which is very nice and has brought a number
of people to prefer Emacs.

   When acting on buffers, those actions should only act on buffers
   generated (or "opened") in that frame. This allows the frame to
   appear as a separate editing session. An example would be listing
   the existing buffers. It should only list those buffers "opened"
   in that frame. Currently it shows all buffers from all frames.

   BUT a frame should still remain coupled to all the other frames
   in an editing session. In this case, if identical buffers are
   "opened" in different frames, they should all really edit the
   same buffer. This way there remains only one version of an edited
   buffer through an emacs session. A frame does this now but without
   the above feature, so it seems very much like an emacs window
   implimentation in X.

   When I work on code, it is usually spread across many directories
   as I work on bits and pieces. I would like to start 1 emacs session
   where when I go to a new directory for source, I use dired-mode
   in a new frame to collect that directory and begin to "open" buffers
   with the source thats in the directory. However, since I'm human and
   prone to err, I would like emacs to help save me from myself. After
   the fifth or sixth frame, I begin to loose track of where I am and
   the buffer list gets REALLY big. So if I begin to edit some source
   open in one of the other frames it just shares that buffer between
   frames.

   Well thats what I would like to see and how I perceive things working.
   I hope that helps.  But for me, I still curious to know if the design
   philosophy to impliment emacs windows in X.

Yes, I see what you mean.  I think this sort of separation would be
rather nice.

I rather suspect that there is very little 'design philosophy' in the
concept of frames.  Rather everyone just thought it would be nice to
be able to have more than one X window to display buffers.  And it is
nice, but that doesn't mean that the design philosophy can't be
incrementally improved in the way that you suggest.

In practical terms I do not think it would be difficult to implement
your suggestions.  A buffer local variable, e.g. `buffer-frame', can
be set to a particular frame or to nil.  Then

1. (switch-to-buffer buf) checks buf's value of buffer-frame.  If
equal to an existing frame, do (select-frame buffer-frame) before
switching to the buffer.  If nil, just do what happens at present.

2. The buffer list now comes in two parts: 'unattached' buffers,
i.e. those with buffer-frame == nil, and the buffers attached to the
frame in which the buffer list is requested.

One or more user options would govern if and when buffer-frame was set
for a particular buffer.

I would further suggest to change every backslash in emx and
emacs specific environment variables into a slash.
The use of slashes is explicitly recommended in the docs,
because as the author states, he has build a conversion routine,
but he may have forgotten some places.

If the above won't work to you (should take you not more than
10 min including reboot), delete all the stuff and install the
whole emx/emacs environment down the root, i.e. unzip the
distribution files in the root directory and let them place where
the default is.
I'll bet you will have had a problem then, but as I said, just a guess.

any suggestions?