This page is primarily for recording the conclusions of ongoing design discussions. That is for documenting the internal design of hIDE.
1 Plugins in General
Almost the whole of hIDE will be dynamically loaded, except for a tiny static core which is responsible for bootstrapping the main application and providing a plugin loading service. You can read more about this application architecture in the paper "Dynamic Applications From the Ground Up".
Plugins will be ["Cabal"] packages. This provides a number of advantages over simple object files:
- Provides a build infrastructure
- Allows plugins to depend on each other easily
- Allows plugins to be built seperately or "out of tree"
- Provides useful metadata like author, description, license etc
- Big advantage: anyone who's written a cabalised library potentially has written a plugin for us. All they need then do is work out a gui wrapper (perhaps we should provide a skeleton for this).
2 Base components
2.1 The bootup sequence
3 Project management
- No import overhead. Must work with all Cabal projects without any user interaction.
- Nice interface for running Cabal commands like 'build', 'haddock' and 'test'.
- Management of the meta info in *.cabal.
- GUI independance.
The core editor functionality will be provided by Yi, which provides both a standalone editor along the lines of vi or a stripped down emacs, and also a plugin interface.
5 Dependencies, and plugin structure
darcs get http://haskell.org/gtk2hs/darcs/gtk2hs/
darcs get http://scannedinavian.org/repos/yi/
6 Desirable Plugins
Add more as you think of them:
- The GHC api.
- TeX typesetting (Easier if you have syntax tree available)
- HaRe ( automatic refactoring )
- Darcs ( revision control )
- Pugs ( perl scripting )
- GHCi ( haskell scripting )
- On-the-fly haddockizing?
- Cabal management, a la VH
- Pointless ( Thomas Jaeger's pointfree refactorer)
- Support for construction of QuickChecks
- Ginsu? (very emacs-ish ;)
- Jump-to-definition in standard library
- Spell checking comments
- auto indenting based on pretty printing the syntax tree
- module dep graph as a module browser view
- compilation via ghc-api (with -fasm)
- automatic insertion of type declarations for expressions
- automatic handling of minimal module imports
- talking to external theorem provers, for example, a la ProofGeneral
- alternating background colour based on bracket level as part of syntax highlighting (syntax backlighting?)
- Harmonia (http://harmonia.cs.berkeley.edu/harmonia/index.html), which gives advanced language-aware facilities
7 Division of labour
Notes on who is doing what, and anything that is unassigned:
- develop the UI
- help with misc gtk issues
- config subsystem
- get yi back into 100% functionality (fill out the broken Yi.Core)
- complete yi gui based on gtk (i.e. minibuffers, window splitting etc)
- indenting plugin based on Ppr
- embed ghci
- clean interface to syntax highlighting in Yi,
- get quickcheck tests working with new gtk buffer
- plugin/standalone-neutral access to ui
- Reducing dependences
- pugs plugin for perl scripting?
- look at darcs plugin
- project management / build support / cabal integration
- win32 support. See ["hIDE/Win32"]