2016-09-15 23:31 GMT+09:00 manuelschiller.pimail via vim_dev < [email protected]>:
> 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 < > [email protected]>: > > > > > > 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 < > [email protected]>: > > > > > > > > > > > > > > > > > > > > > > > > > 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 > Manuel, AFAICT, both iTerm2 and MacVim uses the class NSAttributedString and supports ligatures by tweaking the value of one of the attributes, called NSLigatureAttributeName [1]. (Of course, the reality is not that simple, though :) The attribute itself is virtually of an integer type and has only three different values: 0 (essential), 1 (standard), and 2 (all available). I feel this indicates that there's a possibility to narrow down overwhelmingly huge range of g:gtk_nocache to only three different predefined values, though I'm not sure if that will do or not. [1] https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/AttributedStrings/Articles/standardAttributes.html Best, Kazunobu > > > 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 [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. > > -- > -- > 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.
