Re: improving Vim - Kickstarter - brainstorming - goals - who wants to join?

Over the past years of working with many tools(from visual studio to vim + tmux
+ zsh) I've built a mental model of what would be the perfect tool for my
work as a programmer/system administrator, so I will share its concepts here
as a means of contributing to the idea. Hopefully this will be helpful and
inspiring to someone.

The perfect editor, which can adapt itself to any workflow and will evolve
naturally with new technologies, should meet the following basic requirements:

- Client-server model from the core, following tmux ideas regarding
sessions/windows.

- Small core written in C. Like Marc Weber, I'm not exactly thrilled by writing
large programs in C, but C is a very simple language that anyone can learn
quickly, and a common denominator on all platforms. Besides the core should be
small(so C is fine) only handling basic things:
- Editor server state(which should be sessions, windows, and buffers)
- API that plugins can use to control the editor state.
- Loading plugins
- Emitting events from the client to the plugins and back to the client.
- API for system tasks like dealing with files(?)

- Handle concurrency/multitasking using event loops which is more
efficient and simple than threading. Personally, I would choose
libuv not only for the event loop, but because it provides a platform
abstraction layer for doing most system tasks. Its the simplest way to write a
concurrent C program that runs anywhere.

- Extreme extensibility based on editor events. Everything that can be a plugin,
should be a plugin. The plugin system should be simple enough:
- Based on dlfcn which works on any POSIX and on windows through mingw
- Plugin discovery done by searching a set of directories for
shared libraries.
- Each library can implement any of the functions defined by the plugin
interface to listen for a particular event.
- Scripting support in other languages should be implemented as external
plugins. Each language plugin is responsible for discovering/loading its
own scripts and delegating events from the core to the
scripts(For an example
of this in practice, see 'weechat')

- Protocol for client/server communication, which should express user
input which
comes from the client and editor output which comes from the server processing
events with plugins.

- UI independent. This is a direct consequence of the client/server model. The
motivation is simple: Longevity. Who can be sure if in the future we will be
using keyboard/mouse to write programs? Its best to use the protocol mentioned
above for expressing things like syntax highlighting, popup windows, user
input... and let the client, which can be written in any language or toolkit
decide how it should be displayed(Maybe in the future someone will write an
UI that uses voice-recognition to avoid typing :)).


As some may have noticed, the above doesn't necessarily describe a text
editor, but a generic framework for building any kind of editor or IDE.

Any feedback is appreciated.

Thiago

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.