On Thursday, 15 September 2016 15:14:03 UTC+1, Kazunobu Kuriyama wrote: > 2016-09-15 22:43 GMT+09:00 manuelschiller.pimail via vim_dev > <vim...@googlegroups.com>: > > > Hi Kazunobu, > > > > On Thursday, 15 September 2016 14:33:48 UTC+1, Kazunobu Kuriyama wrote: > > > Hi Manuel, > > > > > > > > 2016-09-15 21:33 GMT+09:00 manuelschiller.pimail via vim_dev > > <vim...@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. > > > > I am confused. My patch shouldn't affect the terminal version of vim at all. > iTerm2 is thus a good way to see how other applications (here a terminal > emulator) deal with ligatures and screen updates (and if they do a good job, > you'll see ligatures because the terminal handles them). But that has nothing > to do with the patches I sent. > > > > If you want to see how my patch does, you will need to have a look at the GTK > version of vim to see anything happening (or not). > > > > I didn't mention your patch at all. So I don't understand why you were > confused.
Ah. That was me assuming things from the context, and boy, was I wrong... Now I get it. > Anyway, I just wanted to share the-state-of-the-art about the ligature issue > with you, suggesting that > use of g:gtk_nocache would not make the users happy. I'll have a look when I get the chance on someone else's laptop - this pointer is definitely appreciated. From what you write in you last mail, that's pretty much the behaviour I get from the gtk3 version by now. :) Cheers, and thanks, Manuel > Best, > Kazunobu > > > > > > 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. > > > > Agreed. Since I'm stuck with Linux for the time being (and don't really feel > like changing OS), I may have to ask a co-worker if they let me check things > out on their Macs... > > > > Cheers, > > > > Manuel > > > > > 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+u...@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+u...@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.
