Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Thursday, 15 September 2016 15:01:35 UTC+1, mcepl  wrote:
> On 2016-09-15, 12:33 GMT, manuelschiller.pimail via vim_dev wrote:
> > 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=[0x, 0xfc00, 0xf801, 0x7801]

Hi,

> I had to make some typo or something, because when copying this 
> line into my ~/.vimrc I got it working as before. Thank you!

glad that's sorted. :)

> > About the criticism that this is not the most user-friendly 
> > option to set: That's a very valid point. My reasoning was 
> > thus:
> 
> That was not my problem. Read 
> http://www.joelonsoftware.com/uibook/chapters/fog59.html
> 
> # Every time you provide an option, you're asking the user 
> # to make a decision.
> 
> I would even say, “you force the user to make decision”. And he 
> will be grumpy for that. You should apologize every time you 
> force user to do anything else than why he started to use your 
> program in the first place.

Interesting read. Thanks for the pointer.

> Which is why I said, that if you need this during the 
> development, then I don't care. However, if normal user ever 
> sees it, she will get fits and she would be right.

Well, I was thinking along the lines that using these special ligature glyphs 
is definitely a matter of preference. (For example, Bram had a pretty strong 
opinion about ">=/<=" and how he would not like to see ligatures for these 
combinations, I seem to remember.)

I thought that not setting any option in .vimrc will produce usable output 
(without ligatures) which is fine for the majority of people who don't care 
about ligatures. No choice involved for the unsuspecting user, it'll just work, 
and produce unsurprising output for a hassle-free editing session (albeit 
without the ligature eye-candy... ;).

For those who want ligatures, they'll have to look at the patch at the moment, 
and set a variable in their .vimrc. In the long run, we should have a nice 
front end for that, and provide documentation, so it becomes easier to see what 
needs to be put into .vimrc.

I didn't know about the article when I wrote this, but the logic of the 
previous two paragraphs seems to tie in with the spirit of the article's last 
paragraph or so. Displaying ligatures (or not) is a matter of preference, and 
options should allow users to fine-tune what they would like to see. For people 
who don't care, they don't need to set anything, and get vim's old 
(ligature-less) behaviour that they're used to.

I'll do a more careful reading of the article tonight, in case I missed 
something important (which could well be - feel free to point it out, since I 
only skimmed the article so far).

> > - The "user-facing part" depends very much on what people 
> > would like to have.
> 
> “Nothing” is the only possible answer, I think.
> 
> > That said, I'm very happy for suggestions (or patches), and 
> > will try to have a draft ready soonish when suggestions do 
> > trickle in. :)
> 
> Thank you very much for your work, despite my criticism.

I appreciate the criticism! You haven't convinced me yet to change the default, 
but I'm willing to be convinced by the right argument. From what I've grasped 
from the article, I tend to lean more towards the current implementation 
(although I think we need something more user-friendly for the users who want 
ligatures).

But ultimately, what we come up with will have to convince the rest of the 
community, so it doesn't matter that much what I think, anyway. :) So keep the 
arguments coming...

Cheers, and thanks,

Manuel

> Matěj
> 
> -- 
> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>  
> Quod fuimus, estis; quod sumus, vos eritis.

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

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

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=[0x, 0xfc00, 0xf801, 0x7801]
> 
> >
> 
> > > >
> 
> >
> 
> > > > 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=[0x, 0xfc00, 0xf801, 0x7801]
> 
> >
> 
> >
> 
> >
> 
> > 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&

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

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=[0x, 0xfc00, 0xf801, 0x7801]
> 
> > >
> 
> > > 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=[0x, 0xfc00, 0xf801, 0x7801]
> 
> 
> 
> 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

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

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=[0x, 0xfc00, 0xf801, 0x7801]
> > 
> > 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=[0x, 0xfc00, 0xf801, 0x7801]

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Tuesday, 13 September 2016 23:21:01 UTC+1, mcepl  wrote:
> On 2016-08-08, 12:50 GMT, Tony Mechelynck wrote:
> > You should see, in that order, the glyphs for ff fi fl ft st 
> > ffi ffl.
> > I absolutely don't like them (in the monospaced fonts that 
> > have them; in serif or sans-serif fonts it's different, 
> > especially in serif italic). OTOH, I think that expanding them 
> > to two or three character cells would be ugly the opposite 
> > way.
> 
> It could be the problem with your font. I use 
> https://github.com/tonsky/FiraCode/ and it seems to work for me 
> just fine.
> 
> Matěj
> 
> -- 
> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>  
> May you come to the attention of those in authority.
> May you find what you are looking for.
> May you live in interesting times.
>-- claimed to be a Chinese proverb, but its origin is disputed
>   first documented use
>   Frederic R. Coudert, Proceedings of the Academy of Political Science, 
> 1939

Hi,

glad to see that people give it a try. You may want to use the updated version 
of the patch here:

https://github.com/manuelschiller/vim/commit/0c8d6a735f1f6452b11c0da039f8c9c9f125475a

It allows users to hand-tune for which characters they want to bypass the glyph 
cache by putting a line in .vimrc, e.g.

