On Fri, 12 Oct 2018, 02:54 Keith David Bershatsky, <
address@hidden> wrote:
Given the latest revisions to nsterm.m that provide compatibility with Mojave, I have been unable to get the drafts of feature requests #17684 (crosshairs) and #22873 (multiple fake cursors) to work properly.
The draft feature request work by calling from xdisp.c:
FRAME_RIF (f)->draw_window_cursor (w, glyph_row, x, y, cursor_type,
cursor_width, true, active_cursor_p);
And, I modify a few settings such as color, coordinates, (x, y, fx, fy and h), cursor_type ...
As far as I can see, ns_clip_to_row (within ns_draw_window_cursor) does not return ON/TRUE with the drafts of feature requests #17684 / #22873.
If I play around by bypassing ns_clip_to_row and force ON/TRUE within ns_draw_window_cursor, the lines containing the fake cursors are inverted -- like Emacs is upside down.
Any ideas how I can properly convince ns_clip_to_row to return ON/TRUE and also have the fake cursors appear right-side-up at the non-inverted frame-Y coordinate?
Hi Keith, this looks a bit strange.
The idea is that when running redisplay cocoa does not let you draw to the screen, so ns_clip_to_rect, etc., marks the area as needing to be redrawn later, and returns NO so you know not to try drawing to the frame.
Later drawRect is called with a list of the areas that have been marked as needing redrawn and it calls expose on those areas and so Emacs runs the drawing functions again, but this time ns_clip_to_rect returns YES so you know you can go ahead and draw.
For some reason NSTRACE doesn't show the functions being called from within drawRect, so if you're relying on that it may mislead you.
I don't know what's going on with your code, is there somewhere I can have a look?