On Thu, Oct 14, 2010 at 2:21 AM, Charles E Campbell Jr wrote:
>
> This patch is causing "vanishing signs syndrome". Here's a test procedure:
>
> When in .../vim73/src,
> ./vim -g -N -u NONE -S tst.vim
>
> where tst.vim is:
>
> e! main.c
> 169
> sign define TestSign icon=../pixmaps/tb_close.xpm
> sign place 1234 line=169 name=TestSign file=main.c
>
> With vim 7.3.1-23, the tb_close.xpm icon shows up on line 169 of main.c .
> With vim 7.3.1-24, a plain block is placed there instead.
>
When the sign is defined with an icon, its 'typenr' is stored in the
ScreenAttrs[] array. The 'typenr' is later retrieved from this array when the
screen is redrawn (so that the icon may be redrawn: see gui_mch_drawsign()).
The problem is that the array is of type 'unsigned short' or 'unsigned char',
while 'typenr' is an 'int'.
See win_line() in screen.c:
line 3423: set the value of 'icon_sign' to the sign 'typenr'
further down: char_attr = icon_sign
much further: ScreenAttrs[off] = char_attr;
There are two other problems that occur before and after this patch:
* buf_getsigntype() returns 'typenr' and 0 when not found, but 0 is a valid
typenr when the sign has been defined with the name '0' (so placing such
a sign does not display the icon or any highlighting)
* when defining a sign with a numeric name, no check is done currently to
make sure that its value will fit in an 'unsigned short' or
'unsigned char'
A possible fix may be:
* cancel the patch
* treat all sign names, including numeric names, as alphabetic
names and allocate a 'typenr' for each one with
'last_sign_typenr', as it was done previously only for
non-numeric names. In this case, 'sn_typenr' and 'sn_name' are
unrelated.
This would fix the broken patch, and the two problems above.
I can send a patch, if this is acceptable.
--
Xavier
Les Chemins de Lokoti: http://lokoti.alwaysdata.net
--
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