let g:gtk_nocache=[0x, 0xfc00, 0xf801, 0x7801]

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!

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Saturday, 13 August 2016 22:27:33 UTC+2, manuelschi...@googlemail.com  wrote:
> On Saturday, 13 August 2016 19:55:23 UTC+2, manuelschi...@googlemail.com  
> wrote:
> > On Thursday, 11 August 2016 19:30:57 UTC+2, Stefan Schwarzer  wrote:
> > > On 2016-08-11 17:40, Kazunobu Kuriyama wrote:
> > > > 2016-08-11 23:44 GMT+09:00 Ken Takata :
> > > >> Screenshot attached.  (I haven't try PragmataPro.)
> > > > 
> > > > I don't either for an obvious reason..Isn't there a free version? :)
> > > 
> > > As far as I know there's no free version. The cheapest is the
> > > "PragmataPro Essential" version for 19 Euro plus tax [1]. :-/
> > > 
> > > Maybe it would make sense to ask [2] the author for a reduced
> > > subset to try things out. If I remember correctly, someone in
> > > the forum section (at [1]) suggested having such a "test version"
> > > and the font author seemed open to the idea. If you want, I can
> > > contact the author and ask.
> > > 
> > > [1] http://www.fsd.it/shop/fonts/pragmatapro/
> > > (There's no dedicated page for the Essential version, but it's
> > > selectable from the "Weights" list.)
> > > 
> > > [2] http://www.fsd.it/contact-me/
> > > 
> > > Best regards,
> > > Stefan
> > 
> > Hi,
> > 
> > okay, good to know that Mac and Windows already have at least partial 
> > support for ligatures.
> > 
> > In the meantime, I've amended the patch that enables "poor man's ligatures" 
> > on GTK2/3. Now, the user can select for which ASCII characters < 128 the 
> > glyph cache should be bypassed (thus enabling ligatures). This is done by 
> > checking a global vim variable, g:gtk_nocache. If unset, not a list, empty, 
> > the wrong length, or set to [0, 0, 0, 0], the default behaviour is 
> > retained. For those who want to see ligatures in most cases, I recommend to 
> > set it to [0x, 0xfc00, 0xf801, 0x7801], which will 
> > bypass the glyph cache for everything but control characters, space, 
> > [0-9A-Za-z] and ASCII code 127 (it's a simple bitmap with bits set if the 
> > cache is to be bypassed). You can find the patch on the glyphs branch in my 
> > github repository 
> > (https://github.com/manuelschiller/vim/commit/d45b7745bd8118748b234e10d8fb9bb80053fa52).
> >  It does not solve any of the redrawing/cursor movement related issues that 
> > were discussed earlier, but it will at least give users a choice if they 
> > want their favourite font glitch-free without ligatures, or with ligatures 
> > (and still the occasional ^L).
> > 
> > Feel free to give it a try, or let me know what's bad and good about it. In 
> > any case, I'm looking forward to feedback.
> > 
> > Cheers,
> > 
> > Manuel
> 
> Hi,
> 
> here's another observation which I hadn't made before consciously: With the 
> gtk3 version of the GUI, the artifacts with ligatures are virtually gone: 
> While typing, ligatures like "<=" compose themselves while typing, and the 
> artifact of "decomposing" the ligature when moving the cursor that I 
> described earlier (and with the gtk2 backend) is virtually gone. In the 
> latter case, you can see a very weak "echo" of the "unligatured" character 
> under the cursor that was used to compose the ligature, but that goes away 
> without a trace when you move the cursor away, and over normal text. It's 
> also absent when the cursor has "blinked off". For example, when you move the 
> cursor over the "<=" combination with PragmataPro, you'll see the "<=" 
> ligature very clearly. But when the cursor blinks to on, it'll also show a 
> single "<" or "=" overlaid with the original screen contents which disappears 
> without the trace when the cursor blinks off again, or is moved away.
> 
> Bottom line: it seems that with the gtk3 backend for the GUI, you'll have an 
> almost glitch-free experience with programming fonts with ligatures like 
> Hasklig or PragmataPro. You'll still need the patches I pointed to in my 
> previous e-mail, though.
> 
> Cheers,
> 
> Manuel

Hi,

since Bram kindly included a fix that will make the ASCII glyph cache usable 
with fonts with ligatures, I revised my patch that enables said ligatures to 
the extent possible with current code to work with Bram's patches. For those 
that do not want to wait until vim officially supports ligatures (if it ever 
will - but I remain optimist ;), the patch will be maintained here:

https://github.com/manuelschiller/vim/commits/glyphs

The commit message 
(https://github.com/manuelschiller/vim/commit/7a25336eed7b2082c016db36f80b2bb9345a4e3f)
 contains hints on how to fine-tune for which ASCII characters the glyph cache 
will be bypassed, so you have at least some vimrc-level control over which 
ligatures you want to see.
I'd recommend the GTK3 GUI backend over the GTK2 one for this patch, since the 
number of times you want to press ^L is vastly reduced.

I'll try to keep pace with vim development in the sense that I'll update the 
patch as needed, and as time permits (feel free to send a 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Saturday, 13 August 2016 19:55:23 UTC+2, manuelschi...@googlemail.com  wrote:
> On Thursday, 11 August 2016 19:30:57 UTC+2, Stefan Schwarzer  wrote:
> > On 2016-08-11 17:40, Kazunobu Kuriyama wrote:
> > > 2016-08-11 23:44 GMT+09:00 Ken Takata :
> > >> Screenshot attached.  (I haven't try PragmataPro.)
> > > 
> > > I don't either for an obvious reason..Isn't there a free version? :)
> > 
> > As far as I know there's no free version. The cheapest is the
> > "PragmataPro Essential" version for 19 Euro plus tax [1]. :-/
> > 
> > Maybe it would make sense to ask [2] the author for a reduced
> > subset to try things out. If I remember correctly, someone in
> > the forum section (at [1]) suggested having such a "test version"
> > and the font author seemed open to the idea. If you want, I can
> > contact the author and ask.
> > 
> > [1] http://www.fsd.it/shop/fonts/pragmatapro/
> > (There's no dedicated page for the Essential version, but it's
> > selectable from the "Weights" list.)
> > 
> > [2] http://www.fsd.it/contact-me/
> > 
> > Best regards,
> > Stefan
> 
> Hi,
> 
> okay, good to know that Mac and Windows already have at least partial support 
> for ligatures.
> 
> In the meantime, I've amended the patch that enables "poor man's ligatures" 
> on GTK2/3. Now, the user can select for which ASCII characters < 128 the 
> glyph cache should be bypassed (thus enabling ligatures). This is done by 
> checking a global vim variable, g:gtk_nocache. If unset, not a list, empty, 
> the wrong length, or set to [0, 0, 0, 0], the default behaviour is retained. 
> For those who want to see ligatures in most cases, I recommend to set it to 
> [0x, 0xfc00, 0xf801, 0x7801], which will bypass the glyph 
> cache for everything but control characters, space, [0-9A-Za-z] and ASCII 
> code 127 (it's a simple bitmap with bits set if the cache is to be bypassed). 
> You can find the patch on the glyphs branch in my github repository 
> (https://github.com/manuelschiller/vim/commit/d45b7745bd8118748b234e10d8fb9bb80053fa52).
>  It does not solve any of the redrawing/cursor movement related issues that 
> were discussed earlier, but it will at least give users a choice if they want 
> their favourite font glitch-free without ligatures, or with ligatures (and 
> still the occasional ^L).
> 
> Feel free to give it a try, or let me know what's bad and good about it. In 
> any case, I'm looking forward to feedback.
> 
> Cheers,
> 
> Manuel

Hi,

here's another observation which I hadn't made before consciously: With the 
gtk3 version of the GUI, the artifacts with ligatures are virtually gone: While 
typing, ligatures like "<=" compose themselves while typing, and the artifact 
of "decomposing" the ligature when moving the cursor that I described earlier 
(and with the gtk2 backend) is virtually gone. In the latter case, you can see 
a very weak "echo" of the "unligatured" character under the cursor that was 
used to compose the ligature, but that goes away without a trace when you move 
the cursor away, and over normal text. It's also absent when the cursor has 
"blinked off". For example, when you move the cursor over the "<=" combination 
with PragmataPro, you'll see the "<=" ligature very clearly. But when the 
cursor blinks to on, it'll also show a single "<" or "=" overlaid with the 
original screen contents which disappears without the trace when the cursor 
blinks off again, or is moved away.

Bottom line: it seems that with the gtk3 backend for the GUI, you'll have an 
almost glitch-free experience with programming fonts with ligatures like 
Hasklig or PragmataPro. You'll still need the patches I pointed to in my 
previous e-mail, though.

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Thursday, 11 August 2016 19:30:57 UTC+2, Stefan Schwarzer  wrote:
> On 2016-08-11 17:40, Kazunobu Kuriyama wrote:
> > 2016-08-11 23:44 GMT+09:00 Ken Takata :
> >> Screenshot attached.  (I haven't try PragmataPro.)
> > 
> > I don't either for an obvious reason..Isn't there a free version? :)
> 
> As far as I know there's no free version. The cheapest is the
> "PragmataPro Essential" version for 19 Euro plus tax [1]. :-/
> 
> Maybe it would make sense to ask [2] the author for a reduced
> subset to try things out. If I remember correctly, someone in
> the forum section (at [1]) suggested having such a "test version"
> and the font author seemed open to the idea. If you want, I can
> contact the author and ask.
> 
> [1] http://www.fsd.it/shop/fonts/pragmatapro/
> (There's no dedicated page for the Essential version, but it's
> selectable from the "Weights" list.)
> 
> [2] http://www.fsd.it/contact-me/
> 
> Best regards,
> Stefan

Hi,

okay, good to know that Mac and Windows already have at least partial support 
for ligatures.

In the meantime, I've amended the patch that enables "poor man's ligatures" on 
GTK2/3. Now, the user can select for which ASCII characters < 128 the glyph 
cache should be bypassed (thus enabling ligatures). This is done by checking a 
global vim variable, g:gtk_nocache. If unset, not a list, empty, the wrong 
length, or set to [0, 0, 0, 0], the default behaviour is retained. For those 
who want to see ligatures in most cases, I recommend to set it to [0x, 
0xfc00, 0xf801, 0x7801], which will bypass the glyph cache for 
everything but control characters, space, [0-9A-Za-z] and ASCII code 127 (it's 
a simple bitmap with bits set if the cache is to be bypassed). You can find the 
patch on the glyphs branch in my github repository 
(https://github.com/manuelschiller/vim/commit/d45b7745bd8118748b234e10d8fb9bb80053fa52).
 It does not solve any of the redrawing/cursor movement related issues that 
were discussed earlier, but it will at least give users a choice if they want 
their favourite font glitch-free without ligatures, or with ligatures (and 
still the occasional ^L).

Feel free to give it a try, or let me know what's bad and good about it. In any 
case, I'm looking forward to feedback.

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Wednesday, 10 August 2016 02:37:38 UTC+2, Stefan Schwarzer  wrote:
> I recently purchased a license for PragmataPro and ran into
> the same problem as Manuel. During my research I came across
> his patch (many thanks, Manuel!) and I subscribed to the list
> to follow the discussion on the patch and possibly
> contribute to the exchange.
> 
> Here are my thoughts on the current discussion. (I had
> considered to add these "inline," but changed my mind
> because I think this would make the text _less_ accessible.)
> 
> If you want to use the ligatures in PragmataPro in GVim,
> your only choice is a GVim with the patch from Manuel.
> Without the patch, there's no readable text.
> 
> As I understand it, both the original code and the patch
> make an assumption about the possible characters in a
> ligature, and these assumptions can still be wrong.
> 
> The original code with its optimization was checked in about
> twelve years ago. I wonder if it nowadays would be feasible
> to remove the optimization altogether, i. e. replace it with
> straightforward code that doesn't make a (still potentially
> wrong) assumption about "valid" or "reasonable" character
> combinations for ligatures.
> 
> I'm aware that this is a trade-off. Possibly some users will
> be noticeably affected by slower rendering, but on the other
> hand you get simpler and more robust code. I haven't seen a
> suggestion of removing the optimization yet, so I'm not sure
> if it's an implicit consensus that the optimization is still
> needed or if this idea didn't come to mind at all. Don't get
> me wrong: I'm not even suggesting removing the optimization,
> but I'm suggesting _considering_ it, even if the result of
> this consideration is to keep the optimization. :-)
> 
> Like Manuel, I noticed artifacts when moving the cursor over
> ligatures. Note that the cursor movement can also happen if
> the cursor isn't moved by the user, that is, if `showmatch`
> is set. To reproduce this:
> 
> - compile GVim with the patch from Manuel
> - start this GVim without a file
> - :set guifont=PragmataPro\ 10
> - :set matchpairs+=<:>
> - :set showmatch
> - insert  <= >=
> - press  to leave insert mode
> - press ctrl-L to make the ligatures render if that didn't
>   happen yet
> - move the cursor onto the  >  which was just inserted
> - observation: the cursor jumps to the left onto the  <  in
>   <=  and the ligature is garbled (a  <  followed by the
>   right half of the  <=  ligature)
> - expectation: the ligature isn't changed or is only changed
>   as long as the cursor is on it
> 
> Regardless of the rendering issues, so far they've always
> been fixed easily by pressing ctrl-L. Even with the current
> imperfections, I'd rather have the patch soon in a regular
> GVim version than not being able to use the ligatures at all
> for a potentially long time.
> 
> In the long run, I'm absolutely fine if the ligatures are
> temporarily "decomposed" if the cursor moves over them, but
> it would be nice if each ligature was rendered correctly if
> the cursor doesn't cover it anymore.
> 
> Regarding the thought that merging the patch will make users
> ask for more: Yes, that's probably true. On the other hand,
> not including the patch will also have users ask for more,
> namely support of ligatures in programmer fonts. :-)
> 
> Thank you all for working on Vim. I've been using it since
> about 20 years and I'm very glad it exists!
> 
> Best regards,
> Stefan

Hi Stefan,

thanks for giving it a try, I appreciate it! Keep that feedback
coming (I'll keep reading mail), and we can hopefully make
ligatures in vim happen at some point. I'll keep updating patches
at the github repo I mentioned in my last mail.

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Wednesday, 10 August 2016 02:35:04 UTC+2, Tony Mechelynck  wrote:
> Manuel:
> 
> In the past there have been "unofficial" features published as patches
> which remained outside of the "official" Vim repositories but publicly
> available, sometimes for years, before Bram finally decided to take
> them in. The +conceal and +float features, now part of mainstream Vim,
> are two examples of such which I've seen remain "unofficial
> third-party patches" while several successive minor versions of Vim
> came and went.
> 
> Maybe you could publish your patch (as a patch that could be applied
> by running "patch -p1 ligatures.diff", or something like that, at the
> top level of a Vim repository clone), upload it somewhere on github or
> vim.org or wherever, and let anyone use it who wants. Then after
> letting it bake there for some time, we'll know better how popular it
> is. Assuming that the new version currently being made ready will be
> called Vim 8.0 and be released before the end of 2016, we might then
> have a poll about your patch when getting ready for 8.1 or 8.2, and
> let's hope that that will arrive long before 8.0 is at patchlevel
> 8.0.2200 — Vim 7.4, whose original release was almost exactly three
> years ago, seems to have been quite successful in its own way.
> 
> If you choose to go this way, please set it up so that it could be
> disabled at compile-time (I mean, place the changes  behind #ifdef
> FEAT_LIGATURES or something equally distinctive), it will help it
> being accepted into the main code, since anyone not wanting it would
> be able to disable it at compile-time — and similarly, an option (to
> enable or disable it at runtime if present at compile-time, let's say
> in the vimrc or gvimrc before starting the GUI) would IMHO be equally
> welcome.
> 
> 
> Best regards,
> Tony.

Hi Tony,

you (and others) are making very good points here, and I appreciate the
feedback.

Following your suggestion, I have created a vim fork with a branch for
this kind of development:

https://github.com/manuelschiller/vim/tree/glyphs

Currently, it contains two patches:

- gui_gtk_x11: force shaping one character at a time for ASCII glyph cache

  This one does what it says. It'll get fonts like PragmataPro or Hasklig
  working in gvim without ligatures, and without the drawing caveats we
  discussed earlier. I imagine that this patch might make inclusion in vim
  quite a bit earlier (I'd hope soonish, but that may be wishful thinking)
  than the next item, because I do not think it does anything controversial.
  If you'd like to see style improvements etc., please let me know, I'm
  happy to accomodate you. :)

- gui_gtk_x11: enable poor man's ligatures

  This one is the bit that enables ligatures, and will require a couple of
  iterations on my side before it's ready to be considered for inclusion.
  (For example, I'd like to make the set of characters that disable the
  ASCII glyph cache user-configurable, and I have to find out how C code
  gets access to variables inside vimscript...) For the curious, this is
  something they might want to try out, and give feedback...

I would again like to thank you all for the friendly and constructive
atmosphere. And let me know if you have suggestions, please!

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

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 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

Hi Kazunobu,

On Tuesday, 9 August 2016 15:46:38 UTC+2, Kazunobu Kuriyama  wrote:
> Hi Manuel
> 
> 2016-08-09 20:06 GMT+09:00 manuelschiller.pimail via vim_dev 
> <vim...@googlegroups.com>:
> 
> 
> Dear Kazunobu,
> 
> If you don't mind, please consider using friendlier 'Hi' instead of 'Dear.'   
> It's OK to me even if you omit greeting itself.
> 

Done. :) Now I just have to remember...

> 
> On Tuesday, 9 August 2016 12:03:47 UTC+2, Kazunobu Kuriyama  wrote:
> 
> > Hi Manual,
> 
> I'm sorry about my writing your name wrongly. 
> 
 
I get that about once a week to every two weeks in my inbox, and actually 
consider it a bit of a compliment when people compare me to the fine manual 
which each and every one of the of course has read most dilligently, 
intentionally or otherwise... ;) So: No worries, as long as I get that you're 
trying to send me a message, it's all good...

> 
> > [...]
> 
> > Okay, fair enough. :) It might take some time though, since I'll be moving 
> > to a different country to start a new job in the coming month.
> 
> I see.  You are busy for a while.
> 
> > Actually, that gives me its own convenience.  It gives me some time to make 
> > myself get accustomed to ligature fonts and their usage on Vim.  Nothing 
> > wrong.
> 

Have fun. Just be careful, you might not want to go back to something truely 
monospaced... ;)

