bingle@cs.purdue.EDU (Richard Bingle) (02/02/90)
We have a user that would like to use vi when composing, replying, and forwarding mail while using xmh. It seems that he got used to that style while using xmail from Tektronix. My questions are, is there any way that this can be accomplished short of a change to the source code? If not, what changes would be necessary? Has anyone else had to placate vi users like this? Thanks, Richard Bingle bingle@purdue.cs.edu Computer Science Department purdue!bingle Purdue University (317) 494-0893 West Lafayette, IN 47907
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (02/03/90)
> We have a user that would like to use vi when composing, replying, and > forwarding mail while using xmh. It seems that he got used to that style > while using xmail from Tektronix. My questions are, is there any way that > this can be accomplished short of a change to the source code? Nope. > If not, what changes would be necessary? You need to write (modify) the Text widget. It currently only supports emacs style editing bindings, and assumes modeless editing. If you are waiting for MIT to support a vi mode, be sure to check the temperature in Hell on a daily basis, and when it gets below freezing... Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
casey@gauss.llnl.gov (Casey Leedom) (02/03/90)
| From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) | | > From: bingle@cs.purdue.EDU (Richard Bingle) | > | > We have a user that would like to use vi when composing, replying, and | > forwarding mail while using xmh. It seems that he got used to that style | > while using xmail from Tektronix. My questions are, is there any way that | > this can be accomplished short of a change to the source code? | | Nope. | | > If not, what changes would be necessary? | | You need to write (modify) the Text widget. It currently only supports | emacs style editing bindings, and assumes modeless editing. If you are | waiting for MIT to support a vi mode, be sure to check the temperature in | Hell on a daily basis, and when it gets below freezing... I also have the same request, but for use with a different editor. It should be obvious that trying to put multiple editor styles into the Text widget is just plain dumb. 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. 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" ... Looking for someone with blood on their hands, Casey
dce@smsc.sony.com (David Elliott) (02/04/90)
In article <47054@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: > 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, which could be implemented now, 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. Or, you might change xmh to use *Editor and *XEditor. The former would be an editor that requires running under a VT100 terminal emulator, and the latter would be an editor that does its own windows. Of course, that's not to say that the extraction of the VT100 and TEK emulators is not a good idea. There are many cases where people would like to use something like xterm with just a few extensions (menus, buttons, key translations, etc.). -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "Never call a crazed psychotic a crazed psychotic."
casey@GAUSS.LLNL.GOV (Casey Leedom) (02/04/90)
/ 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
kent@godzilla.pa.dec.com (Christopher A. Kent) (02/04/90)
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. Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639
casey@gauss.llnl.gov (Casey Leedom) (02/04/90)
/ 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
hvr@kimba.Sun.COM (Heather Rose) (02/04/90)
In article <47054@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: > > I also have the same request, but for use with a different editor. It >should be obvious that trying to put multiple editor styles into the >Text widget is just plain dumb. > > 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. Instead of doing so much work to change the toolkit, if one were to port xmh to the XView toolkit, the reader window could be a TTYSW and you can set the child of the TTYSW to be "my favorite editor" defined by a default, an environment variable, a command line argument, and whatever else method you want to supply. The code would look something like this: #include <xview/xview.h> #include <xview/tty.h> main(argc, argv) char *argv[]; { Tty view_window; Frame frame; char *my_argv; xv_init(); frame = (Frame)xv_create(NULL, FRAME, NULL); my_argv = (char *)get_my_favorite_editor(&argc, argv); view_window = (Tty)xv_create(frame, TTY, TTY_ARGV, my_argv, NULL); window_fit(frame); xv_main_loop(frame); } change_message_in_view_window(...) { ttysw_input(view_window, "editor commands to switch to a new file to edit"); or change_contents("of current file that is being edited") and perhaps refreash_window(); } With this scheme it would also be easy to add the ability to bring up a new frame for the next mesage to view. So, in XView, you might put a "pin" on the view window's frame. If the user pushes the pin in, then the application would know that it should bring up the next message to view in a new window. When the user takes out the pin, then the view window would be dismissed. The same option could be supplied on a menu as well in an entry such as "view next message in new window". If no editor were specified or specified incorrectly, the default view window could be textsw instead of a ttysw. I know of at least two people porting mh to XView, so perhaps they're reading this? ;-) Heather