Difference between revisions of "Yi"

From HaskellWiki
Jump to: navigation, search
(Delete outdated stuff, point to yi website instead)
(236 intermediate revisions by 30 users not shown)
Line 1: Line 1:
= Yi homepage =
== About ==
= Development Plan =
Yi is a text editor written in Haskell and extensible in Haskell.
* Make the source code reference back to this page.
== External links ==
== Refactorings ==
* Website: http://yi-editor.github.io/
* Repository: https://github.com/yi-editor/yi
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).
* Hackage page: http://hackage.haskell.org/package/yi
* IRC channel: #yi on Freenode
* Re-factor so the UI module really takes care of all the presentation/terminal specific stuff
** Window resizes and friends should be in UI (not Editor)
* Re-factor the buffer class -- so things really depending on the buffer implementation are in the class.
** Evaluate if we could move to synchronous keymaps
*** Would allow to have less refreshes, and allow to move to a layered componenents architecture http://www.cs.uu.nl/research/techreps/UU-CS-2002-030.html
**Don't throw an exception for switching keymap
***Instead, return a special Action.
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. [http://www.chiark.greenend.org.uk/~sgtatham/tweak/btree.html]
* Remove OldKeys.hs
== Bug fixes ==
* Fix scrolling bug
** Fuse resetPoint and update
** Fuse merge and refresh (cursor position/scrolling)
* Open file in Emacs2 mode generates an error:
*# Log it properly
*# Fix
== New Features ==
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.
* Window stuff
** Deactivate line-wrap
** Horizontal scrolling
** Independent window scrolling
* Implement per-buffer keymaps
* emacs-style minibuffer
* Open multiple windows on a buffer (each with a different point)
* Syntax hilighting
* Gtk port
* 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).
= NEWS =
(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
= 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
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
; 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)
;GUI abstraction
:want it to work on terminals as well as X
:#Use Stefan O'Rear's vty. for terminal. http://members.cox.net/stefanor/vty/
:#Use gtk2hs for X http://haskell.org/gtk2hs/
;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
:-- 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 ==
; 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.
; 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



Yi is a text editor written in Haskell and extensible in Haskell.

External links