> 
> > What direction would you like to see things heading? I'll most likely be no 
> > good at finding the ultimate patch that gets everything right because I'm 
> > not enough of an expert in the font rendering library field - it only 
> > dawned on me what was going wrong in that code recently.
> > 
> > If you'd want the ultimate ligature-clean solution, I anticipate one would 
> > need to revamp much of the gtk display code to update the right bits of the 
> > screen and keep the relation between glyph and characters, especially for 
> > the cursor drawing routines, so the right bit gets redrawn. That's a tall 
> > order, and I feel my C and gtk/pango skills are a bit too much in the range 
> > from non-existant to rusty for that. (My C++ is good, but that doesn't help 
> > here. ;) Moreovwe, we may want to use a patch along the lines I suggested 
> > to gain a bit of experience to learn about what's important in this 
> > business before we try and design the patch that solves all ligature 
> > issues... It may involve bug reports, and users asking for features, but 
> > that's very good feedback once we understand where the problem is, guiding 
> > us toward a better solution.
> 
> If you don't have any clear direction on that, how about rethinking all the 
> issues that have been raised in this thread so far.  You might find some of 
> them needed to be fixed or might get a better idea to address them.
> 
> Doing that would tell us (hints of) what we need to know and what we have to 
> do.
> 

Well, I'll see what I can do. For non-latin and non-greek alphabets, there's 
not much I can do because I know too little about those writing systems to know 
how things should look, though... I will need help (and potentially an expert) 
on that front.

