Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!yale!mintaka!bloom-beacon!GAUSS.LLNL.GOV!casey
From: casey@GAUSS.LLNL.GOV (Casey Leedom)
Newsgroups: comp.windows.x
Subject: Re: Using vi as the xmh editor
Message-ID: <9002032007.AA27879@gauss.llnl.gov>
Date: 3 Feb 90 20:07:15 GMT
Sender: casey@gauss.llnl.gov
Organization: The Internet
Lines: 49

/ From: Mark Moraes <moraes@cs.toronto.edu>
| 
| >   A much, much, much better way of handling all of this is to have
| > someone approach xterm from behind in a dark alley with a very large
| > knife and little conscience.  With a few deft moves, xterm's VT100 and
| > TEK modes should be removed.  Bring in a janitor to clean up the blood
| > and instantiate the newly freed VT100 and TEK code as widgets for use by
| > a recovering xterm and any other clients that need either or both
| > terminal emulators.
| 
| Gurgle.  Don't even joke about it...  I've had a couple of brushes with
| xterm code, and it's pretty scary.  It wouldn't take a few moves, it
\ would take fairly massive lobotomies all around...

  My Mama didn't raise no fool.  Why do you think I didn't volunteer? :-)
But, really widgetizing the VT100 and TEK code would be The Right Thing
To Do ...  And, after all, xterm does have the system independent pty
code already, so that wouldn't have to be done over.  It would just have
to be pulled out into a separate set of helper routines.  And making the
pty routines available for all to use would also be The Right Thing To Do.

/ From: dce@icky.Sony.COM (David Elliott)
| 
| >   Actually there's still one problem with the above.  Xmh, xrn, etc. might
| > use a resource like *Editor to specify the path of an editor to exec
| > under a VT100 widget (NULL implies use of Text widget with no other
| > underlaying editor process?).  But what happens when the editor in
| > question already does it's own windows (emacs with X support compiled it,
| > xedit, etc.)?  I guess we might use a resource like *EditorWidget which
| > might be "Text", "VT100" or "none" ...  
| 
| Another option would be to require that the editor named by *Editor do
| its own windows.  Then, supply a command called xvi, which for now is a
| program (shell script, probably) that executes vi in an xterm window with
| appropriate signals ignored, scrollbars forced off, and with the title
| bar set correctly (we used this as a hack to make a System V program
| called cscope bring up editor windows instead of editing in the current
\ window).  Later, when a real xvi is available, it can replace this.

  I didn't suggest this because I didn't want require the overhead of
starting up another X client which is pretty high compared to an already
existing client simply starting up a new window.  But you're right, it's
a very simple approach and the one that xrn took.  If I use emacs, my
editor command is just something like ``emacs %f'' (sorry if I have the
% escape codes wrong here -- it's been a while since I looked at xrn).
If I use vi, my editor command is something like ``xterm -e jove %f''.
It works very well if a bit slowly.

Casey