Hi,
As I said, you should post this direct to vim-dev yourself (maybe copy
to Bram), and it'll get considered for inclusion.
For what it's worth, I've checked through the changes and they look
fine to me (although I'd defer to Bram on whether it's OK to take out
support for ancient Vim versions -
On Wednesday, 22 April 2015 20:03:44 UTC+1, Paul Moore wrote:
> Has anyone tried building Vim with Visual C 2015 on Windows yet? I wanted to
> try building a copy of Vim with Python 3.5 enabled, just to see how well it
> worked - Python 3.5 uses VC 2015 to build, so I wanted to use
Has anyone tried building Vim with Visual C 2015 on Windows yet? I wanted to
try building a copy of Vim with Python 3.5 enabled, just to see how well it
worked - Python 3.5 uses VC 2015 to build, so I wanted to use the same version
for Vim to avoid any weird C runtime clashes that might occur. A
On 5 August 2014 04:48, Tony Mechelynck wrote:
> The Vim-specific coding necessary to fetch these "replacement" glyphs is
> (IIUC) minimal; it just consists of calling the proper APIs from the GTK2
> interface. *If* similar APIs exist in other GUI backends, and *if* they can
> handle a fixed-size
On 3 August 2014 06:58, Paul Moore wrote:
> not a "no such character" box, but a usable representation. Having to
> set a series of options that require a deep understanding of character
> sets and how fonts work should not be needed just to see the contents
> of a file t
On 3 August 2014 01:12, Tony Mechelynck wrote:
> From what I read in the help, the only version of Vim which will try to use
> a glyph from a different font if the font you specified doesn't have the
> required glyph, is gvim with GTK2 GUI, which happens to be a Linux version
> (and maybe a rarely
On 31 July 2014 19:38, Bram Moolenaar wrote:
> Paul Moore wrote:
>
>> On Windows, Vim does not correctly display international characters.
>> To demonstrate this, create a file in UTF-8 encoding with the Unicode
>> characters \x5000 \x5001 \x5002 in it. These s
On 31 July 2014 18:51, Mike Williams wrote:
>> Actually, I also see the rendering bugs referred to in the thread
>> there. Maybe there's still some work needed on that patch.
>
> Is this the cut'n'paste issue? Do you have test data? TIA
It looks similar in behaviour (although I have to say I on
On 31 July 2014 18:32, Andre Sihera wrote:
> The proposed patch may fix glyph replacement but have you broken
> right-to-left display using Hebrew and Arabic fonts? I haven't checked
> the code but it appears gViM may do its own RTL processing which
> is why this flag was specified.
>
> You should
On 31 July 2014 16:05, Paul Moore wrote:
> On 31 July 2014 15:51, Mike Williams wrote:
>> Bram's nod AFAIK. I have been using it for the last 18 months and have had
>> no problems with it. I don't know if anyone else, other than the original
>> developer, ha
On 31 July 2014 15:51, Mike Williams wrote:
> Bram's nod AFAIK. I have been using it for the last 18 months and have had
> no problems with it. I don't know if anyone else, other than the original
> developer, has been using it. Can't see any obvious problem rolling it out
> since people have t
On 31 July 2014 14:52, Mike Williams wrote:
> There was a patch on the dev list a year or so back that implemented support
> for DirectX font rendering. This generally improves font rendering in
> Windows gVim, and also deals with this issue. It would be nice to see this
> patch get rolled into
On 31 July 2014 14:52, Ingo Karkat wrote:
>> I'm confused. You want Vim to show Chinese characters, in a font that
>> doesn't have any glyphs for Chinese characters?
>>
>
> The difference between Vim and Notepad (and many other programs) is that
> Vim (on Windows!) does not fall back to glyphs fr
On Thursday, 31 July 2014 14:08:16 UTC+1, Ben Fritz wrote:
> I don't see this problem.
[...]
> I entered unicode characters 5000, 5001, and 5002 which you say are Chinese
> characters, by pressing u5000 in insert mode, and the same for the other
> two. When I set my font to "BatangChe", they look
On Windows, Vim does not correctly display international characters. To
demonstrate this, create a file in UTF-8 encoding with the Unicode characters
\x5000 \x5001 \x5002 in it. These should display as Chinese chacaters.
With stock gvim (I'm using 7.4 with patches to 389) the characters are not
On Tuesday, 21 January 2014 20:24:27 UTC, Thiago Arruda wrote:
> This patch implements a simple but efficient form of job-control for
> vimscript, enabling vim to cooperate with long-running processes without
> blocking the UI.
>
> It is my second attempt to bring multitasking to vim, but unlike
Looking at if_python3.c, the definition of python3_loaded seems to be guarded
by the python 2 preprocessor symbols:
#if (defined(DYNAMIC_PYTHON) && defined(FEAT_PYTHON)) || defined(PROTO)
int
python3_loaded()
{
return (hinstPy3 != 0);
}
#endif
Is this an error?
Paul
--
--
You receive
On Thursday, 4 April 2013 13:10:23 UTC+1, glts wrote:
> > I don't think this is currently possible in Vim. Would it be feasible to
> > add behaviour like this to the completion menu code? (On the other hand, if
> > it *is* possible already, can someone give me a pointer to some sample
> > code?
One really useful feature of Sublime Text is the "fuzzy match" behaviour of
popup menus. The way this works is that if you have a menu with items "begin",
"end", "eat", you start with all items showing. Then, as you type letters, the
list is restricted to only those items containing the typed le
On Tuesday, 2 April 2013 12:28:40 UTC+1, mattn wrote:
> I prefer rename python in current to python2, And define aliased command
> 'python'.
> And I think that command must not be modifiable for users.
> So :python is specified python2 or python3 if it possible. And if both are
> enabled, I pref
Something odd is happening for me on Windows 7 (64 bit). I have my own compiled
copy of Vim, and when I run
:%!sparkup
I get "Shell returned 1" and the buffer is empty. Here, sparkup(.py) is a
Python file - I have a .py file association and .py in my PATHEXT variable. The
same command works fi
2008/9/16 Bram Moolenaar <[EMAIL PROTECTED]>:
>
> Paul Moore wrote:
>
>> On Sep 11, 3:06 am, Luis Carvalho <[EMAIL PROTECTED]> wrote:
>> > In any case, the latest version of the patch that fixes Make_bc5.mak can be
>> > found at:
>> >
>>
On Sep 11, 3:06 am, Luis Carvalho <[EMAIL PROTECTED]> wrote:
> In any case, the latest version of the patch that fixes Make_bc5.mak can be
> found at:
>
> http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-0...http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-m..
On Sep 11, 3:06 am, Luis Carvalho <[EMAIL PROTECTED]> wrote:
> > :lua print (12 * 36)
> > works, but
> > :lua print (0 / 0)
> > or
> > :lua print ( * )
> > crashes Vim
>
> I couldn't reproduce this behavior, but I don't have Vim compiled with BCC.
When compiled with mingw/gcc 0/0
On Sep 4, 8:55 pm, Tony Mechelynck <[EMAIL PROTECTED]>
wrote:
> 1. If the interface uses a separate DLL, then the absence of that DLL
> must not prevent Vim from running (as long as the interface isn't used,
> of course).
That's my view.
> 2. If the DLL must be linked with the same C runtime as
On Sep 4, 2:44 am, Luis Carvalho <[EMAIL PROTECTED]> wrote:
> > Anyway, as for your question I'd say just default to using a shared lib.
> > Most other interfaces seem to do so, and I'd say the costs should be
> > neglectable in this case. On Windows looking up the required symbols at
> > runt
On 1 Sep, 18:19, Luis Carvalho <[EMAIL PROTECTED]> wrote:
> Thank you. I'm attaching an updated version of the patch with a few more
> changes. I should probably find a place to put the latest version of the
> patch...
A fairly small point:
:lua print("a\nb\nc")
prints
[EMAIL PROTECTED]@c
(i
Luis Carvalho wrote:
>>> Below is a minor diff to your patch.
>
> Thank you. I'm attaching an updated version of the patch with a few more
> changes. I should probably find a place to put the latest version of the
> patch...
I gave this a try on Windows. With the following patch to Make_ming.mak
28 matches
Mail list logo
