On Sat, Aug 7, 2010 at 8:52 PM, Tony Mechelynck <[email protected]> wrote: > On 07/08/10 18:53, Bram Moolenaar wrote: >> >> Tony Mechelynck wrote: >> >>> On 05/08/10 23:15, Bram Moolenaar wrote: >>>> >>>> Boyko Bantchev wrote: >>>> >>>>> On 4 August 2010 20:15, Bram Moolenaar<[email protected]> wrote: >>>>>> >>>>>> ... >>>>>> Please report every problem you find! =A0The 7.3 release should not >>>>>> contain a problem because you didn't report it. >>>>>> ... >>>>> >>>>> Well, I did point out to two bugs earlier, and they are still >>>>> present in 7.3d. >>>>> >>>>> 1. Function input()'s echo is broken. If one executes, e.g. >>>>> >>>>> :while 1 | let s = input('') | echo "\n" | endw >>>>> >>>>> one would expect to see a succession of strings that he enters. >>>>> Instead, we are left with nothing but empty lines. >>>>> This bug seems to be very old, and seriously hampers writing >>>>> interactive vimscriptlets. >>>> >>>> Try this: >>>> >>>> :while 1 | let s = input('') | echo s "\n" | endw >>>> >>>> Not sure this is a bug. If someone wants to erase the typed text this >>>> would work now but not when making it work the way you suggest. >>>> >>>> >>>>> 2. Under Linux + GTK, all Unicode characters combined-accented with >>>>> U+0300, U+0301, ... (any of those) are incorrectly displayed: >>>>> the accent is either (mis)placed above the character on the left, >>>>> or is not displayed at all. >>>>> This seems to have originated with Vim 7.2. >>>> >>>> I see this too. I can fix it with this change: >>>> >>>> >>>> --- a/gui_gtk_x11.c 2010-07-25 15:48:22.000000000 +0200 >>>> +++ b/gui_gtk_x11.c 2010-08-05 23:09:43.000000000 +0200 >>>> @@ -5108,10 +5108,11 @@ >>>> >>>> /* There is a previous glyph, so we deal with >>>> combining >>>> * characters the canonical way. That is, setting >>>> the >>>> - * width of the previous glyph to 0. */ >>>> + * width of the previous glyph to 0 and set the >>>> x_offset >>>> + * to puth the accent glyph in the middle. */ >>>> glyphs->glyphs[i - 1].geometry.width = 0; >>>> width = cells * gui.char_width * PANGO_SCALE; >>>> - glyph->geometry.x_offset += >>>> + glyph->geometry.x_offset = >>>> MAX(0, width - cluster_width) >>>> / 2; >>>> #if 0 >>>> /* Dirty hack: for "monospace 13" font there is a bug >>>> that >>>> >>>> >>>> But that might break it for others... >>>> >>> >>> After applying this patch (changeset 2070b63605a7 dated 2010-08-07 >>> 15:46:45 +0200), my gvim display is worse than before. >>> >>> I'm using Bitstream Vera Sans Mono 8 in gvim (Huge) +gui_gtk2 +gui_gnome >>> and currently I'm editing a Russian dictionary, with many combining >>> acute accents (U+0301) over Cyrillic vowels. >>> >>> Before the patch, the accents came beautifully over the concerned >>> vowels. After the patch, the accent is displayed too much to the right, >>> between the concerned vowel and the next letter. This resembles what I >>> get with Times New Roman in the Mozilla SeaMonkey browser; it is not as >>> bad, though, as what I see with "monospace" (not sure which font this >>> brings) in the SeaMonkey mailer, where the accent is squarely over the >>> next letter, one character width to the right of where it ought to be. >>> >>> So I suspect that this is a font-related problem. Boyko, what 'guifont' >>> are you using? >>> >>> Bram, is it possible to know the width of the glyph, in order not to >>> move it so far to the right that it overshoots the next character? Also, >>> what will happen in Arabic, where it is common (at least in Koranic >>> Arabic) to have two combining characters over a single spacing letter? >>> For instance: in the formula, "to the name of God the Benevolent the >>> Merciful", bismillâh ar-rahmân ar-rahîm, >>> ب٠سْم٠ٱللّٰه٠ٱلرَّØْمٰن٠ٱلرَّØ٠يم٠؛ >>> in the last (leftmost) two words (of four), the third consonant (which >>> goes down below the line and is not joined to the next one to its left) >>> has two combining signs, making it in both cases rah + shadda + fatha, >>> U+0631 + U+0651 + U+064E >>> >>> I'm attaching an "Arabic testcase" file which displays horribly in this >>> new Vim changeset. Use ":setlocal arabic" to display the Arabic text RTL >>> as it should be, then compare lines 87-92 (in vocalized Arabic) with >>> lines 94-99 (the same text without the combining characters). You should >>> see the same consonants, just without the combining marks (the >>> "harakaat" as they're called in Arabic) but that's not what I see. Some >>> letters move about, others disappear completely, moving the cursor over >>> the text makes the letters go left or right... (The unvocalized part, >>> lines 94-99, is displayed correctly.) >>> >>> Since this testcase is HTML, you can also view it in a browser; however >>> even browsers may display the consonants differently because when there >>> exists a digram or a trigram to make some letter-combinations "nicer", >>> the browser may not recognise it if there is a combining mark in the >>> middle. This, however, should not affect Vim, which pays no attention to >>> polygrams other than lam+alif. >> >> Sorry, these scribbles don't show me what's wrong. Viewing the text in >> a browser looks completely different. > > These "scribbles", as you call them, are Arabic text, representing a common > salutation, "May peace be with you, and God's benevolence and His blessings" > (lines 87 and 94), plus the first half of the Fatiha, the first and shortest > sûra of the Qur`an (lines 89-92 and 96-99). Text in the browser vs. in gvim > is just "proportional" vs. "monospaced" text; the difference comes from the > high prestige calligraphy has always had in Arabic, whose flowing writing is > not really made for a monospaced kind of font. > > View the file in gvim with 'encoding' set to utf-8 and :setlocal arabic. The > fact that I also have 'cursorline' and 'cursorcolumn' both on may be > relevant, I'm not sure. The following "wrong behaviour" happens with > 'guifont' set to "Bitstream Vera Sans Mono 8", "Luxi Mono 8" or "DejaVu Sans > Mono 8" but not with "Courier New 8" or "Lucida Sans Typewriter 8"; I don't > know why (and remember: use either > :let &gfn = "quoted value" > or > :set gfn=value\ with\ spaces\ escaped > ). > > Lines 87-92 should (but for me they don't) look the same as lines 94-99 > except that the latter have no combining characters. Now move the > Normal-mode cursor this way and that using hjkl over the text in lines > 87-92. With the latest changeset (3607f126a661 "use different Czech keymap") > what I see is that the file looks "bad" when loaded, with approximately > every second letter replaced by a space, and some letters displayed one > character cell off or even two, thus "erasing" what belongs there; then > moving the cursor left and right over a line "corrects" what the cursor has > gone over, but moving the cursor to a different line, or hitting Ctrl-L, > makes the text "bad" again. > > To know which "scribbles" are spacing characters and which ones are > combining characters, use ga. The first glyph (the spacing one) should be > repeated at the same position in lines 94-99. There may also be combining > characters: usually one, sometimes zero or two. > >> >> Please try the latest version, I solved it in a slightly different way. >> For older GTK versions it might do the same as before. >> > > My GTK2 package is called "gtk2-2.20.1-2.13.i586" as distributed with > openSUSE Linux 11.3. > > > Best regards, > Tony.
Hi Tony How about putting somewhere 2 screenshots: - screenshot of Vim with wrong behavior - screenshot of Vim (or other application) with expected behavior It would make it simpler to understand the problem. Cheers -- Dominique -- You received this message from the "vim_use" 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
