On Tue, 15 Oct 2013 14:01:16 -0700
/#!/JoePea trus...@gmail.com wrote:
I think you, Paul Evans, would be a good choice for the mentor who
would guide the students through the effort.
I'm not sure that's true because I have no knowledge at all of the
insides of vim. I know terminals, and I know
On Tue, 15 Oct 2013 12:03:41 -0700 (PDT)
ZyX zyx@gmail.com wrote:
2. Second problem is pure technical: someone must sit down and code
this. Maybe use some terminal library, maybe not.
Not wanting to sound like a broken record, but this suggestion is
basically what I keep making every few
I press CTRL-C very infrequently. I'd be willing to give it a try first
without such a feature and see how often I accidentally interrupt timers.
Relying on good chance is much worse than timer plugins in stock vim.
Unreproducible glitches, fuck yeah!
--
--
You received this message from
On Friday, 26 July 2013 06:23:18 UTC+1, Vlad Irnov wrote:
On 7/23/13, Bram Moolenaar b...@moolenaar.net wrote:
Vlad Irnov wrote:
I confirm that this issue has been fixed by Patch 7.4a.027 and
subseqent, but only partially.
The same errors can occur when Python deletes
On Wednesday, October 16, 2013 6:55:11 AM UTC-5, Anton Bobrov wrote:
I press CTRL-C very infrequently. I'd be willing to give it a try first
without such a feature and see how often I accidentally interrupt timers.
Relying on good chance is much worse than timer plugins in stock vim.
Comment #1 on issue 170 by gauchy...@gmail.com: Support for Activestate
perl 5.18.1.1800 on windows
http://code.google.com/p/vim/issues/detail?id=170
The modification of if_perl.xs to work around.
1. Perl_sv_free2:
Perl 5.18.1 introduces a new file lib\CORE\inline.h, which defines inline
Comment #2 on issue 170 by gauchy...@gmail.com: Support for Activestate
perl 5.18.1.1800 on windows
http://code.google.com/p/vim/issues/detail?id=170
The modification of if_perl.xs to work around.
1. Perl_sv_free2:
Perl 5.18.1 introduces a new file lib\CORE\inline.h, which defines inline
On Oct 16, 2013 4:43 PM, Paul LeoNerd leon...@leonerd.org.uk wrote:
On Tue, 15 Oct 2013 12:03:41 -0700 (PDT)
ZyX zyx@gmail.com wrote:
2. Second problem is pure technical: someone must sit down and code
this. Maybe use some terminal library, maybe not.
Not wanting to sound like a
Comment #3 on issue 170 by alaska...@gmail.com: Support for Activestate
perl 5.18.1.1800 on windows
http://code.google.com/p/vim/issues/detail?id=170
Unfortunately this patch does not work with Activestate perl 5.18.1 x64.
Part of error log:
if_perl.c:1916:15: note: in expansion of macro
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 173 by ma...@von-oppen.com: Error R6034 when starting VIM loading
Python dynamically under Windows 7
http://code.google.com/p/vim/issues/detail?id=173
Under Windows 7 (64 Bit) my VIM builds produce an runtime error R6034
On 2013-10-02, 14:33 GMT, ZyX wrote:
1. Function s:GetRelVer does not give any error messages.
2. Yet it does nothing.
Not sure whether this behavior is fine.
It shouldn't matter. s:GetRelVer() is called on line 97, i.e.,
after ver and rel should be set as best as we can set it without
using
On Wednesday, October 16, 2013 10:56:00 PM UTC+4, ZyX wrote:
They do, because s:GetRelVer() is called inside of
s:SpecChangelog() function so they are local to that function.
No. They are local to s:GetRelVer. Only.
It is not python, there are no closures. Function cannot access
They do, because s:GetRelVer() is called inside of
s:SpecChangelog() function so they are local to that function.
No. They are local to s:GetRelVer. Only.
It is not python, there are no closures. Function cannot access variables from
the other function unless they are explicitly passed.
No. They are local to s:GetRelVer. Only.
It is not python, there are no closures. Function cannot access variables
from the other function unless they are explicitly passed.
Err. With python closures you will not get such an effect: function is defined
outside of the scope where “a”
I bet you know enough to be able to figure out fairly easily. :) Also, the
Vim organization in Google Summer of Code can have more than one mentor,
and you guys could work together. I think GSoC would be a really great way
of making this happen.
*/#!/*JoePea
On Wed, Oct 16, 2013 at 5:37 AM,
I think the issue of backwards compatibility should be kept as simple as
possible. Nothing should change in the way that you can currently use VimL
(a.k.a. Vim Script) inside you .vimrc or in any other .vim file.
For example, you can currently do
map tab :echo does something
*or*
map c-i
It wouldn't be unreproducible, nor would it be a glitch. I'd get a prominent
error message if I pressed CTRL-C that I had canceled timers.
Not all users have excellent error message detection skills like yours.
In response, I'd say whoops!, save all my work, and restart Vim.
I'd say 'bloody
Anton,
What do you mean by long running timers? Are you suggesting we look at the
running time of the current timer?
-Matt
On Wed, Oct 16, 2013 at 5:15 PM, Anton Bobrov bob...@vl.ru wrote:
It wouldn't be unreproducible, nor would it be a glitch. I'd get a
prominent error message if I
On Wed, Oct 16, 2013 at 05:24:53PM -0700, Matthew Kaniaris wrote:
Anton,
What do you mean by long running timers? Are you suggesting we look at the
running time of the current timer?
-Matt
Yes, exactly. As far as I understand the implementation dispatcher should know
about
timer's start
You are correct that we trivially know this information. What would you
suggest for the heuristic on not rescheduling? A timer that takes up 500ms
out of every 1000 is also something we'd want to kill.
-Matt
On Wed, Oct 16, 2013 at 5:52 PM, Anton Bobrov bob...@vl.ru wrote:
On Wed, Oct 16,
You are correct that we trivially know this information. What would you
suggest for the heuristic on not rescheduling? A timer that takes up 500ms
out of every 1000 is also something we'd want to kill.
-Matt
IMHO, any kind of bad plugin detection is useless. It's complicate, need
complex
I like the idea for a threshold, but it would be a ton of work since it
would have to use threads and locking and vim isn't thread safe. This is
way more work than I am willing to put in even if it means this patch
doesn't get merged.
-Matt
On Wed, Oct 16, 2013 at 6:19 PM, Anton Bobrov
I like the idea for a threshold, but it would be a ton of work since it
would have to use threads and locking and vim isn't thread safe. This is
way more work than I am willing to put in even if it means this patch
doesn't get merged.
-Matt
Er, threads, locks? We only need to decide to
On Wed, Oct 16, 2013 at 06:49:09PM -0700, Ben Fritz wrote:
On Wednesday, October 16, 2013 8:40:23 PM UTC-5, Anton Bobrov wrote:
I like the idea for a threshold, but it would be a ton of work since it
would have to use threads and locking and vim isn't thread safe. This is
way more
Comment #4 on issue 170 by gauchy...@gmail.com: Support for Activestate
perl 5.18.1.1800 on windows
http://code.google.com/p/vim/issues/detail?id=170
Sorry, I forgot to mention that I was building vim-7.3.1314. :P
--
You received this message because this project is configured to send
Comment #5 on issue 170 by gauchy...@gmail.com: Support for Activestate
perl 5.18.1.1800 on windows
http://code.google.com/p/vim/issues/detail?id=170
Sorry, I've forgot to mention that I was building vim-7.3.1314. :P
vim-7.4 has a different vim.h, which doesn't include perl.h anymore, and
26 matches
Mail list logo
