Future work

Architecture

• We should get rid of circular dependencies.
• Buffer should know nothing about Windows and let Editor handle all Buffer<->Window interaction. Current Buffer.Misc is a kitchen sink.
• Architecture must allow fast development cycle. Current 'cabal install && :reload' is rather slow.
• We should make it easy to make plugins. From time to time people want to make paredit (syntastic, fugitive, etc.) for yi, but the barrier of entry is too high.

Syntax highlighting

• We must be able to use external tools (haskell-source-exts for Haskell, libclang for (Obj-)C(++), etc.)
• We still want it to be possible to create syntax highlighting from grammars (use case: user has some in-house config file format)
• Rainbow parens!
• Syntax highlighting must be asynchronous (like in xcode, for example), so that slow highlighting doesn't make editing unbearable.
• It must be possible to switch or disable highlighting at runtime, e.g. when editing a huge file or working on a very slow machine.

UI

• Layout code must be shared by frontends.
• Maybe it would be nice to have Qt frontend.
• Should we try terminal libraries other than vty?

Keymaps

• It would be nice to have acme in addition to nano, vim and emacs.
• User must be able to switch and edit keymaps at runtime.

Dependencies

It's been a long time since yi was very actively developed. We should re-evaluate our dependencies. For example:

• Should we move from data-accessor to lens? https://github.com/ethercrow/yi/tree/lens-take2

• Should we move from regex-tdfa to some PCRE library? Regex-pcre branch here: https://github.com/ethercrow/yi/tree/regex Some modern text editors seem to use http://www.geocities.jp/kosako3/oniguruma/

• Should we dump Strings and ByteStrings in favor of Text where possible? (Ropes use Text instead of ByteStrings in my regex branch)

• No! No! No! read this

• Data.Text requires twice the memory utf8: http://blog.johantibell.com/2011/06/memory-footprints-of-some-common-data.html

• long live: utf8-string

• If we are going to compete with mature vi and emacs, we must have THE most memory efficient implementation. So if I open a 20MB utf8 log file my editor better not be expanding it to utf-16 in memory!!!

• If we program to an interface, the regular expression engine should be switchable at runtime. That way, if you want to edit in UTF-16 and use a regular expression engine that only works on utf-16, you still can.

• So in conclusion, the ideal solution is to create an interface that a regular expression engine can implement for a particular character encoding.

• Is it time to drop Scion and GHCAPI flags?

User Experience

There are bunch of things that raise barrier of entry:

• Highlighting is broken for utf8.
• All example configs are monolithic, we should provide a modular one.
• First launch greets user with "Error, no frontend", it should be friendlier.

GSoC

What tasks have the right difficulty and scope for a GSoC project?