On Tuesday, January 15, 2013 1:15:30 PM UTC-6, Ben Fritz wrote:
On Monday, January 14, 2013 1:07:21 PM UTC-6, ZyX wrote:
Note: options without ? (in my opinion) should definitely be added to the
list.
Before adding options with one ? I should think twice and maybe make
- Ctrl-@ and Nul (0x00). But since a null byte is not permissible inside
a line of edited text in Vim memory (in C, null bytes are string
terminators), nulls in the text are internally replaced by newline
characters (which would not be present because they signal a line
break), hence:
Why is 'confirm' on the list? What problems does it cause in a script, when
Vim would fail, but instead asks the user what to do?
Agreeing here: things I was thinking of when adding to list are easily avoided
using buftype or :{command}!.
'eventignore' also confuses me. Although it makes
Bram,
for some reason or the other, I tried a tiny built. Unexptingly the
configure script found gnome libraries and built a version of vim linked
against the GTK libraries. That was fine, until I hit E325 Message, when
Vim crashed:
(process:25595): GLib-GObject-CRITICAL **:
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 103 by degu...@gmail.com: Python thread are not running in
background
http://code.google.com/p/vim/issues/detail?id=103
Hi,
While trying to fix an issue on clang_complete plugin
Comment #1 on issue 103 by zyx@gmail.com: Python thread are not running
in background
http://code.google.com/p/vim/issues/detail?id=103
Wondering whether it depends on the kind of code that is executed in the
thread. I did successfully launch threads that are only sleeping and then
Comment #2 on issue 103 by zyx@gmail.com: Python thread are not running
in background
http://code.google.com/p/vim/issues/detail?id=103
Similar to the one you linked in
http://marc.info/?l=vimm=110029576819749w=2. And it in fact runs fine
here (vim-7.3.762, amd64).
--
You received
Comment #3 on issue 103 by degu...@gmail.com: Python thread are not running
in background
http://code.google.com/p/vim/issues/detail?id=103
Spawning process instead of thread is not an option in my case…
I just tried with a vim-7.3.762 and can still reproduce 100% of the time. I
should
Comment #4 on issue 103 by zyx@gmail.com: Python thread are not running
in background
http://code.google.com/p/vim/issues/detail?id=103
I also use Python2 for the test, but I use both pythoninterp=dynamic and
python3interp=dynamic on amd64 and AFAIR non-dynamic python2-only builds on
Comment #5 on issue 103 by degu...@gmail.com: Python thread are not running
in background
http://code.google.com/p/vim/issues/detail?id=103
Yes you're right about multithreading. I'm just afraid of the cost of
sending completion results from the completion process.
But anyway, this is
Comment #6 on issue 103 by degu...@gmail.com: Python thread are not running
in background
http://code.google.com/p/vim/issues/detail?id=103
I just tried manually disabling PY_CAN_RECURSE from if_python.c, and the
thread seems to be running in background. In clang_complete the correct
Comment #7 on issue 103 by degu...@gmail.com: Python thread are not running
in background
http://code.google.com/p/vim/issues/detail?id=103
I did find the culprit!
Reverting commit 7f10daa706bb solves the issue (the test-case is correclty
incrementing the variable in background). It also
Christian Brabandt cbli...@256bit.org wrote:
Bram,
I recently discovered, that using equivalence classes in regular
expressions did not match all expected characters. Also I think, the
current implementation does not work as expected, since searching for
[[=Ä=]] does only match Ä and neither
On 15/01/13 20:26, ZyX wrote:
[Tony Mechelynck wrote]
The ^[ in those two termcap entries is not a caret followed by a square
bracket, it is a control-bracket (a single byte) which is one of several
notations for the Esc character. I think you could use
backslash-specials with :let, as follows:
14 matches
Mail list logo
