bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: 73838@debbugs.gnu.org
>> Date: Wed, 16 Oct 2024 18:56:53 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > How can scroll bars happen on TTY frames?
>> 
>> I'll try to answer this a bit more broadly: I'd like the code to be more
>> resilient, and not make implicit assumptions about the absence of of
>> features on ttys, which when false, leads to such hard to detect errors.
>> 
>> Consider the internal border case. In master, FRAME_INTERNAL_BORDER
>> happens to return 0 in master. But that might change, if I ever get
>> setting internal borders to work for tty child frames, to draw the
>> border there.
>
> But then we need to audit a lot more than just these bits.  E.g., who
> will guarantee that FRAME_WINDOW_P is always zero on TTY frames?

Quite unlikely, it's the only way we know what is in the output_data
union :-). Anyway.

>
> More seriously, I think we should prefer functional tests to
> declarative tests.  Which means not to assume that TTY frames can
> never have some display feature.  

That would be good. But if I may add that from my experience with the
child frames -- we're far from it.

> Thus, IMO your suggestion is in a sense a step back, because it
> assumes that TTY frames can never have these decorations and can never
> have different cursor types. So my suggestion would be to do the
> opposite: understand why FRAME_OUTPUT_DATA segfaults when dereferenced
> on TTY frames, and fix that so that it doesn't.

But the current situation is that we follow from the presence of an
internal border that it's a window system frame. We're using
FRAME_OUTPUT_DATA. If that would segv it would be a good thing. It
doesn't do that, it just silently accesses some unrelated memory (in my
case this is equivalent to casting the actual output_data contents to
(struct ns_output *) regardless of what it actually is.

I've just dragged the FRAME_WINDOW_P out of this stuff because the
whole if-statement is concerned with cursor = ... using FRAME_OUTPUT_DATA.