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.