From AlphaWiki

Development: AlphaTclAndModes

What is a mode? Something for editing a particular kind of file? Then what are Shel, Diff, Brws, Inst, etc?

There are two possibly related issues that it would be good to resolve and improve to take Alpha(tk) a significant step forward:

More comments on this issue and a first approximation to a proposal can be found on the page Modes.ModesAndStates <JK Dec2003>.

For some loose comments, see Development.GuestModes? <JK Dec2003>.

The difficulty here really is to specify a robust, coherent design which makes sense for these situations. Once such a design has been specified and agreed as sensible, we can then work out how to make Alpha(tk) and AlphaTcl adhere to it.

This page is, therefore, for the specification of such a design....

First, a list of the current uses/properties of a 'mode' at present:

It seems clear that we can stack bindings, menus and hooks quite easily (i.e. we can have multiple modes/states active at the same time in the sense that multiple sets of bindings, menus and hooks can be activated provided a known priority of modes/states is defined. Stacked bindings would require core Alpha(tk) changes, but menus/hooks would be in AlphaTcl only). Somewhat harder (but quite possible in AlphaTcl) is the ability to copy multiple sets of modeVars into the global namespace at once (again this would have to be in a prioritised fashion so that we can resolve conflicts appropriately). It is pretty clear that only one set of syntax colouring can be applied to any single segment of text (although we might be able to apply different colouring schemes to different parts of the window, with a core change). On a slightly more atomic level, it would be possible to extend syntax colouring to, say, make use of word-lists from multiple modes/states (again a core change). However it is probably best to assume there would only ever be a single set of basic definitions of comments, quotes, word-breaks active for any single segment of text.

It is interesting to ask what aspects of Alpha(tk)'s core and AlphaTcl control or make use of which of the above five properties. The primary core role for 'mode' is in defining syntax colouring and key-bindings. In fact key-bindings are controlled by the global variable $mode, and syntax colouring should be controlled by each window's mode (in Alphatk this is correct, but in Alpha 8/X I'm not sure if this works properly for non-front windows, which would be a bug). Everything else could be in AlphaTcl (presently there are a few entanglements with Alpha(tk)'s cores, but those can all be removed). So, with small changes to Alpha(tk)'s cores, a window's colouring 'mode' could be over-ridden, and the keybindings active could be determined by a different global variable than $mode (perhaps a prioritised list of binding-modes?). Finally, we come to the three other areas: menus/features, <mode>modeVars and hooks. Again each of these three (but now just in AlphaTcl) can easily be extended. We can easily have the activated/deactivated menus/features depend on a 'feature-mode-list' rather than just one, and we can make anything which calls hooks call through a prioritised stack of hooks depending on a 'hook-mode-list'. Finally 'changeMode' is the only function which cares about the copying of <mode>modeVars (although globalVarSet, globalVarIsShowed also have results which depend on the current mode), and it could easily copy over several arrays of variables from a 'variable-mode-list' (alternatively, all access to key AlphaTcl variables could occur through a prioritised 'variable-mode-list'). So, as we can see, Alpha(tk) + AlphaTcl are actually not that far from being totally flexible with regard to mode-composites. The question really is: what composites do we want and need? How do we control them? In complete generality, every window could have its own keybinding-mode-list, feature-mode-list, variable-mode-list, hook-mode-list and colouring-list. But, is this what we really want?

Second, what are the desired composites of the above properties for the uses we envisage. There are at least three or four clear uses:

TeXL is a TeX-mode and console combination

What does this need? TeX colouring, process menu (which is needed by TeX and TeXL), bindings -- from console only?


Shel is a Tcl-mode and shell combination

Shell mode is just Tcl mode + what? Well...

It even uses 'set completionsLike(Shel) Tcl' to tell the completions mechanism that it is like Tcl mode, so that's a good start. The differences from Tcl mode are:

That's it, really. So we could re-make Shel mode as a function 'tclShell' which creates a new window in a composite mode (Tcl+TclShell) where TclShell does the following:

So, it looks as if we can remove the completionsLike, remove the wordBreak over-ride, remove the special fake comment definitions which serve to colour the prompt, and only add some very simple stuff. This suggests that we are off to a good path, in that this approach actually allows us to simplify things...