> 
> > In the meantime, I may be able to clean up the glyph cache for ascii codes 
> > < 128, for example, by having a shaping call per character code, so we only 
> > need to store a single glyph in the cache, if you feel that would help. One 
> > could also think about making the ascii code range which passes through the 
> > glyph cache configurable, if you guys would prefer that over the static 
> > list like the one I took over from the original patch proposition. 
> 
> I think it's worth a try.  Even if an effort fails, that will help us 
> understand why the current way is not bad.
> 

Okay.

> > Is there anything else I can do that you or others would feel is valuable 
> > to have? Feel free to keep the suggestions coming...
> 
> I'd also like to hear the voices of people who want to see ligatures on Vim.
> 

I agree. I'm just not sure how many we'll attract from off-list (or how many 
people on-list are interested) without having a demonstrator patch out there 
for which people can hand in suggestions. But we can cross that bridge when we 
have to.

Cool, that sounds like a plan.

Cheers,

Manuel

> 
> Best regards,
> Kazunobu
> 
> 
> 
> 
> All the best,
> 
> 
> 
> Manuel
> 
> 
> 
> 
> 
> 
> 
> > Kind regards, and enjoy your vacation,
> 
> >
> 
> >
> 
> >
> 
> > Thanks,
> 
> > Kazunobu 
> 
> >
> 
> >
> 
> > Manuel
> 
> >
> 
> >
> 
> >

