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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to