Being at 1163 the highlighting with re=2 is broken for the following use case
(using the attached files):
vi -U NONE -u NONE -i NONE --noplugin -N spanish.txt
gg^
:set re=1
:so lang.vim
6j$a abcESCkok!
gg^
:syn off
:set re=2
:so lang.vim
6j$a abcESCkNOK!
--
--
You received this
Bram Moolenaar b...@moolenaar.net wrote, on lun 10 jun 21:27 :
Patch 7.3.1163
Problem:Not easy to load Python modules.
Solution: Search python2, python3 and pythonx directories in
'runtimepath' for Python modules. (ZyX)
Files:runtime/doc/if_pyth.txt,
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 142 by simplex@gmail.com: GVim for Windows (with Russian
localization) should have default UTF-8 encoding
http://code.google.com/p/vim/issues/detail?id=142
On the present moment GVim have default cp1251 encoding for
Davido wrote:
Bram Moolenaar b...@moolenaar.net wrote, on lun 10 jun 21:27 :
Patch 7.3.1163
Problem:Not easy to load Python modules.
Solution: Search python2, python3 and pythonx directories in
'runtimepath' for Python modules. (ZyX)
Files:
Andrei Olsen wrote:
On Monday, June 10, 2013 12:55:16 PM UTC+2, Bram Moolenaar wrote:
On my work system I ran into problems when trying to build with both
Python 2 and 3.
The first error is:
vim/src/if_python3.c:87: warning: PyString_Check redefined [enabled by
default]
926
Charlie Cooper wrote:
Building 7.3.1157 on an older system
uname -s -r -v -m -- HP-UX B.11.23 U ia64
cc --version -- cc: HP C/aC++ B3910B A.06.14 [Feb 22 2007]
./configure \
--with-features=big \
--with-x\
--enable-gui=auto \
Nikolay Pavlov wrote:
On Jun 10, 2013 8:46 PM, Bram Moolenaar b...@moolenaar.net wrote:
After fixing the crash, I still have test 86 fail with slightly
different output. The first difference is:
--- testdir/test86.ok 2013-06-10 12:42:36.304223000 +0200
+++ testdir/test86.failed
On Tuesday, June 11, 2013 1:33:45 PM UTC+9, v...@googlecode.com wrote:
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 141 by zulolox4...@gmail.com: C-@
http://code.google.com/p/vim/issues/detail?id=141
I could handle CTRL-@ with following patch.
Dominique Pelle wrote:
Using the heap memory profiler 'valgrind --tool=massif vim'
I saw 146,176 bytes allocated from here:
| | -02.03% (146,176B) 0x492B61: do_autocmd_event (fileio.c:8623)
| | | -02.03% (146,176B) 0x4925F0: do_autocmd (fileio.c:8401)
| | | -02.03% (146,176B) 0x46CFDD:
I can't reproduce the error, but
On 2013/06/11, at 1:46, Bram Moolenaar b...@moolenaar.net wrote:
The following differences ones are similar.
so the following simpler test (line 536 of test86.ok) also fails similarly?
Testing *Iter* using d[a] = %s
d[a] = FailingIter():(type
I just ask this question at stackoverflow.com. I was so confused.
http://stackoverflow.com/questions/17041782/vim-startup-with-importerror-no-module-named-ultisnips
On Tuesday, June 11, 2013 3:41:00 PM UTC+8, Davido wrote:
Bram Moolenaar b...@moolenaar.net wrote, on lun 10 jun 21:27 :
On Tuesday, June 11, 2013 5:25:42 AM UTC-5, mattn wrote:
On Tuesday, June 11, 2013 1:33:45 PM UTC+9, v...@googlecode.com wrote:
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 141 by zulolox4...@gmail.com: C-@
http://code.google.com/p/vim/issues/detail?id=141
On Monday, June 10, 2013 8:47:35 PM UTC-5, Hiroshi Shirosaki wrote:
Hi,
I noticed slowness with the following file with Vim 7.3.1163 regexpengine=0.
https://raw.github.com/rails/rails/v2.3.18/actionpack/lib/action_controller/session/abstract_store.rb
rubyPredefinedConstant pattern looks
Hiroshi Shirosaki wrote:
I noticed slowness with the following file with Vim 7.3.1163 regexpengine=0.
https://raw.github.com/rails/rails/v2.3.18/actionpack/lib/action_controller/session/abstract_store.rb
rubyPredefinedConstant pattern looks much slower with this file.
At what position in
Davido wrote:
Bram Moolenaar b...@moolenaar.net wrote, on mar 11 jun 11:46 :
Davido wrote:
Bram Moolenaar b...@moolenaar.net wrote, on lun 10 jun 21:27 :
Patch 7.3.1163
Problem:Not easy to load Python modules.
Solution: Search python2, python3 and pythonx
On Monday, June 10, 2013 8:26:57 PM UTC-5, Andrei Olsen wrote:
Also, though unrelated to this problem, older GCC compilers (version 4) do
not accept -pthread on Solaris, so to add support for multithreading using
the POSIX threads library we need to use -pthreads.
I added a fix for this
ZyX wrote:
Sorry, forgot to hg add new files:
Thanks, that works.
Did you see the other message, that loading a module the old way stopped
working? We should support backwards compatibility, otherwise all
existing plugins that load a Python module suddenly stop working.
--
hundred-and-one
On Wed, Jun 12, 2013 at 12:37 AM, Bram Moolenaar b...@moolenaar.net wrote:
Hiroshi Shirosaki wrote:
I noticed slowness with the following file with Vim 7.3.1163 regexpengine=0.
https://raw.github.com/rails/rails/v2.3.18/actionpack/lib/action_controller/session/abstract_store.rb
On Tuesday, June 11, 2013 3:40:12 PM UTC+4, Jun T. wrote:
I can't reproduce the error, but
On 2013/06/11, at 1:46, Bram Moolenaar b...@moolenaar.net wrote:
The following differences ones are similar.
so the following simpler test (line 536 of test86.ok) also fails similarly?
Testing
All the python files seem located in plugin/UltiSnips, but you
have some subdirs inside it. Here is the tree :
[...]/vim-addon-manager/UltiSnips/plugin/UltiSnips
__init__.py
__init__.pyc
_diff.py
_diff.pyc
_vim.py
_vim.pyc
compatibility.py
compatibility.pyc
Did you see the other message, that loading a module the old way stopped
working? We should support backwards compatibility, otherwise all
existing plugins that load a Python module suddenly stop working.
Was not intended. It appears that currently the only option is to have this
special
Patch 7.3.1164
Problem:Can't test what is actually displayed on screen.
Solution: Add the screenchar() and screenattr() functions.
Files: src/eval.c, runtime/doc/eval.txt
*** ../vim-7.3.1163/src/eval.c 2013-06-10 20:10:40.0 +0200
--- src/eval.c 2013-06-10
Patch 7.3.1165
Problem:HP-UX compiler can't handle zero size array. (Charles Cooper)
Solution: Make the array one item big.
Files: src/regexp.h, src/regexp_nfa.c
*** ../vim-7.3.1164/src/regexp.h2013-06-08 18:19:39.0 +0200
--- src/regexp.h2013-06-11
On Friday, June 7, 2013 12:32:35 PM UTC-5, Andrei Olsen wrote:
On Thursday, June 6, 2013 7:47:56 PM UTC+2, Ben Fritz wrote:
And, it still gets a compile error when checking for sane libraries
unless I remove that check.
I attached the diff I used to get it working, but this isn't a
I will investigate the issue further. Currently I can only say that if I try
to use import with trailing directories in a living system bug does appear
(for python-2* only), but the following tests work in both pythons which is
rather strange:
Problem is not with importing packages, but
Patch 7.3.1166
Problem:Loading Python modules is not tested.
Solution: Enable commented-out tests, add missing files. (ZyX)
Files: src/testdir/test86.in, src/testdir/test86.ok,
src/testdir/test87.in, src/testdir/test87.ok,
src/testdir/python2/module.py,
On Tuesday, June 11, 2013 8:45:04 PM UTC+4, ZyX wrote:
I will investigate the issue further. Currently I can only say that if I
try to use import with trailing directories in a living system bug does
appear (for python-2* only), but the following tests work in both pythons
which is
On Tuesday, June 11, 2013 8:49:11 PM UTC+4, ZyX wrote:
On Tuesday, June 11, 2013 8:45:04 PM UTC+4, ZyX wrote:
I will investigate the issue further. Currently I can only say that if I
try to use import with trailing directories in a living system bug does
appear (for python-2* only),
On Tuesday, June 11, 2013 11:43:30 AM UTC-5, Ben Fritz wrote:
But the sane check still fails. I got a hint from here:
http://mail.python.org/pipermail/distutils-sig/2002-January/002744.html
The problem is in the escaping of the -DPYTHON_HOME flag. I had to REMOVE the
extra \ as in the
ZyX wrote:
Did you see the other message, that loading a module the old way stopped
working? We should support backwards compatibility, otherwise all
existing plugins that load a Python module suddenly stop working.
Was not intended. It appears that currently the only option is to
Patch 7.3.1167
Problem:Python configure check doesn't reject Python 2 when requesting
Python 3. Some systems need -pthreads instead of -pthread.
Solution: Adjust configure accordingly. (Andrei Olsen)
Files: src/configure.in, src/auto/configure
***
On Jun 11, 2013 9:53 PM, Bram Moolenaar b...@moolenaar.net wrote:
ZyX wrote:
Did you see the other message, that loading a module the old way
stopped
working? We should support backwards compatibility, otherwise all
existing plugins that load a Python module suddenly stop working.
Patch 7.3.1168
Problem:Python sane configure checks give a warning message.
Solution: Use single quotes intead of escaped double quotes. (Ben Fritz)
Files: src/configure.in, src/auto/configure
*** ../vim-7.3.1167/src/configure.in2013-06-11 19:53:34.0 +0200
---
Ben Fritz wrote:
On Tuesday, June 11, 2013 11:43:30 AM UTC-5, Ben Fritz wrote:
But the sane check still fails. I got a hint from here:
http://mail.python.org/pipermail/distutils-sig/2002-January/002744.html
The problem is in the escaping of the -DPYTHON_HOME flag. I had to REMOVE
Christian Liesch wrote:
I'm the httest maintainer and wonder if I could contribute my htt.vim
syntax file to the official vim? Is there a way to contribute
or is this the wrong place to ask? If it is the wrong place could you
point me to the right direction.
To have a syntax file
On 11 June 2013 13:54, Bram Moolenaar wrote:
Patch 7.3.1167
Problem:Python configure check doesn't reject Python 2 when requesting
Python 3. Some systems need -pthreads instead of -pthread.
FWIW, Cygwin also needs -pthreads as opposed to -pthread.
Chris
--
Chris Sutcliffe
Davido wrote:
All the python files seem located in plugin/UltiSnips, but you
have some subdirs inside it. Here is the tree :
[...]/vim-addon-manager/UltiSnips/plugin/UltiSnips
__init__.py
__init__.pyc
_diff.py
_diff.pyc
_vim.py
_vim.pyc
compatibility.py
ZyX wrote:
On Jun 11, 2013 9:53 PM, Bram Moolenaar b...@moolenaar.net wrote:
ZyX wrote:
Did you see the other message, that loading a module the old way stopped
working? We should support backwards compatibility, otherwise all
existing plugins that load a Python module
On 11 June 2013 15:09, Chris Sutcliffe wrote:
On 11 June 2013 13:54, Bram Moolenaar wrote:
Patch 7.3.1167
Problem:Python configure check doesn't reject Python 2 when requesting
Python 3. Some systems need -pthreads instead of -pthread.
FWIW, Cygwin also needs -pthreads as
Axel Bender wrote:
Being at 1163 the highlighting with re=2 is broken for the following
use case (using the attached files):
vi -U NONE -u NONE -i NONE --noplugin -N spanish.txt
gg^
:set re=1
:so lang.vim
6j$a abcESCkok!
gg^
:syn off
:set re=2
:so lang.vim
6j$a abcESCkNOK!
On Tue, Jun 11, 2013 at 1:29 PM, Andrei Olsen andrei.ol...@gmail.com wrote:
On Tuesday, June 11, 2013 5:42:08 PM UTC+2, Ben Fritz wrote:
On Monday, June 10, 2013 8:26:57 PM UTC-5, Andrei Olsen wrote:
Also, though unrelated to this problem, older GCC compilers (version 4)
do not accept
The one at the office which also work with httest do use the syntax file
as well as I do of course. It is much easier to write httest scripts
with syntax highlighting. Furthermore it is included in the tar.gz
package as well.
I attached it for you. How is it handled if I do improvments? Just
On Tue, Jun 11, 2013 at 5:18 PM, Ben Fritz fritzophre...@gmail.com wrote:
That pattern contains a few patterns using \@! which can only match one or
two characters before. They should probably be explicitly limited like \@2!.
I think performance of patterns like this is the reason the
Patch 7.3.1169
Problem:New regexp engine: some work is done while executing a pattern,
even though the result is predictable.
Solution: Do the work while compiling the pattern.
Files: src/regexp_nfa.c
*** ../vim-7.3.1168/src/regexp_nfa.c2013-06-11 18:42:28.0
Hi,
Never leave a developer in possession of a profiler ...
So with my setup, nerdtree takes a while to start in large directory of
files, such as VIM's src directory. On Windows the profiler shows a
large amount of time is being spent in the CRT's isalnum(), isalpha()
and islower()
Hi
Using the heap profiler 'valgrind --tool=massif vim'
I saw 135,536 bytes allocated from here:
| | -03.74% (135,536B) 0x43D7D1: dict_alloc (eval.c:6977)
| | | -03.69% (133,816B) 0x43E360: get_dict_tv (eval.c:7471)
| | | | -03.69% (133,816B) 0x43A8AD: eval7 (eval.c:5081)
| | | | -03.69%
same error appears in this plugin
https://github.com/Valloric/MatchTagAlways
2013/6/12 Bram Moolenaar b...@moolenaar.net
Davido wrote:
All the python files seem located in plugin/UltiSnips, but you
have some subdirs inside it. Here is the tree :
On Wednesday, June 12, 2013 12:11:35 AM UTC+9, Ben Fritz wrote:
On Tuesday, June 11, 2013 5:25:42 AM UTC-5, mattn wrote:
On Tuesday, June 11, 2013 1:33:45 PM UTC+9, v...@googlecode.com wrote:
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 141 by
On Wednesday, June 12, 2013 10:48:42 AM UTC+9, mattn wrote:
On Wednesday, June 12, 2013 12:11:35 AM UTC+9, Ben Fritz wrote:
On Tuesday, June 11, 2013 5:25:42 AM UTC-5, mattn wrote:
On Tuesday, June 11, 2013 1:33:45 PM UTC+9, v...@googlecode.com wrote:
Status: New
Owner:
On Tuesday, June 11, 2013 5:11:35 PM UTC+2, Ben Fritz wrote:
On Tuesday, June 11, 2013 5:25:42 AM UTC-5, mattn wrote:
On Tuesday, June 11, 2013 1:33:45 PM UTC+9, v...@googlecode.com wrote:
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 141 by
On Tuesday, June 11, 2013 4:56:08 PM UTC-5, John Wiersba wrote:
I run into several issues when editing/viewing files on a filesystem with
64-bit inodes on vim 7.3 (built from source) on AIX 6.1. I
didn't see any mention of similar issues in the patches list. Have I missed
something?
On Tuesday, June 11, 2013 4:56:08 PM UTC-5, John Wiersba wrote:
--- Options ---
...
compatible key= shellcmdflag=-c ttytype=xterm
I note you have 'compatible' set. Vim behaves much nicer with 'nocompatible',
but I doubt this is your issue. You might give it a
Mike Williams wrote:
So with my setup, nerdtree takes a while to start in large directory
of files, such as VIM's src directory. On Windows the profiler shows
a large amount of time is being spent in the CRT's isalnum(),
isalpha() and islower() internals, coping with locale handling.
With
I used -u NONE so that my configuration would be as simple as possible. I
normally use a custom .vimrc which does not have compatible mode set.
This buggy behavior happens only on AIX 6.1 with filesystems which have 64-bit
inodes. It does not happen on other filesystems or other operating
I just tried updating Debian's packages to 7.3.1169 and ran into the
attached failures for test86.
The first diff is because I run the build using SHADOWDIR=vim-$variant
(e.g., vim-nox). The test either needs to handle that or drop that
specific check.
The other errors I'm not sure about.
On Monday, June 10, 2013 8:47:35 PM UTC-5, Hiroshi Shirosaki wrote:
rubyPredefinedConstant pattern looks much slower with this file.
syntime result:
:set re=0
TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
0.073358 1870 0.0015260.000392
On Tuesday, June 11, 2013 2:50:12 PM UTC-5, glts wrote:
On Tue, Jun 11, 2013 at 5:18 PM, Ben Fritz fritzophre...@gmail.com wrote:
That pattern contains a few patterns using \@! which can only match one or
two characters before. They should probably be explicitly limited like
\@2!. I
On Wednesday, June 12, 2013 12:13:48 AM UTC-5, Ben Fritz wrote:
Isn't that first bit much too complicated? Am I missing something, or is this:
\%(\%(\.\@!\.\)\@!\|::\)\_s*\zs\%(RUBY_...
equivalent to this:
\%([^.]\.\_s*\)\@!\%(RUBY_...
?
Well, it's not quite equivalent. For example
Yes, a) I'm using gvim (this is due an alias: vi=gvim ;-), and b) I forgot one
command; the correct sequence is as follows:
gvim -U NONE -u NONE -i NONE --noplugin -N spanish.txt
gg^
:set re=1
:so lang.vim
6j$a abcESCkok!
u
gg^
:syn off
:set re=2
:so lang.vim
6j$a abcESCkNOK!
You should
59 matches
Mail list logo