Re: [vim/vim] VIM 7.4: Possible regression via patch 2146? (#972)

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 19:59:21 UTC+2, Jaren Stangret  wrote:
> Hello,
> 
> 
> With patch 2146 (4724728), text may be inserted while backspacing or typing 
> if you have configured VIM to automatically display a popup menu with 
> possible completions.  This is most noticeable when trying to backspace on a 
> word that has a possible match.
> 
> 
> Using vim -u NONE alleviates this use, but that would be expected.
> 
> 
> I'm currently using ACP to handle autocompletion.

Hi,

I think I'm seeing the same thing (with YouCompleteMe). The behaviour is really 
strange: some completion gets appended to what I type without me actually 
selecting it, and I sometimes cannot even backspace over it because it seems to 
keep appending more than one characte for a single press of backspace key 
press. Reverting patch 2146 seems to cure the issue for me, too. Not sure if 
that helps anybody in tracking it down.

Manuel
 
> Using the below patch fixes/reverts the issue (on HEAD) for me:
> 
> diff --git a/src/edit.c b/src/edit.c
> index 6dae4a0..2281232 100644
> --- a/src/edit.c
> +++ b/src/edit.c
> @@ -3893,7 +3893,7 @@ ins_compl_prep(int c)
> 
> /* CTRL-E means completion is Ended, go back to the typed text.
>  * but only do this, if the Popup is still visible */
> -   if (c == Ctrl_E && pum_visible())
> +   if (c == Ctrl_E)
> {
> ins_compl_delete();
> 
> 
> 
> 
> Hopefully someone can shed some insight on this.  I'm unsure if it's a bug in 
> VIM or the plugins implementation of the VIM popup via ACP.
> 
> 
> Below is the git bisect where I traced from patch 1051(af8af8b) to patch 
> 2181(a772ec5):
> 
> git bisect start
> # good: [af8af8bfac5792fa64efbc524032d568cc7754f7] patch 7.4.1051 Problem:
> Segfault when unletting "count". Solution:   Check for readonly and locked 
> first. (Dominique Pelle) Add a test.
> git bisect good af8af8bfac5792fa64efbc524032d568cc7754f7
> # bad: [a772ec5e91efbd5c4b99bb5cf5704a6c6f0baf3f] patch 7.4.2181 Problem:
> Compiler warning for unused variable. Solution:   Remove it. (Dominique Pelle)
> git bisect bad a772ec5e91efbd5c4b99bb5cf5704a6c6f0baf3f
> # good: [a4f6ca717b4483eb82c6c71f71a5a5cf70e55d80] patch 7.4.1618 Problem:
> Starting job with output to buffer changes options in the current 
> buffer. Solution:   Set "curbuf" earlier. (Yasuhiro Matsumoto)
> git bisect good a4f6ca717b4483eb82c6c71f71a5a5cf70e55d80
> # good: [28b942a064dd486cc241894b625ab72f5a5c6d1b] patch 7.4.1900 Problem:
> Using CTRL-] in the help on "{address}." doesn't work. Solution:   Recognize 
> an item in {}. (Hirohito Higashi, closes #814)
> git bisect good 28b942a064dd486cc241894b625ab72f5a5c6d1b
> # good: [93431df9eb02f7cf3d7f2142bb1bef24c5f325b2] patch 7.4.2043 Problem:
> setbuvfar() causes a screen redraw. Solution:   Only use aucmd_prepbuf() for 
> options.
> git bisect good 93431df9eb02f7cf3d7f2142bb1bef24c5f325b2
> # good: [ad9c2a08f0509294269a2f11a59a438b944bdd5a] patch 7.4.2109 Problem:
> Setting 'display' to "lastline" is a drastic change, while 
> omitting it results in lots of "@" lines. Solution:   Add "truncate" to show 
> "@@@" for a truncated line.
> git bisect good ad9c2a08f0509294269a2f11a59a438b944bdd5a
> # good: [bc8801c9317eb721a2ee91322669f2dd5d136380] Updated runtime files.
> git bisect good bc8801c9317eb721a2ee91322669f2dd5d136380
> # bad: [7522f6982197f83a5c0f6e9af07fb713934f824a] patch 7.4.2162 Problem:
> Result of getcompletion('', 'sign') depends on previous 
> completion. Solution:   Call set_context_in_sign_cmd(). (Dominique Pelle)
> git bisect bad 7522f6982197f83a5c0f6e9af07fb713934f824a
> # bad: [ee695f787ade7fd88fc5f5497553d95c0c3645b5] patch 7.4.2152 Problem:
> No proper translation of messages with a count. Solution:   Use ngettext(). 
> (Sergey Alyoshin)
> git bisect bad ee695f787ade7fd88fc5f5497553d95c0c3645b5
> # bad: [abb71fbd399772d467aaa7b34b958b0f975c7e65] patch 7.4.2147 Problem:
> test_alot fails. Solution:   Close window.
> git bisect bad abb71fbd399772d467aaa7b34b958b0f975c7e65
> # good: [86f2cd5bc574c23fa276d7f57cd1300e24222913] patch 7.4.2145 Problem:
> Win32: Using CreateThread/ExitThread is not safe. Solution:   Use 
> _beginthreadex and return from the thread. (Ken Takata)
> git bisect good 86f2cd5bc574c23fa276d7f57cd1300e24222913
> # bad: [472472898ab71ac80a86fedc37f8eb91461788dd] patch 7.4.2146 Problem:
> Not enough testing for popup menu.  CTRL-E does not always work 
> properly. Solution:   Add more tests.  When using CTRL-E check if the popup 
> menu is visible. (Christian Brabandt)
> git bisect bad 472472898ab71ac80a86fedc37f8eb91461788dd
> # first bad commit: [472472898ab71ac80a86fedc37f8eb91461788dd] patch 7.4.2146 
> Problem:Not enough testing for popup menu.  CTRL-E does not always work   
>   properly. Solution:   Add more tests.  When using CTRL-E check if 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

Dear Kazunobu,

On Tuesday, 9 August 2016 12:03:47 UTC+2, Kazunobu Kuriyama  wrote:
> Hi Manual,
> 
> [...]
> Well, the trouble is that I think you likely are qualified to review that 
> patch, despite me being a newcomer who cannot really tell because I don't 
> know who does what, and who is experienced in which field. But somehow, we 
> seem to have gotten off on the wrong foot (which may be my fault, and if it 
> is, I'm sorry), or you seem to feel really strongly that the code should only 
> deal with true monospaced fonts. That's a bit of a pity because I think we're 
> both trying to make vim a little bit better (even if it's in a frightfully 
> limited way in my case). By the way, your vacation remark I find a bit 
> insulting in this context.
> 
> 
> Apologies to you for that. 
> 
No need, I rather speak up when something is getting beyond my confort zone, 
but before I actually feel seriously insulted. And I guess I'm at the very 
least sharing the blame for the escalation... :) Sorry for that again, and for 
the noise!
> 
> >  My assertion is that people using these programming fonts will be happy to 
> > see these ligatures assemble/disassemble as they edit across them.
> 
> >
> 
> > Once people view ligatures on Vim, they will ask us more for the purpose of 
> > editing them in a way each individual thinks better...
> 
> >
> 
> Yep, that's the sign of people doing a good job - people ask for more. :) In 
> a sense, that's what I'm doing as well (I hope you see that as a compliment!).
> 
> 
> 
> Seriously, I don't mean to aggravate you or anybody else, or cloud your 
> vacation in any way. Maybe we postpone this until you're back from vacation, 
> and we've both had some time to think it over? 
> 
> 
> That sounds good...but considering the fact that the ligature patch now looks 
> gaining momentum for the first time in two years (as Bram shows an interest 
> in it), I think your keeping working on it while I'm off could lead to a 
> good, even better and faster, result.  So I'd like to say to you, "Keep it 
> up!  Over my dead body!", though it's all up to you :)
> 

Okay, fair enough. :) It might take some time though, since I'll be moving to a 
different country to start a new job in the coming month.

What direction would you like to see things heading? I'll most likely be no 
good at finding the ultimate patch that gets everything right because I'm not 
enough of an expert in the font rendering library field - it only dawned on me 
what was going wrong in that code recently.

If you'd want the ultimate ligature-clean solution, I anticipate one would need 
to revamp much of the gtk display code to update the right bits of the screen 
and keep the relation between glyph and characters, especially for the cursor 
drawing routines, so the right bit gets redrawn. That's a tall order, and I 
feel my C and gtk/pango skills are a bit too much in the range from 
non-existant to rusty for that. (My C++ is good, but that doesn't help here. ;) 
Moreovwe, we may want to use a patch along the lines I suggested to gain a bit 
of experience to learn about what's important in this business before we try 
and design the patch that solves all ligature issues... It may involve bug 
reports, and users asking for features, but that's very good feedback once we 
understand where the problem is, guiding us toward a better solution.

In the meantime, I may be able to clean up the glyph cache for ascii codes < 
128, for example, by having a shaping call per character code, so we only need 
to store a single glyph in the cache, if you feel that would help. One could 
also think about making the ascii code range which passes through the glyph 
cache configurable, if you guys would prefer that over the static list like the 
one I took over from the original patch proposition. Is there anything else I 
can do that you or others would feel is valuable to have? Feel free to keep the 
suggestions coming...

All the best,

Manuel


> Kind regards, and enjoy your vacation,
> 
> 
> 
> Thanks,
> Kazunobu 
> 
> 
> Manuel
> 
> 
> 
> > Best,
> 
> > Kazunobu
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > 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).
> 
> >
> 
> >
> 
> >
> 
> > I hope this 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

Dear Kazunobu,

On Tuesday, 9 August 2016 07:28:43 UTC+2, Kazunobu Kuriyama  wrote:
> 2016-08-09 6:35 GMT+09:00 manuelschiller.pimail via vim_dev 
> <vim...@googlegroups.com>:
> 
> On Monday, 8 August 2016 22:27:11 UTC+2, Bram Moolenaar  wrote:
> 
> > Manuel Schiller wrote:
> >
> > [...]
> >
> 
> 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 ;). 
> 
> 
> putty, konsole, qterminal, and gvim...There's a obvious difference between 
> the first three and the last; the former are terminals and the latter is an 
> editor.
> 
> If you think of the difference of their usages, you'll notice that even small 
> hiccups on terminals could much matter on editors, in particular for users 
> who must have the cursor go to and fro to view and edit files for hours.

