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.
> 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.
If we don't do this, then is there still any point in trying to support
this font that isn't really mono spaced?
I'm afraid any half solution will just lead to more bugs about details
later. It might be better to just say that this font is not supported.
--
Engineers understand that their appearance only bothers other people and
therefore it is not worth optimizing.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
