Yi
Yi homepage
http://www.cse.unsw.edu.au/~dons/yi.html
The obligatory screenshoot
NEWS
(Recent items first)
- Miniwindows for GTK frontend
- Basic support for query-replace (emacs)
- Rudimentary support for indentation
- Syntax highlighting in GTK frontend (using SourceView)
- Completion for file names
- Incremental search (emacs)
- Completion for M-x, and buffer switch.
- History for emacs mode minibuffer
- New commands and keybindings can be defined easily and dynamically
- Yi is an haskell interpreter!
- Possibility to run editor actions interactively (similar to emacs M-x)
- Configuration is just a haskell module exporting (yiMain :: Action)
- Possibility to evaluate haskell expressions interactively.
- New, unified way to define Keybindings
- Vty frontend supports Haskell (lexical) syntax highlighting
- GTK frontend works in Win32
- GTK frontend (in addition of Vty frontend) (requires gtk>=0.9.10.4)
- Linewrap support
- Bugfixes in scrolling
- Lots of simplifications in the cursor management
- Keymaps can now process typed events instead of Chars (no extra decode step)
- Yi.Debug added for debugging
- Vty frontend replaces Curses frontend
Bugs
- vi: delete (d) seems broken
- emacs: Incremental search behaves funny when failing to match.
- emacs: file completion can fail if the directory does not exist (fixing)
- emacs: matching names can make the window oversized.
- emacs: saving a file doesn't mark the buffer "unchanged" (fixing)
- vty: home,end: keys are not correctly supported
- This is a vty library problem. sorear: it works fine on the linux console but fails to handle $TERM. (vty 3.1 will wrap ncurses)
- vty: minibuffer windows are normal windows
- vty: haskell syntax highlight chokes on {- -} commments
- vty: killing the last line of a buffer brings the point to the beginning of the buffer
- gtk: regexp search is not implemented
- gtk: impossible to focus the cmdline
Development plan
Also read: http://www.cse.unsw.edu.au/~dons/yi/TODO
Test suite
The test suite has to be made up to date and re-instated.
Build test: regular, gtk, and haddock html doc should be buildable at all times.
Refactorings
The below describes possible refactorings to investigate:
- Keymaps
- Evaluate if we could move to synchronous keymaps
- Would allow to move to a layered components architecture http://www.cs.uu.nl/research/techreps/UU-CS-2002-030.html
- Evaluate if we could move to synchronous keymaps
- Buffers
- All the buffer-only code should not modify the Editor state (ie. should work at the buffer level)
- Duplicating Buffer functions at the Core level by wrapping them in withBuffer is ugly
New features
Roughly by order of easy to do / reverse importance.
- Window stuff
- Add option to deactivate line-wrap (and truncate lines instead)
- gtk: attribute textViewWrapMode
- vty: horizontal scrolling
- Independent window scrolling (without moving the Point)
- Add option to deactivate line-wrap (and truncate lines instead)
- Open multiple windows on a buffer (each with a different point)
- have a console that behaves more or less like ghci
- Buffers
- Do Undo/Redo on the "interactive" transaction boundaries
- Re-think the Buffer interface/implementation (so it supports unicode (utf8), marks, etc.)
- 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. [1]
- Invent/discover a system to have annotated buffers (syntax highlight, interactive content)
Yi ideas
This section is meant to gather ideas people have for Yi.
Emacs
Coming from an Emacs background, I think a few things are essential, mainly the introspection capabilities of Emacs.
Emacs goodness
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
- Extensibility
- 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)
- Integration
- 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.
Emacs badness
So, why replace it?:
- ELisp
- 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.
- Properties
- 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
Vi ?
What about vi? I believe we want Yi to subsume vi as well.
Ideas
- 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?)
- 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 means that given f :: String -> Int -> Action, (makeInteractive f) :: Action would prompt the user for a String then an Int and run the corresponding action.
- Maybe a class YiShow, which all config items must be a member of? This is to emulate describe-variable
Implementation
Considerations:
- Configuration
- 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.
- Also possible: use something similar to the GHCi debugger to "tune" the behavior of some functions.
- 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)