Let's not confuse terminals and gvim here.

On terminals (even those that "paint" ligatures, even if it is with some 
glitches due to the way in which those terminals treat them), (text mode) vim 
is very usable. I should know because I stare at vim in a terminal for a big 
part of my day, especially when things tunnel through ssh. My patch (whether it 
is applied or not) does not change vim's behaviour when running in a terminal.
  
My point is that gvim with the patch is no worse than those terminals with the 
"glitches" when the cursor moves across a ligature. gvim without the patch is 
quite a bit worse because you cannot read what's in the window with some fonts.

For gvim, I could envisage a couple of options that people may decide on:
  * we could leave things as they are:
- true monospaced fonts will work fine
- my "effectively monospaced fonts" will display gibberish
- people may start filing bug reports which you may or may not choose to 
close
  right away again with the hint that gvim only supports monospaced fonts
  * if we had a patch that did ligatures in "effectively monospaced fonts" 
perfectly,
you might choose to apply it (but who knows when we'll have it?)
  * we may use an imperfect patch along the lines that I suggested - it's not 
the
last word on the matter, but it'll improve the display with these fonts from
completely unreadable to something readable that is approaching what was
intended, even if I'm not quite there in solving all the issues yet with 
this patch...
 
> That's something we should not underestimate, isn't that?  Probably, some of 
> the users wouldn't be patient enough to put up with it and would soon file 
> bug reports once your patch was merged into the upstream.
 
Well, I could file such a bug report right now, and it wouldn't complain about 
little imperfections like what happens when the cursor moves across a ligature. 
The gvim window is unreadable without a patch along the lines suggested if you 
have such a font.

> You mentioned that gvim has less issues than the terminals.  But that's is a 
> side effect of redrawing by gvim for its own necessity, not for the sake of 
> ligatures.

I think that's because gvim with the patch is actually doing something a little 
more correct than these terminals do - it respects the character cell size for 
monospaced and effectively monospaced fonts, no matter what. So that's not due 
to vim redrawing when it needs it, but because gvim actually manages to 
calculate the right position in the window at which to draw the rendered glyphs.

> Your patch doesn't contain any code for that.  That has no redraw mechanism 
> to ensure ligatures to appear on the screen as/when they should.

No, it does not. That kind of thing happens inside pango at the moment. If 
someone more knowledgable comes along and has a good idea which fixes this, I'd 
be more than happy. 

> I'm glad to hear, "patched gvim doesn't do that, so I'm very happy with 
> it:)."

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 22:27:11 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.

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

I hope this clarifies things a bit.

Thanks for the interest,

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 21:27:36 UTC+2, Tony Mechelynck  wrote:
> On Mon, Aug 8, 2016 at 3:16 PM, manuelschiller.pimail via vim_dev
> <vim_dev@googlegroups.com> wrote:
> > On Monday, 8 August 2016 14:51:01 UTC+2, Tony Mechelynck  wrote:
> >> Well, if you let Pango do glyph reshaping for U+0020 to U+007F you
> >> might end up with what you said you didn't want, i.e. fi fl st ffi ffl
> >> digraphs and trigraphs, which in my experience are actually uglier (in
> >> monospaced fonts) than just letting the individual letters stand side
> >> by side. Try the following in a gvim (even unpatched) with 'encoding'
> >> set to utf-8 to see what I mean:
> >> 1. Enter Insert mode (i or a or o or whatever)
> >> 2. Type the following sequences (with no spaces). Each sequence should
> >> output one glyph.
> >> Ctrl-V u fb00
> >> Ctrl-V u fb01
> >> Ctrl-V u fb02
> >> Ctrl-V u fb03
> >> Ctrl-V u fb04
> >> Ctrl-V u fb05
> >> Ctrl-V u fb06
> >> You should see, in that order, the glyphs for ff fi fl ft st ffi ffl.
> >> I absolutely don't like them (in the monospaced fonts that have them;
> >> in serif or sans-serif fonts it's different, especially in serif
> >> italic). OTOH, I think that expanding them to two or three character
> >> cells would be ugly the opposite way.
> >
> > Point taken, but this is not what the patch does. The sets [A-Z], [a-z], 
> > [0-9], and ' ' are still drawn without glyph shaping, when there's nothing 
> > else in the string being drawn that requires it - just as the old code did. 
> > (And the old code also fell back to full glyph shaping once you move above 
> > character code 128, i.e. into the range where you start to get UTF-8 
> > encoded characters...) So in that sense, there's no substantial change in 
> > strategy.
> >
> > Also, I'm not changing the width of any glyph drawn, so there is no 
> > expansion of glyphs going on. It's just a question of how exactly the cache 
> > works that bypasses the glyph shaping (and which strings are allowed to 
> > bypass the glyph shaping process by going through the cache...).
> >
> > Are you proposing changes to the patch, or are you more concerned about how 
> > it'll look? In the former case, maybe you could outline which changes you'd 
> > like to see? In the latter case, why not just give the patch a try (e.g by 
> > typing one of the character combinations, and see if it does what you'd 
> > like it to do), and tell me which bits you don't like (which is much more 
> > productive than discussing in the abstract)?
> 
> I'm concerned about how it will look, and I wasn't aware that you were
> intentionally short-circuiting Pango for all letters and digits.
> 
> Yes, these 6 codepoints (U+FB01 to U+FB06) are above the ASCII range
> but they show examples of what one could get by replacing some
> particular pairs of letters. Similarly, the Arabic subsystem of Vim
> fetches its glyphs by (IIUC) altering their codepoint numbers
> depending on whether they're joined to a preceding character, or to a
> following character, or whether a lam and an alif are found together
> in that order, thus implementing the rules for Arabic character
> shaping by means of "presentation form" codepoints.
> 
> >
> > Kind regards,
> >
> > Manuel
> 
> Best regards,
> Tony.

Okay, now I understand - thanks for the clarification. Well, current vim code 
(and my patch) bypasses pango's glyph shaping completely in some cases. Current 
vim code does this if the string only contains code points <= 127. My patch 
restricts the range somewhat, so that glyph shaping occurs in more cases as 
with vanilla vim code. As far as I can tell, strings containing code points of 
128 and above are left alone with or without my patch, and pango deals with 
them the usual way by shaping, and then drawing the resulting glyphs...

Thanks,

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

Hi Kazunobu,

On Monday, 8 August 2016 18:31:40 UTC+2, Kazunobu Kuriyama  wrote:
> 2016-08-08 23:06 GMT+09:00 manuelschiller.pimail via vim_dev 
> <vim...@googlegroups.com>:
> 
> 
> On Monday, 8 August 2016 15:39:02 UTC+2, Kazunobu Kuriyama  wrote:
> 
> > If your windowing system is a recent X11 with fontconfig, do
> 
> >
> 
> >     $ fc-scan 
> 
> >
> 
> >
> 
> > then you'll have something human readable.
> 
> >
> 
> >
> 
> > Take a look at an item called 'spacing.'
> 
> >
> 
> >
> 
> > If you have none or the number zero, then the font is proportional.
> 
> > If you have the number 90, then the font is dual.
> 
> > If you have the number 100, then the font is monospace.
> 
> > If you have the number 110, then the font is charcell
> 
> 
> 
> Thanks, this is getting us somewhere. :)
> 
> 
> 
> I've run a couple of checks with the commands you suggested, and I get the 
> following results:
> 
> - DejaVu and PragmataPro Mono do indeed have the spacing attribute set to 100.
> 
> - Hasklig and PragmataPro do not, in fact they do not show a spacing 
> attribute. (However, as I tried to explain in that previous post in my own 
> frightfully limited way, they're effectively monospaced, and after glyph 
> shaping where appropriate, things will line up with the character cell layout 
> that the rendering code assumes, I think...)
> 
> 
> 
> By "if you have none..." I meant "(fc-scan) do(es) not show a spacing 
> attribute."
> 
> 
> Therefore, the conclusion is that both Hasklig and PragmataPro are 
> proportional.  No matter how they appear "effectively" monospaced to our 
> eyes, no rendering engine handles them as such.

