bug#35468: [PATCH] Refactor draw_glyph_string on X and w32

[Alan Third]

On Thu, May 02, 2019 at 12:14:10PM -0600, Alex Gramiak wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > It looks exactly the same to me with or without the code. Perhaps I’d
> > see something different if I was using some theme which defined mouse
> > face differently.
> >
> > I really don’t see any reason why NS should behave differently from
> > the other terms here.
> 
> There's a similar block in ns_maybe_dumpglyphs_background. Could you
> test with that block removed as well? Also, there's a conditional check
> (s->hl != DRAW_CURSOR) there that's not present in the other versions;
> could you see if that's necessary?

Removing the block in ns_maybe_dumpglyphs_background seems to make no
difference here. Removing the DRAW_CURSOR check results in the cursor
being drawn as a blank (background colour) rectangle on occasion.

I’m not sure what the difference is, but there are a couple of
comments in nsterm.m which reference NS drawing the cursor differently
to other terms, i.e.

  /* We draw the cursor (with NSRectFill), then draw the glyph on top
     (other terminals do it the other way round).  We must set
     w->phys_cursor_width to the cursor width.  For bar cursors, that
     is CURSOR_WIDTH; for box cursors, it is the glyph width.  */

and 

  /* NOTE: under NS this is NOT used to draw cursors, but we must avoid
     overwriting cursor (usually when cursor on a tab).  */

and I suspect this check is related.
-- 
Alan Third