Hi Jürgen - I'm back from a mini-break. The ISO Standard Ch 16 p 239 et seq specifically states "The user makes entries on a keyboard, and obtains responses by seeing them presented on a display- device. The combination of a keyboard and a display-device is intended to represent, abstractly, a terminal. This International Standard does not require the use of any particular terminal, keyboard, display or method of encoding characters. The ISO 2022.2 APL character encoding reproduced in Annex A is widely used. The display-device is considered a window into an unbounded sequence of past entries and responses. The mapping between this unbounded sequence and the display-device is not specified by this International Standard. "
IOW it's implementation defined. Nevertheless APL2 has been mentioned as a sort of de facto standard. IMHO the design for a GNU APL text editing capability ought to be something like this: (1) The default internal editor is an implementation of the APL2 Editor 1 as described in the APL2 Language Reference Manual pp 383-394 et seq. (2) All other text editors are (a) either written in APL itself and thus )LOADable from some library or (b) are external editors, chosen by the user, and interfaced to the interpreter in a standard manner. In particular I think it highly undesirable to have code in the core release to support any specific external editor. Why? Because we should have an as minimal as possible core implementation that meets the standard. Non-lingual extensions should be optional to the core implementation and should interface through the cleanest and simplest possible mechanism. Inclusion should be an intentional activity of the end user. Why? Because once code becomes part of the core implementation users become "addicted" to it and later on it's impossible to remove it - it must be supported forever and constrains future development. This is not a clever design and we see numerous instances of this in the wild. Having an OO paradigm approach is a more preferred way - not necessarily for everything but certainly for interfacing add-ons, plugins, whatever you want to call them. The interface is stable whilst the add-ons can change. So, for example, perhaps we can have a Session Manager Class as well as as well as an Editor Class from which the internal Editor 1 inherits; external editors can also do so even if they need wrappers. As to how the editor interfaces with the interpreter I need to get up to speed with the current situation. Last time I was involved with the internals was ~40 years ago and things have changed - both in the language itself and in the programming paradigms; particularly the Object Oriented paradigm becoming very prevalent these days. More about designing the item (2)(b) standard interface later after I dig deeper. respect Peter
