> i always thought about making the changes in the filesystem. > to be able to have certain windows (fs directories) bound to local > files and others bound to remote files. reads/writes on the > latter would be translated to a sam-like protocol and sent to > the other host. your first remote window could be started with > something like 'New hostname', which would bring up a directory > window.
There are edits (for want of a better name) that can be applied, sed-like, to a view of the file (or even multiple views of open files) while there are others that need a more direct application. It doesn't seem possible to combine these into a single, more general operation. I think it is unfortunate that "brief" was based on "emacs" and that therefore it shared in the latter's reputation, I think there were some valuable concepts in brief that were discarded for the wrong reasons. A New Generation editor would consist, in my uneducated opinion, of a presentation function responsible for interaction with the user (display, keystrokes and mouse events, opening and closing files, maintaining the user preferences - RIO already performs most of the critical functions in this list), an editing engine that modifies the given text (selection) by applying (a sequence of) atomic editing functions to it (this, according to my reading of the ACME and SAM documentation is a core function, but it is presently integrated with the presentation) and an interpreter that allows scripting of all the underlying operations (this is the bit I'd borrow from "brief", or "emacs", if anyone feels strongly about it). These components would comunicate using both interprocess communication and various virtual files provided by the file server, which may well be a totally distinct function, quite uncoupled from the the rest. But I'm expecting many different opinions on this score: the perfect editor is full of conflicting requirements and its most important property is that it must be able to satisfy the needs of one user without sacrificing its ability to be customised to a different user's preferences. One can achieve an apparent degree of customisation through configuration files, but only a scripting language can provide a dynamic environment that deals with changing external conditions. Specifically, I'm thinking of the user being able to specify different execution paths depending on different circumstances. Structured Regular Expressions are a powerful editing tool in this context, but their power has some very firm boundaries. I've always appreciated Tcl's idea of embedding the scripting language in the application, it is only its building bricks that I found a little disappointing. I'm expecting that all the original effort that went into ACME will be retained in a future editor. Also, let us not forget the plumber, which ought to be integrated as an important communication channel. And, having been reminded that the plumber has its roots in Inferno, perhaps Limbo ought to be the scripting language of choice. That, or the language implemented by the new Inferno shell. ++L
