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... ;) 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.
