On Monday, 8 August 2016 22:27:11 UTC+2, Bram Moolenaar wrote: > Manuel Schiller wrote: > > [...] > > > Concerning your request to send a patch that just fixes the assumption > > about "one ascii character == one glyph": One could either get rid of > > that speed optimisation code altogether (in which case all ligatures > > will work), or rewrite most of that optimisation, doing one shaping > > call into pango for each of (or some of) the characters with codes < > > 128. The latter versoin would amount to some overhead for all those > > calls, and reassembling the returned data structures in a suitable > > way... > > I don't see how it can work with a font where it is not true that each > ASCII character is one display cell. E.g., when highlighting or drawing > the cursor. If you draw some combination of two ASCII characters with > one double-wide glyph it's not possible to highlight half of it. > > It appears pango has no way to disable ligatures. > > So the table we create should work, putting in extra spaces to avoid the > shaping to take place. But I don't see why we would be doing this only > for alphanumeric characters, this should work for all ASCII characters. > >
Hi Bram, well, it seems I upset quite a bee's nest with this (much of which may be my own fault ;)... Neither patch nor the current vim code will work when one ASCII character translates to more than one display cell. But when you have a ligature between two characters, drawing a two-cell glyph might be considered an improvement by some. As to what happens when you change highlighting, or move the cursor across such a ligature: Currently, the redrawn character cell gets repainted with the "non-ligaturised" version of that single glyph, which results in the ligature partially reverting back to its component glyphs. Moving the cursor off, and a (partial) redraw like from pressing ^L causes the ligature glyph to reappear. It's not perfect, but it's consistent with the behaviour I've seen from e.g. putty and Konsole/qterminal (the latter two do their own metrics calculation, and get the spacing wrong if there's ligatures on the line - patched gvim doesn't do that, so I'm very happy with it ;). My assertion is that people using these programming fonts will be happy to see these ligatures assemble/disassemble as they edit across them. Regarding your question about the range of ascii characters to which the tabulated cache is applied: Restricting this to subranges of [0,127] that I mentioned should get you most of the speed improvement that can be had from bypassing pango's shaping, and from what I understood, the space ' ' is especially important, since it's used to clear the screen. But the restriction to those subranges also means that strings containing the popular "programming ligatures" like "<=", ">=", "!=", "->" etc. will be subject to pango's shaping, thus ligatures are displayed... In a way, we're selectively disabling the "shaping bypass" for less obvious character ranges where ligatures are more likely (and more likely to be missed by programmers). I hope this clarifies things a bit. Thanks for the interest, Manuel -- -- 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/d/optout.
