Difference between revisions of "Yi"
Jump to navigation
Jump to search
(Delete outdated stuff, point to yi website instead) |
|||
| (203 intermediate revisions by 30 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Applications]] |
[[Category:Applications]] |
||
| + | [[Image:Yi-logo.png]] |
||
| − | = Yi homepage = |
||
| + | == About == |
||
| − | http://www.cse.unsw.edu.au/~dons/yi.html |
||
| + | Yi is a text editor written in Haskell and extensible in Haskell. |
||
| − | = NEWS = |
||
| + | == External links == |
||
| − | (Recent items first) |
||
| + | * Website: http://yi-editor.github.io/ |
||
| − | * Vty frontend supports Haskell (lexical) syntax highlighting |
||
| + | * Repository: https://github.com/yi-editor/yi |
||
| − | * GTK frontend works in Win32 |
||
| + | * Hackage page: http://hackage.haskell.org/package/yi |
||
| − | * GTK frontend (in addition of Vty frontend) (requires gtk>=0.9.10.4) |
||
| + | * IRC channel: #yi on Freenode |
||
| − | * 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 = |
||
| − | |||
| − | * Search function seems broken |
||
| − | * GTK: we want point = mark = 0 for new buffers. (fixing) |
||
| − | |||
| − | = Development Plan = |
||
| − | |||
| − | Also read: http://www.cse.unsw.edu.au/~dons/yi/TODO |
||
| − | |||
| − | == Next Release Goal == |
||
| − | |||
| − | The goal for the next release should be decent editing of haskell sources. This includes: |
||
| − | |||
| − | * Reasonable emulation of both emacs and vi(m) |
||
| − | ** Emacs |
||
| − | *** Decent minibuffer for |
||
| − | **** Saving/Loading files |
||
| − | **** Switching buffers |
||
| − | *** Incremental search |
||
| − | *** Search/Replace |
||
| − | *** Correct killword/back |
||
| − | ** Vi |
||
| − | *** would someone care filling in? |
||
| − | * Rudimentary syntax highlighting |
||
| − | * Rudimentary support for indentation |
||
| − | |||
| − | == Test Suite == |
||
| − | |||
| − | The test suite has to be made up to date and re-instated. |
||
| − | |||
| − | == Refactorings == |
||
| − | |||
| − | 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). |
||
| − | |||
| − | * UI |
||
| − | ** Move window list in UI |
||
| − | |||
| − | * Refresh issues |
||
| − | ** Try to do less refreshes. Some modifications of the editor state do not require a full refresh, e.g. CmdLine change. |
||
| − | ** Consider making refresh synchronous: direct call instead of going through MVar. Currently, the tryPutMVar always wakes up the refresh thread instantly anyway, so we have a synchronous behavior (no speed gain) but extra complexity. |
||
| − | |||
| − | * Lexers |
||
| − | ** remove the difference list code and depend on the dlist package |
||
| − | ** port the documentation to haddock syntax |
||
| − | |||
| − | *Keymaps |
||
| − | ** Keymaps for various editor emulations currently each use a different method to describe key bindings. We should uniformize this. |
||
| − | ** Evaluate if we could move to synchronous keymaps |
||
| − | *** Would allow to have less refreshes, and allow to move to a layered components architecture http://www.cs.uu.nl/research/techreps/UU-CS-2002-030.html |
||
| − | **Don't throw an exception for switching keymap |
||
| − | ***don't use metaM altogether; this implies to do all interaction inside some kind of buffer (with its own keymap) |
||
| − | ***or, return a special Action. |
||
| − | type Keymap = Stream Event () -> Stream Action Keymap |
||
| − | data Stream a end = Stream a (Stream a) | End end |
||
| − | |||
| − | * Buffers |
||
| − | ** All the buffer-only code should not modify the Editor state (ie. should work at the buffer level) |
||
| − | ** Regex code should use a Haskell regex library |
||
| − | ** 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 |
||
| − | ** Horizontal scrolling |
||
| − | ** Independent window scrolling (without moving the Point) |
||
| − | |||
| − | * Implement per-buffer keymaps |
||
| − | |||
| − | * emacs-style minibuffer |
||
| − | |||
| − | * Open multiple windows on a buffer (each with a different point) |
||
| − | |||
| − | * Buffers |
||
| − | ** Introduce the concept of an "interactive" transaction, so Undo can work correctly |
||
| − | ** Re-think the Buffer interface/implementation (so it supports encodings, 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. [http://www.chiark.greenend.org.uk/~sgtatham/tweak/btree.html] |
||
| − | |||
| − | * Invent a system to have annotated buffers (syntax highlight, interactive content) |
||
| − | |||
| − | * GHCi-like interpretation, etc. |
||
| − | |||
| − | * Extend per-buffer configuration (to a full emacs-like mode). |
||
| − | ** Evaluate [Implicit Configurations | http://www.cs.rutgers.edu/~ccshan/prepose/prepose.pdf] for customization of the editor |
||
| − | |||
| − | = Yi ideas = |
||
| − | |||
| − | This section is meant to gather ideas people have for |
||
| − | [http://www.cse.unsw.edu.au/~dons/yi.html Yi], an extensible editor |
||
| − | written in Haskell. |
||
| − | |||
| − | == Emacs == |
||
| − | |||
| − | 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. |
||
| − | |||
| − | === 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 == |
||
| − | |||
| − | ;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) |
||
| − | |||
| − | ;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 |
||
| − | |||
| − | == 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. |
||
| − | |||
| − | ... |
||
| − | |||
| − | [[User:Sjw|Sjw]] 09:15, 2 June 2006 (UTC) |
||
Latest revision as of 17:29, 28 June 2016
About
Yi is a text editor written in Haskell and extensible in Haskell.
External links
- Website: http://yi-editor.github.io/
- Repository: https://github.com/yi-editor/yi
- Hackage page: http://hackage.haskell.org/package/yi
- IRC channel: #yi on Freenode