Difference between revisions of "Yi"

From HaskellWiki
Jump to: navigation, search
(Delete outdated stuff, point to yi website instead)
 
(127 intermediate revisions by 29 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 ==
   
== The obligatory screenshoot ==
 
  +
Yi is a text editor written in Haskell and extensible in Haskell.
   
[[Image:yi-20070409.png]]
 
  +
== External links ==
   
== NEWS ==
 
  +
* Website: http://yi-editor.github.io/
 
  +
* Repository: https://github.com/yi-editor/yi
(Recent items first)
 
  +
* Hackage page: http://hackage.haskell.org/package/yi
 
  +
* IRC channel: #yi on Freenode
* Synchronous keymaps: the behaviour of the keymap (ie. the underlying parser) can depend on the editor state.
 
* Full-dynamic Yi
 
* Yi is now hosted on darcs.haskell.org/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 :))
 
* 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 Stephan 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:
 
 
*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
 
 
* Nail-down the last remnants of C
 
** C-code don't belong to yi but to low-level libraries
 
 
=== 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]
 
 
* Invent/discover a system to have annotated buffers (syntax highlight, interactive content)
 
** see emacs overlays
 
 
== 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