I understand that now.

>
> Accordingly, Vim can't support them in an appropriate way and needn't.
> 

No, it need not do so, and for the general case of proportional fonts, I'm not 
trying to convince you, or anyone else. But the change required isn't a big 
one, and all it costs at runtime is a slightly more complicated initialisation 
of the cache bypassing the shaping, and a bit more memory for it (both of which 
are likely unnoticable among all the other things that gvim needs to do before 
it can start drawing characters in the edit section of the window). It also 
costs one left shift for the index into the cache. That's not what I'd call 
resource-hungry, or bloated. While I understand that vim wouldn't claim 
support, wouldn't it be nice if these effectively monospaced fonts would work 
to that extent at least?

> 
> Do you know any other fonts which have ligatures and are truly monospaced?   
> For such fonts, if any, I think there's room for consideration.
> 
> 
> 
> 
> So, apparently, there's monospaced fonts, and fonts that just happen to have 
> individual glyphs an intger multiple of the same width. I freely admit that I 
> did not know about this, and apologise if I have given offence in the process.
> 
> 
> 
> To my mind, the question the list now needs to decide is this: Do we want to 
> support these "effectively monospaced" fonts like Hasklig, or not? (I think 
> we should, but I'll abide by your decision, of course. :)
> 
> 
> 
> I haven't seen this community works like that.  Needless to say, it's only 
> you who can make a decision as to your way to go.
> 

Well, I have my patch which does what I want. :) If you think there's something 
salvagable from it (e.g. reworking the bit of the cache that has the assumption 
that pango shaping will give one glyph per input character), let me know, and 
I'll see what I can do in my free time.

But from what I gather from your reaction (if I read between the lines 
correctly), you'd rather not include any of it because the fonts in question 
are not truely monospaced in the sense you indicated. Fair enough.

All the best,

Manuel

> 
> Cheers,
> Kazunobu
> 
> 
> 
> 
> If the answer is yes, we can discuss which bits of the patch you'd like 
> cleaned up, and I'll do my best to provide something that's acceptable. Sorry 
> again for the "exchange of fire" earlier, I certainly didn't mean to hurt 
> anyone's feelings.
> 
> 
> 
> Best regards,
> 
> 
> 
> 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 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 15:39:02 UTC+2, Kazunobu Kuriyama  wrote:
> If your windowing system is a recent X11 with fontconfig, do
> 
>     $ fc-scan 
> 
> 
> then you'll have something human readable.
> 
> 
> Take a look at an item called 'spacing.'
> 
> 
> If you have none or the number zero, then the font is proportional.
> If you have the number 90, then the font is dual.
> If you have the number 100, then the font is monospace.
> If you have the number 110, then the font is charcell
 
Thanks, this is getting us somewhere. :)

I've run a couple of checks with the commands you suggested, and I get the 
following results:
- DejaVu and PragmataPro Mono do indeed have the spacing attribute set to 100.
- Hasklig and PragmataPro do not, in fact they do not show a spacing attribute. 
(However, as I tried to explain in that previous post in my own frightfully 
limited way, they're effectively monospaced, and after glyph shaping where 
appropriate, things will line up with the character cell layout that the 
rendering code assumes, I think...)

So, apparently, there's monospaced fonts, and fonts that just happen to have 
individual glyphs an intger multiple of the same width. I freely admit that I 
did not know about this, and apologise if I have given offence in the process.

To my mind, the question the list now needs to decide is this: Do we want to 
support these "effectively monospaced" fonts like Hasklig, or not? (I think we 
should, but I'll abide by your decision, of course. :)

If the answer is yes, we can discuss which bits of the patch you'd like cleaned 
up, and I'll do my best to provide something that's acceptable. Sorry again for 
the "exchange of fire" earlier, I certainly didn't mean to hurt anyone's 
feelings.

Best regards,

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 14:51:01 UTC+2, Tony Mechelynck  wrote:
> Well, if you let Pango do glyph reshaping for U+0020 to U+007F you
> might end up with what you said you didn't want, i.e. fi fl st ffi ffl
> digraphs and trigraphs, which in my experience are actually uglier (in
> monospaced fonts) than just letting the individual letters stand side
> by side. Try the following in a gvim (even unpatched) with 'encoding'
> set to utf-8 to see what I mean:
> 1. Enter Insert mode (i or a or o or whatever)
> 2. Type the following sequences (with no spaces). Each sequence should
> output one glyph.
> Ctrl-V u fb00
> Ctrl-V u fb01
> Ctrl-V u fb02
> Ctrl-V u fb03
> Ctrl-V u fb04
> Ctrl-V u fb05
> Ctrl-V u fb06
> You should see, in that order, the glyphs for ff fi fl ft st ffi ffl.
> I absolutely don't like them (in the monospaced fonts that have them;
> in serif or sans-serif fonts it's different, especially in serif
> italic). OTOH, I think that expanding them to two or three character
> cells would be ugly the opposite way.

Point taken, but this is not what the patch does. The sets [A-Z], [a-z], [0-9], 
and ' ' are still drawn without glyph shaping, when there's nothing else in the 
string being drawn that requires it - just as the old code did. (And the old 
code also fell back to full glyph shaping once you move above character code 
128, i.e. into the range where you start to get UTF-8 encoded characters...) So 
in that sense, there's no substantial change in strategy.

Also, I'm not changing the width of any glyph drawn, so there is no expansion 
of glyphs going on. It's just a question of how exactly the cache works that 
bypasses the glyph shaping (and which strings are allowed to bypass the glyph 
shaping process by going through the cache...).

Are you proposing changes to the patch, or are you more concerned about how 
it'll look? In the former case, maybe you could outline which changes you'd 
like to see? In the latter case, why not just give the patch a try (e.g by 
typing one of the character combinations, and see if it does what you'd like it 
to do), and tell me which bits you don't like (which is much more productive 
than discussing in the abstract)? 

Kind regards,

Manuel

