🚀 go-pugleaf

/ From: kent@godzilla.pa.dec.com (Christopher A. Kent)
| 
| Ah, but what you really want is the ability to point a random editor at
| a window that you already have in your hand! xmh (or any other program)
| should be able to invoke xemacs, xvi, xed, or xteco with a window id and
| say 'go to it, use this as your screen resource, tell me when you're
\ done working on this file'. Just starting up a new xterm isn't good enough.

  For the case of editors which have their own X code I'm not sure this
is doable.  It would certainly be nice because then the editor window(s)
would be part of the parent client's window tree.  But what happens if
you have something like epoch which can create it's own windows
dynamically?  Could/would those windows get hooked into the window tree
correctly?  Also, when you pass a window to a process does it get full
control over the semantics of the window??  E.g. Can it set it up as a
Text widget if it chose to (xedit), as a VT100 emulator (xvi) or just use
it the way it wants to (emacs, epoch)???  I'm very shy own X programming
so this may be a very stupid concerns.

  If this is done, it should be done in some very standard manner so we
don't end up with dozens of different implementations.  Eg. WINDOWID
environment variable is used to pass window id, or a process instantiated
resource, and probably a separate flag environment variable/resource to
indicate that the identified window should be used rather than the
process creating its own connection to the server.

  Again, not really knowning what I'm talking about this may all be
complete foolishness.  All I know is that editors choice is an extremely
religious issue and there's just no point at all in trying to tell people
``Well, look at all the functionality of this foobaz editor.  You're
silly to stick with your old editor!'' Seeing that we have this basically
unconquerable problem of user inertia, it strikes me that it would be
really nice to be able to offer client builders the tools to support
a general editor interface to their applications in a clean manner.

  My problem, being a complete neophyte with regard to X internals
issues, is that I don't really understand what would and what wouldn't be
a clean solution.  But it does look like separating the VT100, TEK and
pty code from xterm's evil grasp would be a start ...

Casey