Thiago de Arruda 2e4ea29d2c events: Refactor how event deferral is handled
- Remove all *_set_defer methods and the 'defer' flag from rstream/jobs
- Added {signal,rstream,job}_event_source functions. Each return a pointer that
  represent the event source for the object in question(For signals, a static
  pointer is returned)
- Added a 'source' field to the Event struct, which is set to the appropriate
  value by the code that created the event.
- Added a 'sources' parameter to `event_poll`. It should point to a
  NULL-terminated array of event sources that will be used to decide which
  events should be processed immediately
- Added a 'source_override' parameter to `rstream_new`. This was required to use
  jobs as event sources of RStream instances(When "focusing" on a job, for
  example).
- Extracted `process_from` static function from `event_process`.
- Remove 'defer' parameter from `event_process`, which now operates only on
  deferred events.
- Refactor `channel_send_call` to use the new lock mechanism

What changed in a single sentence: Code that calls `event_poll` have to specify
which event sources should NOT be deferred. This change was necessary for a
number of reasons:

- To fix a bug where due to race conditions, a client request
  could end in the deferred queue in the middle of a `channel_send_call`
  invocation, resulting in a deadlock since the client process would never
  receive a response, and channel_send_call would never return because
  the client would still be waiting for the response.
- To handle "event locking" correctly in recursive `channel_send_call`
  invocations when the frames are waiting for responses from different
  clients. Not much of an issue now since there's only a python client, but
  could break things later.
- To simplify the process of implementing synchronous functions that depend on
  asynchronous events.
2014-07-17 11:37:42 -03:00
2014-06-12 20:26:35 -04:00
2014-06-23 17:44:12 -04:00
2014-06-19 11:53:57 +02:00
2014-06-30 13:59:56 -04:00
2014-07-08 15:43:04 +02:00
2014-06-12 20:26:35 -04:00

Neovim

Website | Google Group | Twitter | Reddit | Bountysource

Build Status Stories in Ready Coverage Status Coverity Scan Build Clang Scan Build Bountysource

Neovim is a project that seeks to aggressively refactor Vim in order to:

  • Simplify maintenance and encourage contributions
  • Split the work between multiple developers
  • Enable the implementation of new/modern user interfaces without any modifications to the core source
  • Improve extensibility with a new plugin architecture

For lots more details, see the wiki!

What's been done so far

  • Cleaned up source tree, leaving only core files
  • Removed support for legacy systems and moved to C99
    • Removed tons of FEAT_* macros with unifdef
    • Reduced C code from 300k lines to 170k
  • Enabled modern compiler features and optimizations
  • Formatted entire source with uncrustify
  • Replaced autotools build system with CMake
  • Implemented continuous integration and test coverage
  • Wrote 100+ new unit tests
  • Split large, monolithic files (misc1.c) into logical units (path.c, indent.c, garray.c, keymap.c, ...)
  • Implemented job control ("async")
  • Reworked out-of-memory handling resulting in greatly simplified control flow
  • Merged 50+ upstream patches (nearly caught up with upstream)
  • Removed 8.3 filename support
  • Changed to portable format specifiers (first step towards building on Windows)

What's being worked on now

  • Porting all IO to libuv
  • Lots of refactoring
  • A VimL => Lua transpiler
  • Formatting with clint.py
  • msg-pack remote API

How do I get it?

There is a formula for OSX/homebrew, a PKGBUILD for Arch Linux, and detailed instructions for building on other OSes.

See the wiki!

Community

Join the community on IRC in #neovim on Freenode or the mailing list

Contributing

...would be awesome! See the wiki for more details.

License

Neovim is licensed under the terms of the Apache 2.0 license, except for parts that were contributed under the Vim license.

  • Contributions committed before b17d96 by authors who did not sign the Contributor License Agreement (CLA) remain under the Vim license.

  • Contributions committed after b17d96 are licensed under Apache 2.0 unless those contributions were copied from Vim (identified in the commit logs by the vim-patch token).

See LICENSE for details.

Vim is Charityware.  You can use and copy it as much as you like, but you are
encouraged to make a donation for needy children in Uganda.  Please see the
kcc section of the vim docs or visit the ICCF web site, available at these URLs:

        http://iccf-holland.org/
        http://www.vim.org/iccf/
        http://www.iccf.nl/

You can also sponsor the development of Vim.  Vim sponsors can vote for
features.  The money goes to Uganda anyway.
Description
Vim-fork focused on extensibility and usability
Readme 380 MiB
Languages
Vim Script 41.1%
Lua 30.1%
C 27.7%
CMake 0.4%
Python 0.3%
Other 0.2%