Hrvoje Niksic wrote: i did something like this: - add a lisp frame property `frame-number' for the "order count". - the tty frame sets its name to be `F%d' where %d is the order count, unless a name was explicitly given. this follows what FSF does. - i extended the modeline spec so that it in the place where you have a symbol whose value controls whether something gets shown -- basically a simple if/then/else -- you can use a boolean specifier as well as just a symbol. That boolean specifier can be set up so that it's t on tty frames whose frame-number property is > 1, and false elsewhere. [i just use a create-frame hook to set the correct value for each frame, but it occurs to me all i need to do is set the value true on global + tty, and then false on the first frame. but whatever]. - so basically by using specifiers you can get any sort of behavior that's conditionalized on frames, devices, windows, buffers, etc. - i also thought about extending specifier device tags so that there can be specifier frame tags; this would make it really easy to do the above kind of stuff. - but what really just needs to be done is allow elisp in the modeline spec. i already have done all the necessary work making this possible, and it's sitting in my stderr-proc workspace, waiting to be integrated. [that may be the next thing i want to tackle, since it's got lots of useful stuff, not least a total redesign and rewrite of the call-with-error-checking functionality with a specific aim of allowing for running code during redisplay. that stuff -- and in fact, everything in the ws -- is pretty much done. ben

"Stephen J. Turnbull" wrote: yes, i agree. however, we need to clean up the way modes are defined. we do have define-derived-mode, but nothing that's just define-mode. instead, modes do a bunch of "standard" things, which makes it impossible to improve the mode machinery. btw the way to do this in an fsf-compatible way already exists -- the compat.el program i wrote, in the distribution. i'll merge it after the mule stuff.