Hi Manual, 2016-08-09 16:10 GMT+09:00 manuelschiller.pimail via vim_dev < vim_dev@googlegroups.com>:
> 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:)." But you should be aware that your happiness comes to you only by > accident or fortune, not by design or code. > > Point taken. OTOH, saying the current glyph caching code for ascii > characters also fails horribly in some cases where as a non-technical user > who just happens to like (g)vim, you'd not expect it to fail - monospace > fonts or not. The question becomes a bit "which is the unhappier accident > or bad fortune?"... > > > The reason I'm sticking to monospace fonts comes here. If we were > making a text viewer, your patch would be sufficient. But actually what we > are making is an editor. We have to address other issues such as the one > you mentioned above to make vim truly and decently support ligatures. For > that purpose, the precondition that all fonts to be used are monospace, > could be helpful and make our work much simpler and easier. After that, we > could do something about "effectively" monospace fonts if necessary, > couldn't we? > > Feel free to do as you see fit. My point is that this little patch doesn't > change > anything in the big picture of things, so you're still free to plan > whatever > architectural changes you may have in the pipeline, and I'm sure we'll all > be happy > when they materialise, whoever comes up with them. At the same time, that > ugly little > patch fixes a issue with some fonts not rendering to anything > intelligible. In fact, > if I want I can do a "set guifont=Helvetica\ 12", and I get something I > can read. I > know you don't officially support proportional fonts, and it sure doesn't > look > pretty. That's what I get for trying. But, and this is a big but: It's > readable. > Every single last character of it. For these fonts with ligatures in the > ascii > range, the result is very different, and quite unreadable. You may like or > not like my patch, but that is something it improves - maybe it was written > and advertised for the wrong reasons, but it does improve on that. > > > > > By the way, why didn't you honestly talk to the people here about the > issue you've already noticed till now? As you guessed, I didn't install > the fonts in question on my PC nor tried your patch, because I easily > predicted from the code that your patch had such an issue you mentioned > above. That's why I'm sticking to monospace; it's for getting us ready for > addressing possible other issues your patch has. Not a pretext for > rejecting your patch on behalf of old-school people. > > > Well, I'm occasionally doing a some code review myself (in high energy > physics). When somebody sends something, I generally give them the benefit > of a doubt, and try their patch first. (Sometimes I also say "I don't have > time right now, can we come back to this in a month or two?". That's > equally acceptable.) > > You also seem to expect a newcomer who's trying to figure out things in > vim as he goes along to have the same level of proficiency as you do. I'm > not sure that's entirely fair. But be that as it may. Since the patch was > that transparent for you, you might have asked for clarification on these > specific points right away, saving us both a lot of typing... > > > That said, it's OK for me to stop talking right now if you think I'm not > qualified for a reviewer because of those. That helps me enjoy the coming > vacation without anything bothering me. > > 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. > > 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 :) > 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 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+u...@googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- 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.
