Recent Changes - Search:

WikiDoc

Categories

AlphaTclAndModes

Development.AlphaTclAndModes History

Hide minor edits - Show changes to markup

January 23, 2006, at 02:24 PM by 212.180.15.164 -
Added lines 1-134:

(:title 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:

  • (i) Appropriate designs so that a TeX editing mode and the interactive (or non-interactive) handling of a TeX-log can make appropriate use of each other, of word-definitions, syntax colouring, hooks, menus, etc.

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

  • (ii) Allowing a single file to be edited in several modes: e.g. HTML which contains embedded javascript, or even any C, C++, Tcl, Java code which contains embedded comments. Surely those comments should be edited in a more Text-like 'mode'.

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:

  • key-bindings -- anything with 'Bind .... <mode>'

  • menus inserted in the menubar (and other features activated) -- contents of mode::features(<mode>)

  • <mode>modeVars copied into global namespace (including 'wordBreak', 'fillColumn', 'wordWrap' and such critical items), and <mode>::... variables not copied anywhere (mostly paragraph/comment definitions).

  • hooks for the mode (funcs, marks menus, double-click, cmd-click, etc) -- <mode>::variousProcs

  • syntax-colouring -- whatever was registered with regModeKeywords <mode> (which also makes use of the wordBreak definition).

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:

  • It provides some new bindings (and Tcl mode's bindings aren't active --- note some complex caveat with a preference activateBindingsInTclModeOnly which is somewhat weird?)
  • It only colours the prompt and nothing else (probably a bad idea). But, at least we'd want to be able to colour Tcl keywords and colour the Shel prompt.
  • It changes 'wordbreak' (but only to enable colouring of the prompt, I think)
  • It provides its own mode-vars (but very few, and Tcl's aren't active)
  • It takes over a number of hooks (optiontitlebar, carriageReturn, dbl-click (this last is partially routed to Tcl's dbl-click))
  • It changes the paragraph start/end regexp

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:

  • Adds some bindings (easy: setWinInfo bindtags {TclShell Tcl})
  • It colors the prompt (how? -- easiest way is to do it manually, and this avoids colouring non-prompt things too)
  • It modifies wordBreak (easy: setWinInfo wordbreak $wordbreak, but I don't actually think this is necessary)
  • We don't really need any modeVars, and it remains to be seen if Tcl's get in the way.
  • It intercepts certain hooks (easyish: stack hooks into AlphaTcl's hooks mechanism)
  • We need a mechanism to over-ride paragraph start/end by stacked mode (use win::getModeVar, and provide our new versions).

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:

  • accessing <mode>modeVars(*) and <mode>::* vars
  • defining the wordBreak definition (this is an important special case of the previous one, since it is used internally by Alpha's core for colouring and word-movement and double-clicking)
  • calling <mode>::* hooks
  • defining colouring keywords/comments/strings
  • defining which bindings apply to the window
  • defining which other features are active for the window (mode::featueres(<mode>))

In principle, therefore each window has 5 different behaviours:

  • looking up <vstr>modeVars and <vstr>::* vars
  • calling <hstr>::* hooks
  • examining a previous call to regModeKeywords <cstr> .... for colouring information
  • examining bindings created with 'Bind .... <bstr>' for keypresses which apply
  • examing mode::features(<fstr>) for features to activate

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


Category.Development

Page last modified on January 23, 2006, at 02:24 PM
Hosted on SourceForge.net Logo