Difference between revisions of "Yi"

From HaskellWiki
Jump to: navigation, search
Line 9: Line 9:
 
(Recent items first)
 
(Recent items first)
   
* GTK frontend compilable in Win32
 
  +
* Vty frontend supports Haskell (lexical) syntax highlighting
 
* GTK frontend works in Win32
 
* GTK frontend (in addition of Vty frontend) (requires gtk>=0.9.10.4)
 
* GTK frontend (in addition of Vty frontend) (requires gtk>=0.9.10.4)
 
* Linewrap support
 
* Linewrap support
 
* Bugfixes in scrolling
 
* Bugfixes in scrolling
* Lots of simlifications in the cursor management
+
* Lots of simplifications in the cursor management
 
* Keymaps can now process typed events instead of Chars (no extra decode step)
 
* Keymaps can now process typed events instead of Chars (no extra decode step)
 
* Yi.Debug added for debugging
 
* Yi.Debug added for debugging
Line 21: Line 22:
   
 
* Search function seems broken
 
* Search function seems broken
* GTK build broken
 
 
* GTK: we want point = mark = 0 for new buffers. (fixing)
 
* GTK: we want point = mark = 0 for new buffers. (fixing)
   
Line 38: Line 38:
 
** Vi
 
** Vi
 
*** would someone care filling in?
 
*** would someone care filling in?
* Rudimentary syntax hilighting
+
* Rudimentary syntax highlighting
 
* Rudimentary support for indentation
 
* Rudimentary support for indentation
   
Line 54: Line 54:
 
* Refresh issues
 
* Refresh issues
 
** Try to do less refreshes. Some modifications of the editor state do not require a full refresh, e.g. CmdLine change.
 
** 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.
+
** 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
 
* Lexers
Line 63: Line 63:
 
** Keymaps for various editor emulations currently each use a different method to describe key bindings. We should uniformize this.
 
** 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
 
** 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
+
*** 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 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)
 
***don't use metaM altogether; this implies to do all interaction inside some kind of buffer (with its own keymap)
Line 72: Line 72:
 
* Buffers
 
* Buffers
 
** All the buffer-only code should not modify the Editor state (ie. should work at the buffer level)
 
** 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
+
** Regex code should use a Haskell regex library
 
** Duplicating Buffer functions at the Core level by wrapping them in withBuffer is ugly
 
** Duplicating Buffer functions at the Core level by wrapping them in withBuffer is ugly
   
Line 81: Line 81:
 
* Window stuff
 
* Window stuff
 
** Add option to deactivate line-wrap (and truncate lines instead)
 
** Add option to deactivate line-wrap (and truncate lines instead)
*** gtk: attibute textViewWrapMode
+
*** gtk: attribute textViewWrapMode
 
** Horizontal scrolling
 
** Horizontal scrolling
 
** Independent window scrolling (without moving the Point)
 
** Independent window scrolling (without moving the Point)
Line 96: Line 96:
 
** Re-write the FastBuffer so it uses ByteString (or something else) instead of directly the C pointers
 
** 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]
 
*** 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)
 
* Invent a system to have annotated buffers (syntax highlight, interactive content)
Line 207: Line 205:
 
: 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?
 
: 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.
 
: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.
+
:Also possible: use something similar to the GHCi debugger to "tune" the behavior of some functions.
   
 
; Interface to the runtime
 
; Interface to the runtime

Revision as of 08:00, 4 February 2007


Yi homepage

http://www.cse.unsw.edu.au/~dons/yi.html

NEWS

(Recent items first)

  • Vty frontend supports Haskell (lexical) syntax highlighting
  • 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

  • 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
    • Emacs
      • Saving files
      • Incremental search
    • 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
    • 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. [1]
  • Invent a system to have annotated buffers (syntax highlight, interactive content)
  • GHCi-like interpretation, etc.

Yi ideas

This section is meant to gather ideas people have for 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.

...

Sjw 09:15, 2 June 2006 (UTC)