2016-08-09 6:35 GMT+09:00 manuelschiller.pimail via vim_dev < [email protected]>:
> 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 ;). putty, konsole, qterminal, and gvim...There's a obvious difference between the first three and the last; the former are terminals and the latter is an editor. If you think of the difference of their usages, you'll notice that even small hiccups on terminals could much matter on editors, in particular for users who must have the cursor go to and fro to view and edit files for hours. That's something we should not underestimate, isn't that? Probably, some of the users wouldn't be patient enough to put up with it and would soon file bug reports once your patch was merged into the upstream. You mentioned that gvim has less issues than the terminals. But that's is a side effect of redrawing by gvim for its own necessity, not for the sake of ligatures. Your patch doesn't contain any code for that. That has no redraw mechanism to ensure ligatures to appear on the screen as/when they should. I'm glad to hear, "patched gvim doesn't do that, so I'm very happy with it:)." But you should be aware that your happiness comes to you only by accident or fortune, not by design or code. The reason I'm sticking to monospace fonts comes here. If we were making a text viewer, your patch would be sufficient. But actually what we are making is an editor. We have to address other issues such as the one you mentioned above to make vim truly and decently support ligatures. For that purpose, the precondition that all fonts to be used are monospace, could be helpful and make our work much simpler and easier. After that, we could do something about "effectively" monospace fonts if necessary, couldn't we? By the way, why didn't you honestly talk to the people here about the issue you've already noticed till now? As you guessed, I didn't install the fonts in question on my PC nor tried your patch, because I easily predicted from the code that your patch had such an issue you mentioned above. That's why I'm sticking to monospace; it's for getting us ready for addressing possible other issues your patch has. Not a pretext for rejecting your patch on behalf of old-school people. That said, it's OK for me to stop talking right now if you think I'm not qualified for a reviewer because of those. That helps me enjoy the coming vacation without anything bothering me. > My assertion is that people using these programming fonts will be happy to > see these ligatures assemble/disassemble as they edit across them. > Once people view ligatures on Vim, they will ask us more for the purpose of editing them in a way each individual thinks better... Best, Kazunobu > 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. > -- -- 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.
