On 04/08/10 20:54, Bram Moolenaar wrote:
James Vega wrote:
Using a recent version of the vim73 repo (e037ee8598b3), the below steps
show some display corruption.
From Vim's source directory, use the attached test.vim as follows and
perform a search for "text" -- /text<CR>.
$ vim -u test.vim -N runtime/syntax/tex.vim
Namely, the cursor is displayed in an incorrect position but 'ga' does
show that it is on the 't' from "texTypeSize". Also, the search causes
a fold to open and remnants of the 'foldtext' is still displayed.
":redraw!" will clear the remnants of the 'foldtext' but the other
display corruption still exists.
Issuing ":set list!" to toggle the list characters on and off will show
that the cursor is at the start of the match, as expected, and that
enabling 'list' changes the display of items other than those being
covered by 'list'. For example, some of the groups listed in the
contains list for texCmdGroup get garbled when 'list' is enabled.
So far, I've only been able to reproduce this when viewing the tex
syntax file.
That's because of this modeline:
" vim: ts=8 fdm=marker ambw=double
It sets 'ambiwidth' to "double" after setting 'listchars'. That's what
is causing the trouble, because the 0xb7 character is then suddenly double
width.
I think the way to solve it is to disallow changing 'ambiwith' when it
causes 'listchars' or 'fillchars' to become invalid. I'll make a patch
for that.
Perhaps we should remove 'ambiwidth' from that modeline?
I guess the error is mine.
A few days ago Dr. Chip asked my help about a problem he had with
various kinds of double angle math operators and brackets, wondering how
to represent the \ll and \gg codes that can appear in, I think, TeX.
Some of these double angled glyphs were displayed (in his gvim but not
in mine) in what looked like half of a double-width glyph, and I
mentioned the 'ambiwidth' option. However I didn't realize that it was
for use in a syntax script for general consumption.
I suppose I should have stressed, more than I did, the fact that
'ambiwidth' should be set on or off in correlation with the needs of
whatever 'guifont' (or, maybe, terminal font) one is using. It is a
global option, and as such dangerous to use in a modeline, which is
meant to set only local options.
The 'encoding' option has recently been disallowed in modelines. Setting
'guifont' is usually harmless, except that going from a Latin font to a
Chinese one or vice-versa could throw 'ambiwidth' out of whack, and that
setting 'ambiwidth' on may render 'listchars' and/or 'fillchars' invalid
if they include ambiguous-width characters.
Forbidding any change of 'guifont' or 'ambiwidth' in modelines might be
viewed as too harsh ... or is it?
Best regards,
Tony.
--
Cahn's Axiom:
When all else fails, read the instructions.
--
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
