Re: nsterm.m: How to play nice with Mojave revisions -- #17684 (crosshairs) and #22873 (multiple fake cursors) ...

[Alan Third <athird@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On Fri, 12 Oct 2018, 02:54 Keith David Bershatsky, <esq@lawlist.com> 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?

>

[-- Attachment #2: Type: text/html, Size: 2562 bytes --]