On 16/12/13 03:24, James McCoy wrote:
On Sun, Dec 15, 2013 at 08:00:32PM +0100, Tony Mechelynck wrote:
On 15/12/13 16:39, Alex Efros wrote:
Hi!
I'm not sure which application has this bug - vim or urxvt.
I'm using urxvt with custom font which doesn't have all unicode symbols,
but AFAIK urxvt somehow magically load symbols absent in current font from
some other fonts. I've no idea how urxvt decide which font should be
used, but looks like in my case most such symbols loaded from DevaVu.
I've just added to ~/.XCompose these lines:
<Multi_key> <v> <v> : "✓" U2713 # CHECK MARK
<Multi_key> <V> <V> : "✔" U2714 # HEAVY CHECK MARK
and while testing them I noticed strange thing: in vim CHECK MARK looks
too large, larger and bolder than HEAVY CHECK MARK. In bash CHECK MARK
always looks correctly (lighter than HEAVY CHECK MARK).
In `vim -u /dev/null --noplugin` CHECK MARK also always looks correctly,
like in bash. So, I've bisect vim settings and found problem is in …
set esckeys
WOW, that was a real surprise!!!
Actual command which break this is "set nocompatible" in /etc/vim/vimrc,
but if I add "set noesckeys" right after it - it fix issue with CHECK
MARK's rendering/font.
I don't like to disable esckeys just to fix one symbol rendering issue
(all other symbols works ok, or at least I never noticed rendering
differences), so if anyone have idea about another workaround or how to
further debug this issue (is it possible to enable debugging in urxvt to
find out which extra fonts it use?)…
I'm using Gentoo Linux, vim-7.4.94, rxvt-unicode-9.18.
Like it is said under :help 'esckeys', try the following:
:set esckeys timeout timeoutlen=5000 ttimeoutlen=100
I don't see how this relates to the problem Alex is trying to solve.
The issue is that the font is rendered differently depending on the
value of 'esckeys', nothing to do with responsiveness while typing.
Cheers,
It isn't only responsiveness. These timeouts are used to distinguish
which bytes belong to a single typed key, which ones belong to different
keys but may belong to a single mapping, and which ones are too far
apart in time for any mapping to come into consideration.
If 'esckeys' makes a difference, then there is some keycode starting
with <Esc> that gives a problem. So what does the terminal send to mean
U+2713 has been sent? Apparently ignoring the possibility that a
multibyte keycode might start with <Esc> makes a difference. (This might
require starting the terminal in 8bit-meta mode, see :help map-alt-key).
But why argue? If Alex tries it and it doesn't solve his problem, then
it's something else and he's lost nothing except maybe a little time.
But if it does solve his problem, he won't know it unless he tries it.
Whai _I_ find weird is that 'esckeys' (and the timeouts) relate to
keyboard input but the OP seems to have a problem with display output.
Does the display really look different according to the 'esckeys'
setting, when looking at a file already containing those check marks
without inserting anything in it? If it does, it's weird.
Best regards,
Tony.
--
Really heard in court in the U.S.A.:
Q.: Are you qualified to take a urine sample?
A.: Are you qualified to ask this question?
--
--
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
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
