Revision as of 15:46, 22 January 2006
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. That is the project management API exposed to other hIDE components should not depend on the GUI.
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 --partial http://darcs.haskell.org/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"]