To reproduce:

1. Open a document that does not fit within the Maka display and scroll to the end.
2. Double-click on the last observation, edit it, and click "OK".

When the edit dialog is dismissed, the observation list scrolls to the beginning of the document. It should remain where it was when the edit dialog was invoked.

Maka should offer a basic command interpreter class that can be subclassed to create interpreters for specific applications.

Currently, if when a new document is opened there is no command interpreter available for its document format, the ValueError exception raised by the MainWindow._getCommandInterpreter function is not caught and Maka crashes. It would be better to go ahead and open the document but display an error dialog and disable the command line.

Maka currently formats None field values as "", which is indistinguishable from the empty string. This behavior should be an option to retain Aardvark compatibility when needed, but it should not be the default. By default Maka should format None field values as something that is less likely to collide with other field values. One possibility, for example, is <>. We could avoid collisions in this case with the formatted version of the string "<>" by always including quotes when formatting that particular string, even though it does not include any whitespace.

The Maka preferences facility should type and range check preference values. Perhaps JSON schema could be useful here. Note that the checks will be similar to what we do for observation field values.

The Maka preferences facility should allow comments in preference files by ignoring lines that start with #. This means the file format will not quite be JSON, but I think that's okay. We can parse preference files by first removing comment lines and then parsing the resulting JSON.

The Aardvark editor splits the initial token of a command if the token is not a command name and ends with digits. For example, when given the command "p12" the interpreter first finds that "p12" is not a command name, then splits the token into "p" and "12", then finds that "p" is a command name, and then executes the command "p" with argument "12".

I have never liked this because it is potentially confusing. In the MMRP command set, for example, there are commands "p45", "p90", and "p180", for example, which do things quite different from "p 45", "p 90", and "p 180". It seems odd and a little risky that "p" is treated like "p " for all except when happens to be 45, 90, or 180! In this case the problem is not a big one since pod numbers as large as 45 are not common, but one can imagine other command sets in which the problem would be more serious.

So perhaps the default Maka command parser should not split the initial token when it isn't a command name. If needed we could implement a special parser for the HMMC that performs the splitting.

Maka currently requires pySerial to be installed in order to use the theodolite classes. It would be good to be able to use them without it, but get a warning and dummy data from theodolite reads.

To streamline testing, it should be possible to run all Maka unit tests with a single command. The unit tests for the individual field types (i.e. the tests in modules StringFieldTests, IntegerFieldTests, etc.) are currently run individually because I have not been able to figure out how to run them with nose. Figure out how to do this, modifying the test modules if necessary.

Maka currently does not conform to the Python PEP8 coding conventions in numerous ways. It might be better to conform more or entirely with these conventions.

To reproduce:

1. Open a document.
2. Copy some observations from it.
3. Open a new document.
4. Note that the paste menu item is disabled.

The paste menu item should not be disabled, since there are observations on the clipboard that can be pasted into the new document.

There are currently no commands that create StartPlayback, EndPlayback, SuspectedAffiliation, and SuspectedDisaffiliation observations. It might be best to add such commands.

Currently, the only way to create a new observation is via a command. It might be helpful to allow users to create new observations via observation dialogs as well. The user would somehow choose an observation type and an observation dialog of the appropriate type would appear for them to complete. Presumably we would fill the dialog with default field values. This might mean that we would want to move the functionality provided by the defaultFieldValues command class attributes somewhere else. We might, for example, associate the default field value information more directly with observation types rather than attaching it to command classes.

Maka preferences are currently specified as a JSON string in the Preferences module. They should instead be specified in a JSON file in a platform-dependent directory.

Allow the user to control the command line and observation list font size via a preference.

The current command interpreter/command interface could probably be improved. For example, it might be possible to simplify and perhaps unify the mechanisms (such as callable default field values and field value hooks) through which field values are set when commands are executed. Think about this issue and implement any improvements that come to mind.

The extensions included in Maka are currently hard-coded in the ExtensionManager module. Adopt a real plug-in mechanism and separate the Maka source code into a core and plug-ins that are discovered and loaded by the core. The core should have no prior knowledge of the plug-ins, only knowledge of how to discover and load them.

Maka should offer an Aardvark compatibility mode that is enabled via a preference. In this mode Maka will write files that Aardvark can read. This mode will not be enabled by default, and Maka will write files in a format that is not compatible with Aardvark.

It might be desirable for the Aardvark compatibility mode to alter other behavior, such as the token used to denote a field value of None.

Currently, all Maka extension modules are imported when the extension manager is initialized. The initialization is lazy in the sense that it isn't performed until the first call to ExtensionManager.getExtension or ExtensionManager.getExtensions. However, all extension modules are imported at initialization, regardless of whether or not they are actually used. It would be better to import each extension module when and only when it is used.

This begs the question, though, of how we will know what extensions are available if we don't import them. The answer might be that some sort of lightweight plug-in manifest loaded at initialization would describe the extensions included in a plug-in, but the bulk of an extension would not be imported until the extension is actually needed.

Currently, instances of the SimpleCommandInterpreter class try to split the first command token into a command and an integer if the token is not itself a command. The default behavior should be to not split tokens, but it should be possible to enable splitting via a preference.

When a command template refers to a nonexistent observation field (e.g. 'c bobo'), the _Command._checkFieldNames method raises a CommandInterpreterError that is not handled. Such an exception should be caught and an appropriate error message displayed in a dialog. If possible, processing of command definitions should continue after the error.

TextUtils.tokenizeString currently tokenizes '"One"2' to ["One", 2]. It should instead raise a ValueError since there is no space between the "One" and the 2 in the input.