However, if you set your ".editor" property to a properly written custom editing function, that function will be used instead of the built-in editor. Since it requires wiz privs to set a reference to a function you do not own, non-wizards will have to change their editor with a command such as the following:
An editor function has the form:
The editor function must examine the msg and state parameters to decide how to process the buffer. It must then return a new state, which will be passed back upon the next entry by the user. "state" may be any datatype, but two return values have special meaning to the POO engine:
Note: if msg is '.x' you must exit with "DONE", and if it is '.q' you must exit with "ABORT". These are enforced by the POO engine; if you don't interpret these messages, the normal save/abort behavior will be invoked regardless. This is to prevent users from getting "stuck" in a custom editor and unable to exit.
If your code raises an exception, it will be caught silently and the built-in editor will be invoked instead. This makes debugging difficult; the only way to debug is to manually invoke your editor, e.g.,
@newfunc me.testEditor( self, buffer, msg, state ) print "in " + str(self) + "'s editor, with ", \ "buffer: ", buffer, "msg: ", msg, "state: ", state # for this ultra-simple editor, the only command we recognize # is "." to exit; anything else is text to append to the buffer. if not state: print "[Cheezy line-entry editor -- enter a period when done.]" return "OK" # we'll use "OK" to mean "ready to accept input" if msg == ".": return "DONE" # <-- special keyword, indicates we're done editing else: buffer.append(msg) print "new buffer:", buffer return "OK" .x @set me.editor = me.testEditor
Python objects don't die as long as any references to them exist. So if you recreate your editor with @newfunc, and other players have references to it, they will continue to use the old code. To avoid this mess, always update an editor function with @edit rather than @newfunc.