Re: [PATCH] fix broken Python3 support
On Tue, Jun 14, 2011 at 06:06:51AM +0200, Bram Moolenaar wrote: Thanks for the update. I'll check it out later. I have this remark in the todo list, I suppose this patch is fixing it: Python3 interface doesn't handle utf-8 correctly? (Nov 2010, lilydjwg) Yes. -- Best regards, lilydjwg Linux Vim Python 我的博客 http://bit.ly/lilydjwg or http://goo.gl/y4Gsy -- 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
Re: Requests
Adrien Axioplase Piérard wrote: Hello, 2011/6/14 Ben Fritzfritzophre...@gmail.com: Am I correct in my understanding, that your file .vim/after/syntax/ tex.vim, has a line like: let g:tex_conceal='agm' ? If so, then your problem is in assuming the g:tex_conceal option works like built-in Vim options like 'wrap' or 'guifont' Yes, I feel a bit ashamed, now you point this out :) May I point out that, instead of using :e you could use :set ft=tex and that will re-initialize the syntax (without re-loading the file). Regards, Chip Campbell -- 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
Re: [conceal] Requests
Adrien Axioplase Piérard wrote: I would like to express some regrets regarding this extremely useful feature, and thus plea for some enhancements, should anyone capable of coding them read this. Hello, If I may ask, how did you find out about it? I suspect that there's a lot of LaTeX users out there that would like to use the conceal feature but don't know about it. Regards, Chip Campbell -- 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
Re: Mercurial Workflow: Feature seperation via named branches
On Wed, Jun 15, 2011 at 12:51 PM, Matt Mackall m...@selenic.com wrote:
2011/6/15 mercurial-requ...@selenic.com:
Also, I think you underestimate how badly things can go algorithmically
for people who are not aware that particular things aren't designed to
scale. For instance, we've had people who've tagged essentially every
commit in a 100k cset repo. That's simply not going to work well and
we're not going to be able to tweak things so it does.
I'm curious about what problems might arise from tagging nearly every
commit. For instance, Vim is maintained in Mercurial at
http://code.google.com/p/vim , and each new patch added is tagged with
the patch number. What specific problems might occur from this
practice?
Slow startup for any command that needs tags info is the primary risk.
This is cached now so it's generally fast, but the cache will need to be
rebuilt at each tagging point. You probably won't see any pain here for
a long time.
You seem to have an unusual model:
changeset: 2891:acda456c788a
tag: v7-3-219
user: Bram Moolenaar b...@vim.org
date: Mon Jun 13 02:04:00 2011 +0200
files: src/os_mac_conv.c src/os_macosx.m src/version.c src/vim.h
description:
updated for version 7.3.219
Problem: Can't compile with GTK on Mac.
Solution: Add some #ifdef trickery. (Ben Schmidt)
It seems like you bump the version number in version.c on basically
every change, then tag it as a release.
Yes, this is the case. It is somewhat strange (especially in the
open-source world) but it is what it is. Bram is the
benevolent-dictator-for-life of Vim and still maintains it by
accepting patch files from Vim community (in pretty much any format
but normally in Mercurial's nowadays) and then releasing each coherent
change as a patch which he also happens to apply and keep in
Mercurial. The nice thing is that within Vim's internal scripting
language you can check for not only a specific version but also a very
specific patch level using something like v:version == 703
has('patch219') for the specific changeset you quote. Due to this
release strategy, it's convenient to be able to refer to specific
changesets by version ID. But since there are not a bunch of
intermediate changesets, tagging each one still only results in a few
hundred tags per major version, rather that the hundreds of thousands
you indicated would cause a problem.
--
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
Re: CCTree feature request and question
I included vim_dev due to the crash. This is using the CCTree plugin
available on vim.org:
On Wed, Jun 15, 2011 at 4:16 PM, Benjamin Fritz fritzophre...@gmail.com wrote:
On Wed, Jun 15, 2011 at 4:05 PM, hari.rangara...@gmail.com
hari.rangara...@gmail.com wrote:
version 1.51 with enhanced symbol processing enabled should get what you
want because of the second pass it does to catch out on symbols cscope
missed out.
Cool, I'll need to try it out when I find a function cscope fails on.
I wasn't expecting it to already be working!
I downloaded 1.51, and got a weird error message. I narrowed it down a little:
First, I did a :cs add of 3 databases.
Then, I did a CCTreeLoadDB with the first database. This worked fine.
Next, I did a CCTreeAppendDB with the next database. I get as output
from start to finish:
Added cscope database U:\CSCOPE~1\ECAP30~1.OUT
Added cscope database U:\CSCOPE~1\ECACOM~1.OUT
Added cscope database U:\CSCOPE~1\CEFSA-~1.OUT
0 4212 U:\CSCOPE~1\ECAP30~1.OUTnone
1 5912 U:\CSCOPE~1\ECACOM~1.OUTnone
2 1704 U:\CSCOPE~1\CEFSA-~1.OUTnone
6 more lines
6 more lines
CCTree: Done loading database. xRef Symbol Count: 740. Time taken:
9.598038 secs
Error detected while processing function
163..137..139..102..SNR28_CCTreeMakeCommaListUnique..40:
line5:
E713: Cannot use empty key for Dictionary
Error detected while processing function 163..137:
line 12:
E171: Missing :endif
My Vim version is the Vim without Cream build for 7.3.198 on Windows XP.
I find this very strange. I THINK (if I'm reading the error messages
correctly) the line that causes the error is the let valdict[aval] =
'' line in the below code fragment from cctree.vim, but it sure
looks correct to me:
let valdict = {}
let reslist = ''
for aval in a:lstval
if !has_key(valdict, aval)
let valdict[aval] = ''
let reslist .= (aval . ,)
endif
endfor
--
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
Issue 11 in vim: VIM shell extension added LANG environment variable to explorer.exe
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 11 by lovet...@21cn.com: VIM shell extension added LANG environment variable to explorer.exe http://code.google.com/p/vim/issues/detail?id=11 What steps will reproduce the problem? 1. reboot 2. right click any file 3. after menu popup, LANG environment variable (with value zh_CN) is injected to explorer.exe (which will affect any new child process of it) What is the expected output? What do you see instead? - What version of the product are you using? On what operating system? vim73_46 on Windows XP Professional (Simplified Chinese). Please provide any additional information below. I'm not sure why VIM need a LANG environment variable to be put to explorer.exe, because even without LANG environment, vim display the correct GUI language (for me, it's simplified chinese). Add a LANG environment variable to explorer.exe will affect all new child process, I often use Cygwin 1.7, LANG will affect Cygwin to display Chinese/multibytes characters. If LANG environment is needed by vim.exe/gvim.exe, why not putenv to vim.exe/gvim.exe itself instead of explorer.exe? related code may be here: http://code.google.com/p/vim/source/browse/src/GvimExt/gvimext.cpp#286 -- 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
Issue 12 in vim: Mapped CTRL-C doesn't work in gvim due to focus out/in events confusing ctrl_c_interrupts.
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 12 by stephen@gmail.com: Mapped CTRL-C doesn't work in gvim
due to focus out/in events confusing ctrl_c_interrupts.
http://code.google.com/p/vim/issues/detail?id=12
What steps will reproduce the problem?
1. Run Gnome 2 desktop environment.
2. In Gnome, System menu - Preferences - Assistive Technologies, pops up
a window, click Mouse Accessibility button, pops up a window,
click General tab, enable Show position of pointer when the Control key
is pressed.
3. In .vimrc, map C-C to something (e.g. use mswin.vim to map C-C to copy)
4. Run gvim
5. Press C-C (e.g if in mswin mode, select some text (e.g. Shift-DownArrow
a couple of times then press Ctrl-C)
What is the expected output?
Selected text is copied. Selected text stays highlighted.
What do you see instead?
No text is copied (C-V won't paste it). Selected text gets unhighlighted;
visual mode is exited.
What version of the product are you using? On what operating system?
64-bit Ubuntu Natty, Ubuntu-packaged gvim (vim 7.3.35). Also happens with
7.3.219 built from latest Hg source.
Please provide any additional information below.
This can be fixed (or perhaps just hacked around) by editing gui_gtk_x11.c
near the end of function key_press_event() from:
if (len == 1 ((string[0] == Ctrl_C ctrl_c_interrupts)
|| (string[0] == intr_char intr_char != Ctrl_C)))
{
trash_input_buf();
got_int = TRUE;
}
to:
if (len == 1 ((string[0] == Ctrl_C ctrl_c_interrupts
!mapped_ctrl_c)
|| (string[0] == intr_char intr_char != Ctrl_C)))
{
trash_input_buf();
got_int = TRUE;
}
But a better solution probably relies on correctly setting
ctrl_c_interrupts to WAR the issue described below.
Background:
If the Gnome option show mouse pointer position is not set,
ctrl_c_interrupts is false when the C-C keypress is received, and
everything works.
However, due to the extra keypress events processed when show mouse
pointer position is enabled, ctrl_c_interrupts gets set back to true, and
C-C triggers trash_input_buf() etc. The extra keypress events from the
Control key being pressed are injected from focus lost/gained events, which
IIRC get injected from gui.c function gui_focus_change().
--
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
gvimext replace lang for new gvim
Hi.
gvimext set $LANG for gettext. and This environment variable pass to new
gvim.
below is a patch for this problem.
This will fix issue no 11.
http://code.google.com/p/vim/issues/detail?id=11
--
diff -r c6f8f1957c66 src/GvimExt/gvimext.cpp
--- a/src/GvimExt/gvimext.cpp Mon Jun 13 21:21:22 2011 +0200
+++ b/src/GvimExt/gvimext.cpp Thu Jun 16 14:28:35 2011 +0900
@@ -142,6 +142,7 @@
static int dyn_libintl_init(char *dir);
static void dyn_libintl_end(void);
+static wchar_t *oldenv = NULL;
static HINSTANCE hLibintlDLL = 0;
static char *(*dyn_libintl_gettext)(const char *) = null_libintl_gettext;
static char *(*dyn_libintl_textdomain)(const char *) =
null_libintl_textdomain;
@@ -339,8 +340,10 @@
inc_cRefThisDLL()
{
#ifdef FEAT_GETTEXT
-if (g_cRefThisDll == 0)
+if (g_cRefThisDll == 0) {
dyn_gettext_load();
+ oldenv = GetEnvironmentStringsW();
+}
#endif
InterlockedIncrement((LPLONG)g_cRefThisDll);
}
@@ -349,8 +352,11 @@
dec_cRefThisDLL()
{
#ifdef FEAT_GETTEXT
-if (InterlockedDecrement((LPLONG)g_cRefThisDll) == 0)
+if (InterlockedDecrement((LPLONG)g_cRefThisDll) == 0) {
dyn_gettext_free();
+ if (oldenv)
+FreeEnvironmentStringsW(oldenv);
+}
#else
InterlockedDecrement((LPLONG)g_cRefThisDll);
#endif
@@ -890,8 +896,8 @@
NULL, // Process handle not inheritable.
NULL, // Thread handle not inheritable.
FALSE, // Set handle inheritance to FALSE.
- 0, // No creation flags.
- NULL, // Use parent's environment block.
+ CREATE_UNICODE_ENVIRONMENT, // No creation flags.
+ oldenv, // Use parent's environment block.
NULL, // Use parent's starting directory.
si, // Pointer to STARTUPINFO structure.
pi) // Pointer to PROCESS_INFORMATION structure.
--
Thanks.
- Yasuhiro Matsumoto
--
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
Re: gvimext replace lang for new gvim
Ooops, bits strange. Below is a better.
diff -r c6f8f1957c66 src/GvimExt/gvimext.cpp
--- a/src/GvimExt/gvimext.cpp Mon Jun 13 21:21:22 2011 +0200
+++ b/src/GvimExt/gvimext.cpp Thu Jun 16 14:33:28 2011 +0900
@@ -142,6 +142,7 @@
static int dyn_libintl_init(char *dir);
static void dyn_libintl_end(void);
+static wchar_t *oldenv = NULL;
static HINSTANCE hLibintlDLL = 0;
static char *(*dyn_libintl_gettext)(const char *) = null_libintl_gettext;
static char *(*dyn_libintl_textdomain)(const char *) =
null_libintl_textdomain;
@@ -339,8 +340,10 @@
inc_cRefThisDLL()
{
#ifdef FEAT_GETTEXT
-if (g_cRefThisDll == 0)
+if (g_cRefThisDll == 0) {
dyn_gettext_load();
+ oldenv = GetEnvironmentStringsW();
+}
#endif
InterlockedIncrement((LPLONG)g_cRefThisDll);
}
@@ -349,8 +352,11 @@
dec_cRefThisDLL()
{
#ifdef FEAT_GETTEXT
-if (InterlockedDecrement((LPLONG)g_cRefThisDll) == 0)
+if (InterlockedDecrement((LPLONG)g_cRefThisDll) == 0) {
dyn_gettext_free();
+ if (oldenv)
+FreeEnvironmentStringsW(oldenv);
+}
#else
InterlockedDecrement((LPLONG)g_cRefThisDll);
#endif
@@ -890,8 +896,9 @@
NULL, // Process handle not inheritable.
NULL, // Thread handle not inheritable.
FALSE, // Set handle inheritance to FALSE.
- 0, // No creation flags.
- NULL, // Use parent's environment block.
+ oldenv ? CREATE_UNICODE_ENVIRONMENT : 0,
+ // No creation flags.
+ oldenv, // Use parent's environment block.
NULL, // Use parent's starting directory.
si, // Pointer to STARTUPINFO structure.
pi) // Pointer to PROCESS_INFORMATION structure.
--
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
