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 Thursday, July 31, 2014 4:46:22 AM UTC-5, 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 should display as Chinese chacaters.
>
> W
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 Thursday, July 31, 2014 8:30:36 AM UTC-5, Paul Moore wrote:
> 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 t
On 31/07/2014 14:30, Paul Moore wrote:
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 se
On 31-Jul-2014 15:43 +0200, Ben Fritz wrote:
> On Thursday, July 31, 2014 8:30:36 AM UTC-5, Paul Moore wrote:
>> 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
>>> c
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 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/07/2014 15:44, Paul Moore wrote:
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
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 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, has been using it. Can't see any obvio
On 01/08/14 00:40, Paul Moore wrote:
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, has been
On 31/07/2014 16:40, Paul Moore wrote:
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, has bee
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 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
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 should display as Chinese
> chacaters.
The question is: What version of Windows? Readin
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 should display as Chinese
>> chacaters
On 31/07/2014 19:30, Paul Moore wrote:
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 beh
On 31/07/14 20:50, Paul Moore wrote:
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 should di
On Sat, Aug 2, 2014 at 8:12 PM, Tony Mechelynck
wrote:
> On 31/07/14 20:50, Paul Moore wrote:
>>
>> 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
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 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 to the level of clarity tha
On 03/08/14 07:58, Paul Moore wrote:
[...]
Thanks for the explanation, but with all due respect, it doesn't seem
unreasonable to me for a user to expect that if they specify a
commonly-used monospace font like Consolas, Lucida Console, or even
Courier New, they should get behaviour that is simil
Hi Tony!
On So, 03 Aug 2014, Tony Mechelynck wrote:
> On 03/08/14 07:58, Paul Moore wrote:
> [...]
> >
> >Thanks for the explanation, but with all due respect, it doesn't seem
> >unreasonable to me for a user to expect that if they specify a
> >commonly-used monospace font like Consolas, Lucida C
On 04/08/14 14:34, Christian Brabandt wrote:
Hi Tony!
Hi Christian
[...]
And since this seems to work with the GTK2 build (I didn't test it), I
see no reason, why this behaviour should not be also enabled on other
GUIs.
The reason, IIUC, is that searching other fonts is how Pango and Cairo
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
What's the status here?
I (Win7 64-bit) still see rendering issues e.g. with Hebrew text. Put the
following lines in a file an move the cursor over them:
ירושלים של זהב
ושל נחושת ושל אור
הלא לכל שירייך
אני כינור...
--
--
You received this message from the "vim_dev" maillist.
Do not
27 matches
Mail list logo
