> It's easy to accidentally make a Vim script that consumes all
memory.
If you see this often then you must be running Vim on a machine with
an extremely low amount of memory. This is not the case for most users
though, in the few years using Vim I never experienced this and I use
some pretty hea
Nevermind my previous patch, it will fail for codepoints <= 0x80. The
new patch fixes with a explicit conversion to schar_T before comparing
with ScreenLines[off_t].
On Mon, Jan 5, 2015 at 2:07 PM, Thiago Padilha wrote:
> When using utf-8, the condition to check if the separator ch
When using utf-8, the condition to check if the separator char was
modified in screen_line will always evaluate to true if the char is >
0x80. This is because the type of ScreenLines is unsigned char, so
larger values will only pass the first byte. The attached patch fixes
the problem.
--
--
You
Juan, see this issue: https://github.com/tarruda/vim/issues/5
That means even if you have a 100% stable implementation, embedded
scripting languages that spawn threads may not set their sigmasks(this is a
out of our control), meaning vim's signal handlers can run in spawned
threads causing crashes
On Thu, Jan 23, 2014 at 8:24 AM, Paul Moore wrote:
>
> Do you plan on doing the Windows port? Your example of having a background
> shell looks really useful, and I'd love to play with it, but the patch is
> useless to me unless it works on Windows.
Windows API is very different and I have no
This patch implements a simple but efficient form of job-control for vimscript,
enabling vim to cooperate with long-running processes without blocking the UI.
It is my second attempt to bring multitasking to vim, but unlike the
event-loop/message queue patch, this one does not rely on multithreadi
This file would only be interesting for vim devs
On Fri, Jan 17, 2014 at 12:52 PM, mattn wrote:
> please post it to vim_use instead of vim_dev.
>
> --
> --
> 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 in
Lately I've been hacking vim a lot, and the YouCompleteMe plugin has
been very useful(semantic completion, jumping and syntax errors).
Here's the configuration for other YouCompleteMe users who also happen
to be hacking vim: https://gist.github.com/tarruda/8459816
Hope it helps
--
--
You recei
On Wed, Jan 15, 2014 at 2:23 PM, Ben Fritz wrote:
> So, your background thread is directly calling a function to get user
> input/update the screen? I think THAT is a mistake. This should not happen. A
> background thread can be used for data processing, but any user input, buffer
> changes, sc
On Wed, Jan 15, 2014 at 11:44 AM, Ben Fritz wrote:
>
> I thought the idea of this patch, was to allow background threads to send Vim
> a message, that says "when you get a chance, run function X". Then, at some
> later point in time, when Vim is not busy, it will run function X *IN THE
> MAIN T
On Tue, Jan 14, 2014 at 7:10 PM, kans wrote:
> Thiago,
>
> I am not hopeful for this patch, but I would love to see you succeed. We
> spent around two months working on adding async support to Vim without
> threads, https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J .
> We added
github.com/tarruda/vim), so if anyone wants to try the
fork be sure follow those instructions as the patches posted here are
outdated.
On Tue, Jan 14, 2014 at 8:33 AM, Thiago Padilha wrote:
> On Tue, Jan 14, 2014 at 6:23 AM, Christian Wellenbrock
> wrote:
>> I really like this appro
On Tue, Jan 14, 2014 at 6:23 AM, Christian Wellenbrock
wrote:
> I really like this approach and hope Bram will consider this some day. Just
> wanted to say: Keep up the good work!
Thanks, even if this doesn't get merged I will probably use it as the
starting point of a personal vim fork.
--
--
Today I got some free time and decided to give this patch another try.
I have made a few modifications to the original:
- Rebased against the current master
- Removed the 'defer' function, and added an equivalent to the 'vim'
module in python's bindings. This was needed because I had no way of
kn
Having support for multiple scripting languages would certainly be useful.
One simple way to achieve this would be to follow weechat's take on
plugins(http://weechat.org/files/doc/stable/weechat_user.en.html#plugins)
where each plugin is a dynamic library loaded at startup(eg: dlopen)
by vim's cor
On Mon, Dec 9, 2013 at 4:33 PM, Christian Brabandt wrote:
>>
>> No, and by the time I noticed, it was too late, Vim wouldn't respond
>> anymore. By attaching gdb to the process I saw, that Vim was hanging in
>> the python_end() function, so I think, you are right, python will never
>> exit unless
Christian, thanks for the feedback.
About this issue of vim not responding, did you try to call the Stop()
function of the test plugin? I added this function because python will
never exit by itself unless the background thread is killed.
I'm gonna try the redraw_later tip later, thanks.
Thiago
This patch implements the concept suggested in this
post: https://groups.google.com/forum/#!topic/vim_dev/lylNU4Na2Nk
Heres a simple explanation of whats going on:
- A frozen 'background' thread is started at the beginning of the program.
- At every iteration, the main_loop function will wake tha
On Tue, Dec 3, 2013 at 2:19 PM, Ben Fritz wrote:
> This use case--periodically polling an external process and then taking
> action on results--is a perfect use case for the "timed events" patch a while
> back which was initially given the misnomer "async":
> https://groups.google.com/d/topic/v
19 matches
Mail list logo
