[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 3 21:54:25 1995 
Subject:Re: poplog and emacs 
From:A . Sloman 
Volume-ID:950303.03 

> an old chestnut I know, but does anyone have a good idea of the state of
> the art regarding poplog and emacs - info about both driving poplog from
> emacs and making VED behave like emacs would be of interest.

One of my colleagues who is now very keen on Pop-11 refuses to use VED
for his programming. LIB VEDEMACS is inadequate for someone who uses
Emacs a lot. I suspect the only way to overcome this would be to write
an interpreter for Emacs lisp and an emulator for most of the main emacs
functions, so that any form of personal tailoring of Emacs can be ported
to VED.

He tried the "contrib" emacs interface and found it largely acceptable,
though some bits did not work, and he had to fix them. Unfortunately the
fixes are now merged with his current emacs environment, so extracting
them will require some effort. (I think they had to do with loading
a marked range.)

However, there are still serious problems.

(a) the fancy new VED-based bold and underlined characters in the
documentation are a **TOTAL** disaster when using Emacs. So he has been
reluctantly forced to run VED in a separate process just for looking up
documentation. (This is why I refuse to use any of the new fancy
character attributes in online documentation that I produce. My view is
that because it was not based on any generally accepted standard for
extending ascii characters, e.g. understood by Emacs, all the effort
that went into the new format was a complete waste of time, especially
when compared with other things that might have been done, e.g. a
sockets package, better menu facilities, etc.)

(b) if you load a library that extends search lists, VED knows about it
but Emacs doesn't. This can be a pain. For this reason I am moving
towards basing any new package on a "startup" file that does nothing but
extend the search lists. So an emacs user can at least load those
searchlist files in the Ved process being used for online help. But
that's not a good general solution.

I still think the best long term solution is for Poplog to define a
client-server protocol for an editor that could be used remotely. Then
Emacs could be programmed to use it and VED could be programmed to use
it (via a socket package!), and a user could have his code running in a
process that is separate from the process (VED, or Emacs, or ...) in
which he is doing development work or looking at documentation, and
might even be on a remote machine (with a shared file structure).

The protocol would have to be quite complicated to support things like
showtree and lib vturtle, and prolog's library(tracer), but even without
those things something useful could be done.

The protocol would have to include a way of telling the editor that
search lists had been extended, and about the equivalent of vedopeners,
vedclosers, etc.

Allowing Emacs to learn about a new searchlist category (as used by
vedgetsysfile) would be another complication. E.g. I don't know if the
current Emacs package can cope with things like INCLUDE * VM_FLAGS.PH
as a cross reference to be got using ved_showinclude.

Aaron