The above are cases where a single window has multiple modes/states associated with it as a whole. Can we view this as a primary mode and a number of associated states? (a default 'editing' state which perhaps doesn't need to be specified, and alternative 'console' and 'shell' states which override certain aspects of the primary mode).

HTML mode contains embedded Javascript


Tcl code contains embedded textual comments


These are cases where a single window contain different textual segments each of which has different associated modes).

What is a mode?

This section is a draft of what could, eventually, go into Extending Alpha once all of this functionality and terminology and appropriately defined and clarified. It currently only applies to composite modes and not to guest modes which need further analysis and development. One of the main difficulties is deciding on the right words and terminology for all this.

A mode is what AlphaTcl associates with each window, and which appears in the mode-popup menu in the status bar, and which is used as a default for the following behaviours:

In principle, therefore each window has 5 different behaviours:

So, there are five strings: vstr, hstr, cstr, bstr and fstr, which can be used to look for information relevant to these different operations. In Alpha as of 2003, all of these strings are just $mode and there is no ability to over-ride them. However, in Alpha as of 2004 we are close to a situation where each of these 5 strings can be over-ridden for any individual window. In fact, going further, we are close to being able to over-ride each of them with an ordered list of strings each of which will be searched in turn until a match is found. On way of doing this, for example, (in Alphatk only at present) is to do setWinInfo bindtags {extra} which will make a window only use bindings defined with the tag 'extra'. One could also do setWinInfo bindtags {extra Tcl} which would look for bindings first defined with 'extra' and then with 'Tcl'.

In Alphatk at present (Windows only until next OS-X release), vstr, hstr, bstr, cstr and fstr are all stacked in this fashion (i.e. they're taken from prioritised lists).

Of course, this flexibility could be used in a totally chaotic fashion, to define totally weird modes, but the point is that this should only be used in sensible ways. The fact that the default for all behaviours is the old $mode makes everything quite simple, really. Joachim pointed out, quite correctly, that the flexibility provided by having all 5 of these totally free is effectively an API which can be used by the rest of AlphaTcl to define what it considers a sensible definition of a mode and a mode + other attributes/states.

Once all of this is in place, current modes like Brws, Shel will almost certainly disappear from the popup-mode-menu, and simply become behaviour modifiers for real modes. (I expect that Diff, InSh, mpws, and possibly others will also disappear, but I haven't analysed those).

One open question is how to display to the user the fact that a given window is not in a pure mode state, but has certain modifiers associated. E.g. it's confusing if a window is in Tcl mode + Shell modifiers, but the mode popup says "Tcl" and nothing else gives any indication of the modification status. Perhaps the easiest would be just to have, to the right of the mode popup, a textual label listing the modifiers: Tcl,shell

A first step to clearing some of this up is that we might want to actually place a flag in the window structure for windows which are not associated with editing a file (for example, Shel, Diff and Brws windows) indicating that they are not editing windows. Currently we base this decision on the window title.

Vince adds that he doesn't think this is directly relevant to this discussion. I might want to open a .patch and be in Diff mode, for example, and I might have a new window which I intend to save to file in the future, but isn't yet associated with a file.

On the issue of multiple modes in a single file (for example, JavaScript embedded in a HTML page), to be useful, this would require storing more metadata in the file, indicating which lines are associated with which mode. I don't think we can teach Alpha to automatically deduce what mode we want each line to be in and re-assigning lines to modes would be a real pain.

TeXL mode as originally conceived by me is probably not the way to go (I would TeX in batch mode then do a batch find on the log file and then manually jump to the errors). The early TeXL modes were based on that workflow (something I had been doing for years). I think that what is more useful is what Joachim is doing: scanning a log file; generating a browser window filled with errors and using Brws mode to jump to the errors. Coming up with a good Brws mode (one that allowed each browser window to store a local copy of all its variables instead of using the global values) would greatly help with this. The second aspect I would like would be the ability to access TeX commands while this mode was on top. Now that each Brws mode window supports its own data, we could have the TeX menu added for this browse window (but not as a global Brws mode feature so that it wouldn't appear after a batch find). Alas, this doesn't solve the problem: when I request to TeX a file with the error browser on top, I want to TeX the last file I TeXed, not the front window. This might be fixable within TeX mode. For instance, if TeX mode understands that attempting to TeX a console window should result in the command applied to the previously TeXed file.

agm Feb102004


Retrieved from
Page last modified on January 23, 2006, at 02:24 PM