> Best regards,
> Tony.
> 
> On Mon, Aug 8, 2016 at 1:50 PM, manuelschiller.pimail via vim_dev
> <vim_dev@googlegroups.com> wrote:
> > On Monday, 8 August 2016 12:33:44 UTC+2, Tony Mechelynck  wrote:
> >> On Mon, Aug 8, 2016 at 11:15 AM, manuelschiller.pimail via vim_dev
> >> <vim_dev@googlegroups.com> wrote:
> >> > On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama  wrote:
> >> >> 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev 
> >> >> <vim...@googlegroups.com>:
> >> >>
> >> >>
> >> >> On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
> >> >>
> >> >> > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
> >> >>
> >> >> > > Hello
> >> >>
> >> >> > >
> >> >>
> >> >> > > In a few words, here is a patch that makes gvim work better with 
> >> >> > > ligatures
> >> >>
> >> >> > > in fonts, which can be useful even for programmers. Details follow.
> >> >>
> >> >> > >
> >> >>
> >> >> > > I tried to use a Hasklig[^1], a font with ligatures intended for the
> >> >>
> >> >> > > Haskell language. It serves the same objective as the Haskell 
> >> >> > > Conceal
> >> >>
> >> >> > > script[^2], but with the added benefit that even a mouse copy-paste 
> >> >> > > works
> >> >>
> >> >> > > as intended.
> >> >>
> >> >> > > [^1]: https://github.com/i-tu/hasklig
> >> >>
> >> >> > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
> >> >>
> >> >> > >
> >> >>
> >> >> > > Unfortunately, gvim doesn't support ligatures on ASCII characters. 
> >> >> > > The
> >> >>
> >> >> > > following assertion fails at run-time:
> >> >>
> >> >> > >
> >> >>
> >> >> > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs 
> >> >> > > ==
> >> >>
> >> >> > > sizeof(ascii_chars)' failed
> >> >>
>

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 12:33:44 UTC+2, Tony Mechelynck  wrote:
> On Mon, Aug 8, 2016 at 11:15 AM, manuelschiller.pimail via vim_dev
> <vim_dev@googlegroups.com> wrote:
> > On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama  wrote:
> >> 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev 
> >> <vim...@googlegroups.com>:
> >>
> >>
> >> On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
> >>
> >> > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
> >>
> >> > > Hello
> >>
> >> > >
> >>
> >> > > In a few words, here is a patch that makes gvim work better with 
> >> > > ligatures
> >>
> >> > > in fonts, which can be useful even for programmers. Details follow.
> >>
> >> > >
> >>
> >> > > I tried to use a Hasklig[^1], a font with ligatures intended for the
> >>
> >> > > Haskell language. It serves the same objective as the Haskell Conceal
> >>
> >> > > script[^2], but with the added benefit that even a mouse copy-paste 
> >> > > works
> >>
> >> > > as intended.
> >>
> >> > > [^1]: https://github.com/i-tu/hasklig
> >>
> >> > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
> >>
> >> > >
> >>
> >> > > Unfortunately, gvim doesn't support ligatures on ASCII characters. The
> >>
> >> > > following assertion fails at run-time:
> >>
> >> > >
> >>
> >> > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs ==
> >>
> >> > > sizeof(ascii_chars)' failed
> >>
> >> > >
> >>
> >> > > and many characters are displayed with the wrong glyphs.
> >>
> >> > > The attached patch limits the function ascii_glyph_table_init() to
> >>
> >> > > spaces and alphanumeric chars. It solves the problem here.
> >>
> >> > >
> >>
> >> > > Yet I wonder if the current hack with ASCII characters is really 
> >> > > useful.
> >>
> >> > > Is there any performance test to check if a simpler behaviour wouldn't 
> >> > > be
> >>
> >> > > suitable, at least for modern desktop installations?
> >>
> >> > > As the code comment mentions spaces, maybe it should be restricted to
> >>
> >> > > blank lines?
> >>
> >> > >
> >>
> >> > > Regards
> >>
> >> > > --
> >>
> >> > > François
> >>
> >> >
> >>
> >> > This would be so great to see implemented.
> >>
> >>
> >>
> >> It certainly would (and apologies for reopening such an old discussion).
> >>
> >>
> >>
> >> On my system, the patch François sent doesn't work for the ligatures in 
> >> PragmataPro (but flawlessly for other fonts like Hasklig),
> >>
> >>
> >> According to http://www.fsd.it/shop/fonts/pragmatapro/ ,  PragmataPro has 
> >> "One typeface, 3 families for the right need":
> >>
> >>
> >>
> >> - PragmataPro is a spaced modularly font family with working ligatures.
> >> - PragmataPro Mono is a very monospaced without ligatures.
> >> - Essential PragmataPro is the cheap version to coding for English only.
> >>
> >>
> >> As you know, Vim is implemented by design only to support monospace font 
> >> families.
> >>
> >>
> >> So it looks to me that, among those three font families,  the only 
> >> possible and suitable choice for Vim to use with is PragmataPro Mono alone.
> >
> > In PragmataPro, all ASCII glyphs etc. are monospaced. Just as they are in 
> > PragmatePro Mono or Courier, or whatever your favourite monospaced font is. 
> > The difference between the two is what happens during shaping into glyphs 
> > inside pango (or another library): For fonts like Hasklig or PragmataPro, 
> > some combinations of ASCII characters get assigned a new glyph (the 
> > ligature) which looks better (e.g. "<=" might be replaced with a new glyph 
> > that more closely mimics the mathematical notation), but fits into the 
> > normal monospaced character grid. These ligature characters are two and 
>

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Sunday, 7 August 2016 15:19:48 UTC+2, Bram Moolenaar  wrote:
> Manu Schiller wrote:
> > Please let me know if it would be possible to include this, and if
> > not, at least the patch is public now where people can find it if they
> > want it.
> 
> Let's hear from a few people whether this works in various contexts.

That's all I can ask for. :)  (And it's anyway the drill I'm used to from my 
contributions to ROOT.) I'm willing to try and help fix any breakage, should we 
get any.

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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
> On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
> > Hello
> > 
> > In a few words, here is a patch that makes gvim work better with ligatures
> > in fonts, which can be useful even for programmers. Details follow.
> > 
> > I tried to use a Hasklig[^1], a font with ligatures intended for the
> > Haskell language. It serves the same objective as the Haskell Conceal
> > script[^2], but with the added benefit that even a mouse copy-paste works
> > as intended.
> > [^1]: https://github.com/i-tu/hasklig
> > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
> > 
> > Unfortunately, gvim doesn't support ligatures on ASCII characters. The
> > following assertion fails at run-time:
> > 
> > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs ==
> > sizeof(ascii_chars)' failed
> > 
> > and many characters are displayed with the wrong glyphs.
> > The attached patch limits the function ascii_glyph_table_init() to
> > spaces and alphanumeric chars. It solves the problem here.
> > 
> > Yet I wonder if the current hack with ASCII characters is really useful.
> > Is there any performance test to check if a simpler behaviour wouldn't be
> > suitable, at least for modern desktop installations?
> > As the code comment mentions spaces, maybe it should be restricted to
> > blank lines?
> > 
> > Regards
> > --
> > François
> 
> This would be so great to see implemented.

It certainly would (and apologies for reopening such an old discussion).

On my system, the patch François sent doesn't work for the ligatures in 
PragmataPro (but flawlessly for other fonts like Hasklig), apparently because 
the ASCII-to-glyph mapping won't quite work - I suspect that's due to 
PragmataPro having ligatures in that range, too. I solved this by inserting a 
space between characters that we hand to pango for shaping. Sane fonts will not 
have ligatures between a space and a printable character, this way we still get 
one glyph per ASCII character. I've attached the modified patch. This will work 
with normal fonts and ones with programming ligatures like Hasklig and 
PragmataPro; I've tested it with the gtk2 and gtk3 front ends.

Please let me know if it would be possible to include this, and if not, at 
least the patch is public now where people can find it if they want it.

Best regards,

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.


commit-2d7da14
Description: Binary data