/* Note:  this file contains rough ideas only.  And they are frequently
   changing, something gets written here several times. */

The nearest:
------------

* Fix `the machine has performed 0 instruction...' message.

* Review all the err_ messages to remove unneeded `\n's.

* Make it to install configuration file into /etc and read it from there.

* Add examples to the `--help' output.

* Add `flags' feature to the error reporting system.

* Add common err_message function in error handling module.

* Find out how to disable static yyunput in generated configuration_scanner.c.

* Fix IO prompts issues.

* Include time information in the -vv output.

* Fix the following:  if I use `c 2000' in gcd_simplest.ram debugging, it
  repeats the command two times, but it doesn't at third.

* Do not show "Breakpoint reached" stuff if we are doing "c" with arg.

* Make a different package from our error and verbosity control modules, they
  have grown to a useful things.

* Implement logging facility in our error processing module.

* Configuration directory at least to make DJGPP release happy about the
  history file.

* Comprise common build and installation instructions and README.CVS into one
  INSTALL.

* Watch the program text file state and ask user if he wants to re-read it
  if it has changed.

* List place of a halt after a halt.

* Actually implement AVL tree and segment merging in ram_memory.c.  NOTE:
  current register lookup time in usual case is O (n^2) !!!

* Fix `continue' with a parameter.

* Add `set' debugger command which will allow to modify RAM memory.

* Add djgpp/README.

* Reorganize the headers.

* the examples have to have legal information too!

* figure out why libtool script isn't created on a build from CVS.

* make interface script for kmp/kmp.ram.

* add possibility to dump contents of a register during the program run.

* the parser shouldn't be sensible to the DOS line ending sequences.

* make `open' command to recognize and interpret the tilde in its paths.

* catch the `SEGV' signal and involve the user to the debugging process :-)
  Other "bad" signals can be processed as well.

* add appropriate commands and possible arguments to the debugger's `open'
  command to have the possibility of input and output redirection.

* add possibility to use comma separator in the debugger display expressions.

* show in the display_instruction function current line number in verbose mode.

* fix `state de' completion bug.

* fix `skipped breakpoints notification' bug.

* make `open' debugger command to re-read the last program if no arguments are
  given to it.

* make the `read' instruction to repeat the procedure rather than bail out with
  error in interactive mode.

* texinfo documentation!  We already have a great number of things to document
  (mainly the debugger operation)  :-)

* deal with incorrect jump/jgtz arguments.
* ignore empty programs.
* fix cleanup problems between 'open's.

* fix 'close/rerun?' prompts.
* add 'delete' debugger command, for breakpoint deletion.
* add 'delete display', for display removing.

* there should be a way to safely interrupt running program, for case
  if it have infinite loops etc.  We could automatically run the debugger
  on Ctrl-C.

* add possibility to set breakpoint by the instruction label.

* We can turn on debugger command line filename completion only for appropriate
  commands, and nothing else.

* add possibility to print or display range of registers by single command.

* make insertion_sort example to work correctly.


To be done before 0.1.0:
------------------------

* rewrite the parser to extend its flexibility.
* write a texinfo manual and a manual page.

* arrange some webpage for the project.

To be done before 0.2.0:
------------------------

* add working smart debug mode command and expression expansion.

* implement user-adjustable hints for READ and WRITE instructions.

To be done before 1.0.0:
------------------------

* Develop a way for defining custom languages for RAM class machines.  This is
  probably very difficult, but having done once this will be great, because
  since that moment everyone can implement his own custom syntax for the machine
  and be happy about it.

* arrange Windows port.

* make a nice logo.

* implement internationalization.  This feature proposes to learn the gettext.

* develop (at least elementary) statistics collecting.

* cool GUI interface.  Itself it is of the least importance, but have to be
  taken into account within the design of the library and the debugger.
  After all, it can be done with ease if the library and the debugger library
  are designed really good, but requires some skill on the GUI programming.

To be done sometimes:
---------------------

* Make simple Pascal- or C-into-RAM compiler.  Its main task should be to make
  human-readable and optimized RAM programs from high-level language
  sources.  This would be good work.  It is very interesting to see how the
  compiler works, and once done this would open easy way 
  to make new RAM programs.

* Add possibility to save session in the debugger.  Maybe this feature is
  not needed at all?  It is just interesting to do it and see how it is.

* Vim mode editing facility on the RAM sources.

* Emacs editing mode would be great too, but I'm not using it.

* Implement ram2c, a tool for converting RAM programs into C program or
  module.  The simple and effective version isn't very tough.

* Implement `DRAM' machine (direct register access, it is used in some theories
  as the simplest device for calculations.  It has only 4 very simple
  instructions, and mainly used as model for computing that models the ability
  of computation itself but not its complexity aspects with respect to real
  systems.

* Implement PRAM class machine emulation.  It would be great too.
