yost@esquire.UUCP (David A. Yost) (02/20/90)
In article <1120taylorj@yvax.byu.edu> taylorj@yvax.byu.edu (Jim Taylor) writes: >I've written a small, fast runtime editor to replace the one that comes with >SuperCard. It also lets you get at more attributes (like locked, visible, >hilite, etc.) Is there enough interest in this for me to post it? Sure, of course. Do it. Since you know how to get in and replace the editor in SuperCard, maybe you can comment on the following: We are now starting to see a proliferation of specialized text editors built to be hooked into specific Mac applications. This is silly. Plain text editing is a standard thing one needs to do in conjunction with many applications. Apple should have worked out a TextEdit Manager or TextEdit Toolbox or something by now. Some way that souped-up text editing (beyond the base-level text editing provided in the toolbox) can be provided wherever plain text editing is needed. Maybe they have a solution already: maybe IAC will make this a piece of cake. I hope so. Even on dumb old UNIX you can specify as a user profile the ASCII text editor you prefer, and it will be used by applications that need text editing. Of course, the UNIX way is brain dead because it drops you into the editor with only one file[1] and you have to finish and exit and lose all your context--you can't keep the editor active alongside the other application. (Hmmm... yes you could... if you... [see below]) Why don't the Preditor and/or Qued/M people get together with the SuperCard, HyperCard, Wingz, etc. people and Apple and come up with some way their editors can be used for internal editing in other applications? Dave Yost yost@dpw.com or uunet!esquire!yost Please ignore the From or Reply-To fields above, if different. [1] The Rand Message Handler ("MH") and the Rand Editor were modified many years ago to circumvent this problem: the MH reply command puts the name of the message replied to into an 'editalt' environment variable and the editor, if it sees anything in that env variable, puts that file up as the 'alternate file'. P.S. About that "hmm..." above. There could be a generic 'editor-manager' program on unix, say 'edmgr', and you would set EDITOR=edmgr EDMGR_EDITOR=yfe (your favorite editor). When edmgr was invoked, it would launch yfe if it wasn't already running as a service, or it could tell you to run yfe in server mode in some window. Then when yfe is running in server mode, edmgr would send it (over a socket) a list of files to edit. Now, in yfe, all those files are automatically brought up to edit. You edit and save as many of them as you feel like, then issue a new 'done' command, which notifies edmgr to exit. If the next request yfe gets from an edmgr is for different files than you currently have active, yfe will ask you if you want to forget about the previous files and start over; otherwise, it keeps all your same context. Of course, yfe would have to be modified to cooperate with edmgr. Edmgr is really just a compatibility hack to let this new style of editing coexist with existing programs that know only how to invoke $EDITOR in the old way. Eventually, maybe applications would be written on unix that would know how to skip edmgr entirely and talk directly to the editor in this new mode.
jrferro@wheaties.ai.mit.edu (Jon R Ferro) (02/21/90)
In article <1793@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: >P.S. About that "hmm..." above. There could be a >generic 'editor-manager' program on unix, say >'edmgr', and you would set > EDITOR=edmgr EDMGR_EDITOR=yfe >(your favorite editor). When edmgr was invoked, >it would launch yfe if it wasn't already running >as a service, or it could tell you to run yfe in >server mode in some window.... This already partially exists in, of course, GNU Emacs, but it only really works in a windowing environment. Also, it may require the cooperation of your system manager, as emacsclient is one of the "extra" utilities that comes with GNU Emacs that may not exist on certain machines that are trying to save space. It usually lives in the directory named by the Elisp variable "exec-directory", which should be added to the end of your path. (Do "C-h v exec-directory" to see its value.) To set up to use emacsclient put the line: setenv EDITOR emacsclient in your .cshrc, or put the lines: EDITOR=emacsclient export EDITOR in your .profile. Then put the line: (server-start) in your .emacs file. When emacsclient is invoked it sends an ID number and a list of filenames to be edited via a socket to the serving Emacs process and waits for Emacs to signal completion of editing. The first file to be edited pops up in Emacs IF EMACS IS CURRENTLY RUNNING -- either it is in another X window or your current program is a subprocess of the Emacs. Otherwise some mucking around with ^Z and %- is necessary to bring up the serving Emacs for the files to pop up. After editing each file in Emacs, hit "C-x #". This marks the file as done and saves it. After all of the files from a client have been edited Emacs signals the emacsclient process that sent them which then exits, continuing the process which invoked it (i.e. your mailer or Pnews). If you don't always run Emacs immediately after logging in, the following shell script should be put in the file ~/bin/emacsclient (provided that ~/bin is in your PATH). This covers the case of invoking a new Emacs when emacsclient reports that no server exists. ================ #!\bin\sh # If can run emacsclient (GNU Emacs is already running someplace) do # it; else invoke a GNU Emacs proper. # Substitute the absolute path of your emacsclient in the next line. /usr/local/lib/emacs/etc/emacsclient "$@" && exit exec emacs "$@" ================ YAGEF (Yet Another GNU Emacs Feature) from --- -- Jon Ferro jrferro@ai.mit.edu