-
Notifications
You must be signed in to change notification settings - Fork 200
Future work
- 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.
- 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. Best would be to run highlighting processor in parallel, at lower priority, and be able to interact with buffer before highlighting is available.
- 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.
- Layout code must be shared by frontends.
- Maybe it would be nice to have Qt frontend.
- Should we try terminal libraries other than vty?
- It would be nice to have acme in addition to nano, vim and emacs.
- It would be nice to offer less popular keymaps (CUA, Joe, Mg, Ee) for a beginning user, in addition to nano, vim, and emacs. Which of these we consider ready for public consumption?
- User must be able to switch and edit keymaps at runtime.
It's been a long time since yi was very actively developed. We should re-evaluate our dependencies. For example:
-
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.
-
-
How about text-icu then? We don't want to handle all of unicode quirks ourselves.
-
Is it time to drop Scion and GHCAPI flags?
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.
What tasks have the right difficulty and scope for a GSoC project?