On 12/05/13 21:28, Jan Pobrislo wrote:
On Sat, 11 May 2013 04:45:50 +0200, Tony Mechelynck
<[email protected]> wrote:
1) Add VimL api to hook into the eventloops. The unix poll() eventloop seems
simple enough to start with.
Is it guaranteed to be available? Think MS-Windows or IBM-mainframe.
Nope, neither are some other optional features. What I'm saying here is that
the eventloop that covers significant part of vim installs (terminal on
unix-like platforms) seemed easy enough to hack, so I could start
prototyping on that and then see how it can be transferred to other
platforms.
Generally said, we can not portably handle this on platforms that don't have
filedescriptor handling like this. Luckily, pretty much everybody stole the
BSD socket implementation, so this interface is quite widespread.
It should definitely be more portable than the +clientserver feature, of
which it is functionally superset. (FWIU +clientserver requires either X11
or Windows event queue)
2) Add support for some established eventloop that is already pluggable. I
suspect glib can already be accessed inside gvim. My choice for terminal
glib inside Vim? Again, even when compiled on MS Visual C or on some
z390 compiler? Don't forget that Vim is multi-platform, and that we're
proud of that.
Glib inside gvim, since gtk+ uses glib internally. More precisely glib is
that part of gtk+ that does not deal with gui, so there's no gvim without
glib. (Unless there's implementation of gvim not based on gtk which I'm
unaware of).
My understanding was that glib is the C library included with gcc,
regardless of whether some GUI development package (and which one) is
also installed. As such, glib is not included with MS Visual C which is
one of the most popular C compilers used (including by Bram) when
compiling Vim for Windows. I don't know which C compiler is included on
IBM EBCDIC zOS systems; for all I know it could well be something
totally different (unlike C for zLinux, which is gcc, but running on a
non-Intel-x86-compatible processor). I'm not sure either which compiler
is used on Mac OSX but for all I know it could be some version of gcc.
Additionally, there are several gvim implementations not based on GTK2
(or on the obsolete GTK1) even on Linux, but all of them are compiled
with gcc so I would assume that they are based on glib.
vim would probably be libevent which is highly portable and supported by
libraries of most scripting languages out there (I know of gevent for
python. Perl, lua and ruby should also have one). That way we can have
features working those languages first and then go on with VimL api
as for 1)
For reference, from libevent.org:
Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX
select(2), Windows select(), poll(2), and epoll(4).
...
Libevent should compile on Linux, *BSD, Mac OS X, Solaris, Windows, and
more.
Thanks for reply :-)
Best regards,
Tony.
--
SOLDIER: What? Ridden on a horse?
ARTHUR: Yes!
SOLDIER: You're using coconuts!
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
--
--
You received this message from the "vim_dev" 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_dev" 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.
