The below defines stuff that should be done before actual development of new feature start (to keep the code maintainable, more easily approachable by contributors).
- Remove the dependency on fps (base package has enough)
- Re-factor so the UI module really takes care of all the presentation/terminal specific stuff
- Re-factor the buffer class -- so things really depending on the buffer implementation are in the class.
- Don't throw a exception for switching keymap
- Instead, return a special Action.
- Don't throw a exception for switching keymap
type Keymap = Stream Event () -> Stream Action Keymap data Stream a end = Stream a (Stream a) | End end
- Re-write the FastBuffer so it uses ByteString (or something else) instead of directly the C pointers
- Look at other possibilities for buffer storage; e.g. Simon Tatham has had success using lazily-constructed size annotated 2-3-4 trees for editing >10GB files. 
- Proper rendering of long lines, either (or both)
- line wrapping
- horizontal scrolling
Roughly by order of easy to do / reverse importance.
- Use Yi.Debug to properly log errors to a file. In particular, we should replace calls to "Prelude.error" by something more clever.
- Implement per-buffer keymaps
- Extend per-buffer configuration (to a full emacs-like mode).
- emacs-style minibuffer
- Open multiple windows on a buffer (each with a different point)
- Gtk port
- Invent a system to have annotated buffers (syntax highlight, interactive content)
- GHCi-like interpretation, etc.
(Recent items first)
- Lots of simlifications in the cursor management
- Keymaps can now process typed events instead of Chars (no extra decode step)
- Yi.Debug added for debugging
- Vty backend replaces Curses backend
This section is meant to gather ideas people have for Yi, an extensible editor written in Haskell.
Coming from an Emacs background, the current version of Yi lacks a few things I think are essential, mainly the introspection capabilities of Emacs. One of the main problems is that Yi is based on purely compiled code --- there is little or no interaction with the run-time system.
Ideally, the next version of Yi would be based on a (modified?) version of GHCi, maybe taking advantage of package GHC.
The following are things I like about Emacs, as an extensible environment:
- Really good online documentation
- Emacs can tell you a lot about a function or variable with a keypress--- the current value, where it is declared, and a hypertext formation string
- All (good) apps allow users to extend, through, e.g., hooks --- a list of functions that are run before/after some event (like saving a file)
- It is really easy in Emacs to have one package interact with another. Thus, I can, e.g., insert a new appointment from my mail app into the diary.
- Everything is One Language
- Ignoring the actual language (Lisp!), everything is handled in a uniform language --- from binding keys to writing apps.
- Easy to start hacking
- I can start playing with the system from the second I start up, and things pretty much work as expected. I.e., I can type a bit of code in, execute it, and the result is displayed in the minibuffer. The good docs help immeasurably.
- Written for the frequent user
- Lots of key shortcuts (and famous for it). There are still menus, for those who like em, but you aren't forced to pretend you just started using it.
- A tonne of code
- Well, Haskell has this to some degree. Haskell is (IMHO) much easier to write than ELisp, so maybe people will be encouraged to contribute.
So, why replace it?:
- Dynamically scoped, Dynamically typed, ugly, old. 'Nuff said
- What's a Parser?
- A lot of apps in emacs do stuff with text, usually text that is in some language. There is no standard parser (like, e.g. parsec), so a lot of it is ugly handwritten spaghetti. This also means that adding analysis tools isn't really done (or done nicely).
- ELisp again
- Haskell is a lot cleaner to write, especially because of the large number of libraries.
Emacs maybeness (?)
Some things that are sometimes bad, sometimes good:
- Everything is a buffer
- Makes some sense, but sometimes doesn't. It is nice to have uniform key bindings do the right thing (e.g., C-Space sets the mark, and the region can then be used, e.g. to delete a sequence of emails in Wl) Sometimes, however, you just want some sort of GUI widget.
- OTOH, having the minibuffer be a special kind of buffer is a good idea.
- It is possible to associate arbitrary properties with symbols. This means you can annotate a symbol and then use that information at a later date
What about vi? I believe we want Yi to subsume vi as well.
- Yi should include GHCi
- like emacs includes a elisp interpreter.
- An extension to GHCi to support documentation of symbols.
- This seems to be (reasonably) straightforward, as GHCi already has :info. It would mean hacking the type environment (what about values?) to add documentation information. The main problem would seem to be populating this --- maybe hack haddock to produce something from the library docs? I assume that using package GHC uses the parent RTS (package GHC seems to be the way to go, but more investigation is required --- don?)
- Intermixed compiled/interpreted code
- (for speed/hacking)
- GUI abstraction
- want it to work on terminals as well as X
- Views on data
- Rather than just editing a file, you would open a view onto the file, i.e. there is no longer a 1-1 correspondence between buffers and files. Why? Well, for aggregate buffers (i.e., editing multiple files in the one view), or for multiple views of a file (e.g. AST and source-level). There would be some primitive ops for editing a buffer (insertChar, delete, etc.), which would then call update functions on anything observing that file.
- Remote attach so I can work from home, but still use a remote machine
- Haddock documentation
- (no brainer), maybe associate with .hi files for binaries.
- A class MiniBufferRead (or PromptingRead) which allows the user to
invoke a function similar to M-x in Emacs, but without requiring (interactive)
- -- This is incomprehensibe, would the original author elaborate?
- Maybe a class YiShow, which all config items must be a member of? This is to emulate describe-variable
- Per mode/file/buffer/whatever Monads, or reload/recompile? Or some hybrid? How does this interact with the documentation aspects? Do we want to have separate sorts of symbols a la emacs (describe-function, describe-variable), or is everything a function? I would think that configuration info doesn't change that frequently --- is this globally true though?
- We can probably use a GHCi-like "let". Rebinding a function would then be synonym to assign a variable, thereby achieve unification between functions and variables.
- Interface to the runtime
- The scheduler, docs, etc.
- Introspection of e.g. what processes are running.
- There are already libraries in Haskell for processes, but they don't give Yi any extra information --- we really want a layer on top.
Sjw 09:15, 2 June 2006 (UTC)