Difference between revisions of "Yi"

From HaskellWiki
Jump to: navigation, search
(Delete outdated stuff, point to yi website instead)
 
(213 intermediate revisions by 30 users not shown)
Line 1: Line 1:
 
[[Category:Applications]]
 
[[Category:Applications]]
   
= Yi homepage =
 
  +
[[Image:Yi-logo.png]]
   
http://www.cse.unsw.edu.au/~dons/yi.html
 
 
== About ==
   
= NEWS =
 
  +
Yi is a text editor written in Haskell and extensible in Haskell.
   
(Recent items first)
 
  +
== External links ==
   
* GTK frontend (in addition of Vty frontend) (requires gtk>=0.9.10.4)
 
  +
* Website: http://yi-editor.github.io/
* Linewrap support
 
  +
* Repository: https://github.com/yi-editor/yi
* Bugfixes in scrolling
 
  +
* Hackage page: http://hackage.haskell.org/package/yi
* Lots of simlifications in the cursor management
 
  +
* IRC channel: #yi on Freenode
* Keymaps can now process typed events instead of Chars (no extra decode step)
 
* Yi.Debug added for debugging
 
* Vty frontend replaces Curses frontend
 
 
= Bugs =
 
 
* Gtk
 
** Mouse selection
 
 
= 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
 
** Saving files in emacs!
 
* Rudimentary syntax hilighting
 
* Rudimentary support for indentation
 
 
== 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 synchrononous behaviour (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 componenents 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;
 
***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)
 
** 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]
 
 
* Syntax hilighting
 
 
* 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 behaviour 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

Yi-logo.png

About

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

External links