|
|
| (252 intermediate revisions by 30 users not shown) |
| Line 1: |
Line 1: |
| | [[Category:Applications]] | | [[Category:Applications]] |
| | | | |
| | + | [[Image:Yi-logo.png]] |
| | | | |
| − | = Yi ideas = | + | == About == |
| | | | |
| − | This page is meant to gather ideas people have for
| + | Yi is a text editor written in Haskell and extensible in Haskell. |
| − | [http://www.cse.unsw.edu.au/~dons/yi.html Yi], an extensible editor
| |
| − | written in Haskell. | |
| | | | |
| − | == Emacs == | + | == External links == |
| | | | |
| − | Coming from an Emacs background, the current version of Yi lacks a few
| + | * Website: http://yi-editor.github.io/ |
| − | things I think are essential, mainly the introspection capabilities
| + | * Repository: https://github.com/yi-editor/yi |
| − | of Emacs. One of the main problems is that Yi is based on purely
| + | * Hackage page: http://hackage.haskell.org/package/yi |
| − | compiled code --- there is little or no interaction with the run-time
| + | * IRC channel: #yi on Freenode |
| − | 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) | |
| − | | |
| − | ;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
| |
| − | (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.
| |
| − | | |
| − | ; 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)
| |
| − | | |
| − | = Development Plan =
| |
| − | | |
| − | == 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).
| |
| − | | |
| − | * Re-factor so the UI module really takes care of all the presentation/terminal specific stuff | |
| − | | |
| − | * Simplify the cursor movements functions
| |
| − | ** Most code/checks should be in Buffer
| |
| − | *** In particular, the point should be managed by the buffer as a normal mark
| |
| − | ** Window should do the least possible cursor-management
| |
| − | ** Core should do no cursor management
| |
| − | | |
| − | *Keymaps
| |
| − | ** Input should be a stream of properly typed events
| |
| − | *** (Currently keymaps take a [Char] as input, with this or that bit set for indication of meta and control. This is somewhat ugly, and certainly lacks a bit of strongness in typing. -> It's impossible to bind C-space, etc.)
| |
| − | **** Reason invoked: Alex support (I think we don't really need this)
| |
| − | **Don't throw a 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 instead of directly the C pointers
| |
| − | | |
| − | * Remove the dependency on fps (base package has enough)
| |
| − | | |
| − | == New Features ==
| |
| − | | |
| − | Roughly by order of easy to do / reverse importance.
| |
| − | | |
| − | * Implement per-buffer keymaps
| |
| − | ** Extend per-buffer configuration (to a full emacs-like mode).
| |
| − | | |
| − | * emacs-style minibuffer
| |
| − | | |
| − | * Open multiple windows on a buffer (each with a different point)
| |
| − | | |
| − | * Gtk port -- stalled: probably bugs in gtk
| |
| − | | |
| − | * Invent a system to have annotated buffers (syntax highlight, interactive content)
| |
| − | | |
| − | * GHCi-like interpretation, etc.
| |
