Hi Manuel, 2016-09-15 21:33 GMT+09:00 manuelschiller.pimail via vim_dev < vim_dev@googlegroups.com>:
> On Wednesday, 14 September 2016 20:38:27 UTC+1, Christian Brabandt wrote: > > Hi, > > > > On Mi, 14 Sep 2016, manuelschiller.pimail via vim_dev wrote: > > > > > > > > let g:gtk_nocache=[0x00000000, 0xfc00ffff, 0xf8000001, 0x78000001] > > > > > > This contains a bitmap for each character < 128, which has the > > > corresponding bit set if the glyph cache is to be bypassed (which in > > > turn enables ligatures). The default is no ligatures, unless people > > > set something like above in their .vimrc. With this slightly more > > > sophisticated patch, people have the option to enable/disable certain > > > ligatures by routing the corresponding characters through the cache > > > (or not) without recompiling, if they so prefer. > > > > > > Comments remain welcome! > > > > I appreciate your effort you put into this. But for the hell of it, I > > can't understand how the values inside g:gtk_nocache are supposed to > > work. Can you please describe more in detail, what each value stands > > for? > > > > I am afraid this needs some documentation and possibly a different > > format. We don't have something similar like this. Perhaps a new type > > for the 'renderoptions'? > > > > Best, > > Christian > > -- > > Ich habe etliche mal bemerkt, daß ich Kopf-Weh bekam, wenn ich mich > > lange in einem Hohl-Spiegel betrachtete. > > -- Georg Christoph Lichtenberg > > Hi Matěj, Christian, > > I've added the value which is equivalent to the previous patch, i.e. > > " this should keep character 0-31 (control characters), and [0-9A-Za-z] > flowing > " through the glyph cache, and the rest < 128 will bypass it > let g:gtk_nocache=[0x00000000, 0xfc00ffff, 0xf8000001, 0x78000001] > > So, if you're looking to see "<=" as a combined glyph, and your font has a > ligature for that combination, you should see it with the setting above. > > About how these values work: This is a bitmap, specifying with a set bit > which of the first 128 characters bypass the glyph cache. To check > character i, you'd check (a[i / 32] & (1u << (i % 32))), if a refers to the > array g:gtk_nocache, and you assume standard C notation. > > About the criticism that this is not the most user-friendly option to set: > That's a very valid point. My reasoning was thus: > > - Internally, we need something that's quick to handle inside a tight loop > in the glyph rendering code, so something complex such as a list of > characters or a regexp is out. This bitmap thing is quite nice, since it > doesn't take up much memory, and it is easy and fast to do lookups. As an > internal representation, that appears to do the job nicely. > > - The "user-facing part" depends very much on what people would like to > have. I haven't written this part for two reasons yet: The first reason is > that I am unsure what people would prefer. The second reason, I'll keep to > myself for another couple of sentences, and continue with my thought > process. I was thinking that it should be possible to provide a little vim > script/function that takes the list of characters for which to bypass the > glyph cache (or those for which not to bypass it), and set g:gtk_nocache > from that. What form this takes depends very much on what users want. This > brings me to the second reason why the user-facing part of vim script > doesn't exist yet: I'm new to the vim code base and vim script, and I'm not > sure I will manage something usable on the first go. This will require some > iteration... ;) > I'm now giving a try to a nightly build iTerm2 with FiraCode to improve my general knowledge on the ligature issue. The terminal has started supporting ligatures since early August. With Vim on that particular terminal, the result is nearly perfect: - No drawing glitches are found when the cursor goes over ligature glyphs. - Other than specifying a font name at the Preferences Panel, you can enjoy ligatures with Vim just out of the box. Only the glitch I've found so far is that, when the cursor is over a double-width glyph, the right half of the glyph is gone. It might be good to give a glance at other implementations. Best regards, Kazunobu > That said, I'm very happy for suggestions (or patches), and will try to > have a draft ready soonish when suggestions do trickle in. :) > > Does this help? > > Cheers, > > 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 vim_dev+unsubscr...@googlegroups.com. > 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
