Difference between revisions of "Yi"

From HaskellWiki
Jump to: navigation, search
(Delete outdated stuff, point to yi website instead)
 
(120 intermediate revisions by 28 users not shown)
Line 1: Line 1:
 
[[Category:Applications]]
 
[[Category:Applications]]
   
former Yi homepage http://www.cse.unsw.edu.au/~dons/yi.html
 
 
[[Image:Yi-logo.png]]
   
= About =
+
== About ==
   
Yi is a text editor written and extensible in Haskell. The goal of the Yi project is to provide a flexible, powerful and correct editor core scriptable in Haskell. A principle of Yi is that any behaviour can be programmed, so there exist vi, vim, emacs, mg, nano, joe and ee frontends to Yi. Other editor interfaces can be written easily via a parser specification.
 
  +
Yi is a text editor written in Haskell and extensible in Haskell.
   
== The obligatory screenshoot ==
 
  +
== External links ==
   
Gtk frontend:
 
  +
* Website: http://yi-editor.github.io/
 
  +
* Repository: https://github.com/yi-editor/yi
[[Image:yi-20070409.png]]
 
  +
* Hackage page: http://hackage.haskell.org/package/yi
 
  +
* IRC channel: #yi on Freenode
Vty frontend: (upcoming)
 
 
 
 
== NEWS ==
 
 
(Recent items first)
 
 
* Overlays (thanks Ben Moseley)
 
* per-buffer exentsible state (11:44, 28 May 2007 (UTC))
 
* Synchronous keymaps: the behaviour of the keymap (ie. the underlying parser) can depend on the editor state.
 
* Full-dynamic Yi
 
** it's now possible to change any part of the Yi codebase and see the result with a mere 'M-x reconfigE' (take that, Steve Yegge :))
 
* Yi is now hosted on darcs.haskell.org/yi
 
* Dired mode (thanks Ben Moseley)
 
* Yi 0.2 released!
 
* Buffer-specific code is now contained in BufferM monad
 
* Multiple marks per buffer
 
* All keymaps use a unified mechanism! (and are therefore potentially composable)
 
* Miniwindows for vty frontend
 
* 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 (thanks Stefan O'Rear)
 
* 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: matching names can make the window oversized.
 
* emacs: isearch should unset the selection
 
* emacs: buffer set should behave as a stack
 
 
* 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: haskell syntax highlight chokes on {- -} comments
 
* vty: killing the last line of a buffer brings the point to the beginning of the buffer
 
 
* gtk: regexp search is not implemented
 
 
== How to Configure Yi ==
 
 
You can find configuration file examples here:
 
 
http://www.cse.unsw.edu.au/~dons/yi/examples/
 
 
A good start is to copy YiConfig.hs in your ~/.yi directory (create it if needed), and hack as needed.
 
 
To run the gtk frontend, use the "-fgtk" option.
 
 
== 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:
 
 
* Merge yi-lib into the yi package.
 
 
*Keymaps
 
** Evaluate "layered components architecture": http://www.cs.uu.nl/research/techreps/UU-CS-2002-030.html
 
 
* Buffers
 
at the buffer level)
 
** Duplicating Buffer functions at the Core level by wrapping them in withBuffer is ugly
 
** Gtk frontend should not use gtk buffer primitives
 
 
* Nail-down the last remnants of C
 
** C-code don't belong to yi but to low-level libraries
 
 
* Gtk should use the same syntax higlighting code as vty backend.
 
 
=== 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)
 
 
* Open multiple windows on a buffer (each with a different point)
 
 
* have a console that behaves more or less like ghci
 
** prompt
 
** direct evaluation (not only of (EditorM a))
 
 
* cua mode
 
 
* Buffers
 
** Per-buffer specific state. Ideally this should be statically typed and fit the per-buffer keymap.
 
** Do Undo/Redo on the "interactive" transaction boundaries
 
** Re-think the Buffer interface/implementation (so it supports unicode (utf8), better 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]
 
 
== 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, and miss in Yi:
 
 
; 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
 
 
; Hooks-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)
 
 
 
==== 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.
 
 
...
 
 
[[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