Hi Bram, On Tuesday, 9 August 2016 21:52:16 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. > > I think you may see this as an improvement to having the font not work > at all, but other people who think the font would just work might very > well report a bug about this behavior. For example, long time ago we > simulated bold by drawing the glyph with a one pixel offset. That > sometimes left some pixel dust behind. The bug reports didn't stop > until all of that was fixed.
Point taken. > > 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). > > What makes you think these are popular? Maybe it's because I have read > ">=" as two characters all my programming life, but having it show up as > anything but the sequence of two characters would look weird to me. > Perhaps it would look nice in a book or other place where you only read > code. Well, preferences matter a lot to people, and I respect that (read on, because I think there's a way how both of us can have our cake, and eat it, too...). In fact, I had a useful discussion by mail with Kazunobu earlier today, and also did some thinking on the tram home tonight, and here's what I figured: - I think I should have another go at the ascii (code < 128) character to glyph cache in such a way that it forces one glyph per character, regardless of what the font offers in terms of ligatures. That way, the corruption for normal text for these effectively monospaced fonts with ligatures in that range will stop (because we'd effectively disable ligatures in that range), and we'll introduce none of the strange drawing issues with the cursor/redraw. - Instead of having a hardcoded range of characters for which we bypass glyph shaping (be it the entire range from 0 to 127, or just the subrange that the patch proposed), we could have a bit map from characters 0-127 in 4 32 bit integers, where each bit specifies if the character is eligible to bypass glyph shaping, or not. (We can discuss other data structures, of course.) If we make this user settable in some form, and set the default such that the old behaviour (i.e. no ligatures, no redrawing problems) remains unless people do something in their .vimrc, we could have correct, albeit non-fancy behaviour by default, and have effectively monospace fonts work (without ligatures). If users change the character range for which they bypass glyph shaping because they want ligatures, they'll get some, or all of the ligatures, with all the interesting behaviour that happens on redraw and cursor movement. Thus, users would get a choice. That way, we'd kind of have the best of both worlds with one or two relatively simple patches that I would hope to be viable for most people, and that do the right thing with no surprises or drawing glitches, unless people change the default settings. Once we have a bit of experience with that, maybe we can come up with a better patch that supports ligatures in an even better way. Would that be acceptable for you as an interim hack/solution, Bram? > If we don't do this, then is there still any point in trying to support > this font that isn't really mono spaced? Hmm, given that a proportional font like Helvetica works (even if the result isn't pretty), producing gibberish for these effectively monospaced fonts with ligatures seems to violate the POLA (Principle Of Least Astonishment). My prediction would be that not fixing it will just generate you a steady stream of discussions through the coming years, and you'll have to explain point to a statement each time that goes "no, we really mean monospaced and monospaced only when it comes to supported fonts, with the proper flag set and everything". > I'm afraid any half solution will just lead to more bugs about details > later. It might be better to just say that this font is not supported. Well, that could still remain the official slogan, or we could dub it "experimental" or something if you think it helps. But the question will come back every now and then, I think... Kind regards, Manuel > -- > Engineers understand that their appearance only bothers other people and > therefore it is not worth optimizing. > (Scott Adams - The Dilbert principle) > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
