As this writing is a collection of my ideas that have not been written down in full before now, this page will be gradually updated and refined whenever I recall or conceive more and more of my ideas concerning the topic and feel the want. In particular, I intend to update this article with illustrations, later.
The Meta-Machine Code interface concept began as a vague notion of machine-assisted creation of machine instructions through reasonably structured use of questioning and whatnot. Among the first examples was, having chosen the instruction, having the system guide operand questioning in a way that prevented invalid such operands from being entered. To provide a concrete example, the peculiarities of ARM literals could be accomodated for in the integer collecting routine in a way that didn't permit an invalid such integer to be entered.
Due to distaste with Emacs' notion of a mode-line and minibuffer, the interface eventually became entirely uniform, with an unimportant number of rows spanning ranges filling the display area. The interface uses these rows to display contiguous regions of memory, with each row containing identity information, such as address and range contents in various bases, and the remainder being available to the meta-machine code for custom purposes, such as displaying the contents of the memory as an instruction for ease of understanding.
The question arose as to where input should be collected, with either a transient area, such as a ``popup window'', appearing for such or the commandeering of a row for such use. The commandeering of a row is simpler in some display primitives and is currently what is being pursued.
Associated meta-machine code routines are run in order, and these could potentially alter previous displayed rows, but this isn't considered an issue, in that the programmer is expected to know how such a feature would be used or abused. The intelligence of the redisplay mechanism has hard repercussions, in that many actions, such as changing a name associated with an address, could affect what has already been displayed; while presumably rare, this raises the question of whether the screen should be redisplayed after each action or not; if not, this raises the question as to what mechanisms should trigger redisplay or if it should always be taken manually. After a range is changed to consume more or less, this must redisplay every following row, but this raises the question as to whether range checking should occur to redisplay only when needed. Ultimately, it is undesirable to maintain a screen buffer to optimize sent changes or to optimize in other ways, and so either constant redisplay or manual redisplay will be used, with a bias towards the former except in cases which discourage this.
As for manual screen redisplay, a traversal command was found to be suitable for this without explicitly creating such a command and so tainting the MMC with such concerns. Along with traversal among the rows and the scrolling of rows through memory, a command for selecting an address was envisioned to be useful and an unoptimizing, and so realistic, version would always redisplay. Having the default address result in redisplay of the current contents nicely solves this.