<br />
<b>Deprecated</b>:  The each() function is deprecated. This message will be suppressed on further calls in <b>/home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php</b> on line <b>456</b><br />
First, read:
         http://haskell.org/haskellwiki/Yi

Refactorings/Frameworks:
        - ui type class
        - hot swappable user interfaces

Emacs modes:
        - should always show the modeline (or minibuffer)

Vim mode:
        - undo interferes with :w :q
        - empty tmp files don't complain when you try to write them.
        - 0 in vim mode is ignored.
        - tab completion.
        - flavours of s///
	- visual mode
	- visual line mode
        - range syntax, including '<,'> for beginning and end of visual mode.
        - performance issue on very long lines. (C fragment?)
        - path names not expanded in :e
        - :!cmd , run an external command not implemented
        - deal with delay after hitting esc from command mode.
        - undo should coalesce so that dl is undone all at once.

Darcs support:
        - what interesting things can we do with integrated darcs
          support?

Undo:
        - overwrite is not properly supported
        - emacs-style undo
        - other forms of undo
 
Build system:
        - check how to install it from a port script
        - think about how to do a testsuite, unit testing
                + icfp05/stefanw-style

Presentation/Rendering:
        - windows need to be wrap or nowrap.

other stuff:
	- compilation errors from make() go to stderr (and screw up the
	  window). 
	- the unChanged test doesn't seem to be accurate. what's up with
	  that?

        - :eval, :type, .. etc. ghci stuff
        - make the cmd line a buffer.
        - start drawing buffer before it is all loaded. (ie. load buffers lazily)
        - either generalise registers, or make them entirely keymap-local
        - errorE should display in colour

        - closing window and terminating on OSX produces infinite loop?

------------------------------------------------------------------------
Syntax Highlighting -- Ideas parallel to the current one:

        - run a parser in background thread (of Parser class), producing a syn tree

        - abstract syn representation
            - produces syntax colouring ppr (not general ppr)
            - hints for layout (on \n, for example)

        - so we're mostly direct editing, and updating the syn tree
          where possible.

        - so how to take a syn tree and flatten it to produce a drawable buffer?
            - can we deparse it directly?   
            - or can we consult the abs syn tree, as we draw each buffer line?
                - walk the parse tree, drawing chars from the buffer in
                  the colour specified by the tree.

        - need correct position information in syn tree, to colour
          tokens. comments aren't stored in the syn tree, so how do we
          colour them?
            * Centaur records comments in the lexer, with their locations.
              Then using location information in the syntree, hook
              comments back in.
          - what about comments?
              - record the comments, with their positions, in the lexer.
              - re-splice comments back into the parse tree.

        - set of token classes?

        - need multiple entry points to the parser, to reparse subexpressions?
            - ==> Centaur (for ML) has a good system.
              ftp://ftp.inria.fr/INRIA/publication/publi-pdf/RR/part3/RR-3139.pdf

            - alredy available in Happy parser for GHC, via the %name
              directive, for:
                - parseModule module
                - parseStmt   maybe_stmt
                - parseIdentifier  identifier
                - parseIface iface
                - parseType ctype

        - can keep track of points to start reparsing from. see
          vim:syntax.c- syntax state stack cache

        - need to map tokens to attributes.

	- good overview to structure editors
             http://www.cs.uu.nl/research/projects/proxima/

------------------------------------------------------------------------
regexes:

        - how do we handle all the different editors regex languages?
            - do they have to compile down to a core regex language,
              before calling searchE?