Hi,
as reported by Benjamin R. Haskell on vim-use, the second example in the
map() documentation is wrong, using '&' instead of 'v:val'. Here is a
patch that corrects it.
Jan
--
-[ OpenPGP key ID: 00A0FD5F ]-
The most dangerous phrase in the language is, "We've always done it this
way."
On 01/07/12 00:52, Maximus ConEmu wrote:
Thanks for clarification.
Yes, message appears, 256 colors works.
However, CR/LF looks weird. Checking my code now...
see
:help 'ff'
:help 'ffs'
:help ++ff
:help file-formats
:help file-read
One more question.
Whell, One problem/incomprehensibility is revealed.
Vim drops all flags for g_hConOut, because of "(tmode == TMODE_RAW)"
os_win32.c: 2952
cmodeout &= ~(ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT);
I'm hunging up. Dropping "ENABLE_PROCESSED_OUTPUT" means that must NOT examined
for ASCI
On 30/06/12 20:24, Maximus ConEmu wrote:
Hi.
Not sure, if community is interested in subj, but...
I'm developer of ConEmu (Windows Console Emulator) wich supports xterm 256
color extension of ANSI X3.64.
http://code.google.com/p/conemu-maximus5/wiki/Screenshots#ANSI_X3.64_and_xterm_256_colors_i
Hi.
Not sure, if community is interested in subj, but...
I'm developer of ConEmu (Windows Console Emulator) wich supports xterm 256
color extension of ANSI X3.64.
http://code.google.com/p/conemu-maximus5/wiki/Screenshots#ANSI_X3.64_and_xterm_256_colors_in_ConEmu
Vim "from the box" does not suppo
On 30-Jun-2012 22:03:42 +0200, Bram Moolenaar wrote:
> Taylor Hedberg wrote:
>
>> This patch doesn't appear to have been published in the Mercurial repo
>> on Google Code.
>
> It should be there:
>
> 2d107086903a
> updated for version 7.3.584 Problem: PyCObject is not always defined.
> Solution
Chris Sutcliffe wrote:
> On 30 June 2012 10:22, Bram Moolenaar wrote:
> >> So adjusting it in the source would be ineffective anyway, you should
> >> just adjust WINVER in Make_ming.mak.
> >
> > If we can solve it by changing the default for WINVER to 0x0500 that
> > should probably work. Still,
Taylor Hedberg wrote:
> This patch doesn't appear to have been published in the Mercurial repo
> on Google Code.
It should be there:
2d107086903a
updated for version 7.3.584 Problem: PyCObject is not always defined. Solution:
Use PyObject instead.
Today (7 hours ago)
--
>From "kn
This patch doesn't appear to have been published in the Mercurial repo
on Google Code.
signature.asc
Description: Digital signature
On Saturday, June 30, 2012 12:33:05 PM UTC-4, Heptite wrote:
> On Sat, 30 Jun 2012, Bram Moolenaar wrote:
>
> > If we can solve it by changing the default for WINVER to 0x0500 that
> > should probably work. Still, there is quite a large uncertainty
> > about what the side effects are.
> >
> > I
On Sat, 30 Jun 2012, Bram Moolenaar wrote:
If we can solve it by changing the default for WINVER to 0x0500 that
should probably work. Still, there is quite a large uncertainty
about what the side effects are.
I would really appreciate it if a few people try out the solution
for changing WIN
On Sat, Jun 30, 2012 at 01:01:16PM +0200, Bram Moolenaar wrote:
> > In addition to the PyCapsule problems, it appears that
> > _PyObject_NextNotImplemented is not present in Python 2.6, and so when I
> > try to run a python command after today's series of patches, I get
> >
> > E448: Could no
On 30 June 2012 10:22, Bram Moolenaar wrote:
>> So adjusting it in the source would be ineffective anyway, you should
>> just adjust WINVER in Make_ming.mak.
>
> If we can solve it by changing the default for WINVER to 0x0500 that
> should probably work. Still, there is quite a large uncertainty a
Chris Sutcliffe wrote:
> On 30 June 2012 07:17, Bram Moolenaar wrote:
> > Is that the latest version of MingW? MEMORYSTATUSEX is a standard part
> > of Windows XP and later.
> >
> > Hmm, I found a suggestion to put this before including windows.h:
> >
> > #define _WIN32_WINNT 0x0501
> >
> > We
Patch 7.3.584
Problem:PyCObject is not always defined.
Solution: Use PyObject instead.
Files: src/if_py_both.h, src/if_python.c
*** ../vim-7.3.583/src/if_py_both.h 2012-06-29 17:51:58.0 +0200
--- src/if_py_both.h2012-06-30 13:25:24.0 +0200
***
*** 2
On 30 June 2012 07:17, Bram Moolenaar wrote:
> Is that the latest version of MingW? MEMORYSTATUSEX is a standard part
> of Windows XP and later.
>
> Hmm, I found a suggestion to put this before including windows.h:
>
> #define _WIN32_WINNT 0x0501
>
> We have never needed that for other features,
Patch 7.3.583
Problem:PyObject_NextNotImplemented is not defined before Python 2.7.
(Danek Duvall)
Solution: Add #ifdefs.
Files: src/if_python.c
*** ../vim-7.3.582/src/if_python.c 2012-06-29 19:14:48.0 +0200
--- src/if_python.c 2012-06-30 12:59:38.
Cesar Romani wrote:
> I'm building vim on windows 7 with MinGW. By upgrading from 7.3.566 to
> 7.3.582 I get the following compile error:
>
> ---
> ...
> os_win32.c: In function 'mch_avail_mem':
> os_win32.c:5012:2: error: unknown type name 'MEMORYSTATUSEX'
> os_win32.c:5014:4: e
Lech Lorens wrote:
> On 13 June 2012 14:05, Bram Moolenaar wrote:
> >
> > I wrote:
> >
> >> Patch 7.3.550 (after 7.3.541)
> >> Problem: With "j" in 'formatoptions' a list leader is not removed. (Gary
> >> Johnson)
> >> Solution: Don't ignore the start of a three part comment. (Lec
Danek Duvall wrote:
> On Fri, Jun 29, 2012 at 12:55:10PM +0200, Bram Moolenaar wrote:
>
> > Patch 7.3.569
> > Problem:Evaluating Vim expression in Python is insufficient.
> > Solution: Add vim.bindeval(). Also add pyeval() and py3eval(). (ZyX)
> > Files: runtime/doc/eval.txt, run
20 matches
Mail list logo
