From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#73838: 31.0.50; Problems in note_mouse_highlight if -nw Date: Thu, 17 Oct 2024 07:07:44 +0200 Message-ID: References: <86r08goy76.fsf@gnu.org> <86msj3q4t0.fsf@gnu.org> <86iktrpe46.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15830"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 73838@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 17 07:10:07 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t1Ilz-0003wU-5A for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Oct 2024 07:10:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t1Ill-0007MX-99; Thu, 17 Oct 2024 01:09:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1Ila-0007LN-5G for bug-gnu-emacs@gnu.org; Thu, 17 Oct 2024 01:09:43 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t1IlZ-00006Q-SI for bug-gnu-emacs@gnu.org; Thu, 17 Oct 2024 01:09:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=brupAr7YpdB1Ia3U0U9m/iOMb/prcv1S4SYu/Xr/vKo=; b=GFbICZghiptOZyYfppH3DaTQ/wwME9usaLGcsgprMUJDfqhrjTkB2W6XC7ERUv7fgFyYeTf6CMDss5tNalzwk6UZHpDvEQgeGABn0Mv5VHP+tkgIJyikF371u24qf4oz86nl+T48KulGOZiYtZ9QcvW9ig53ZFJuaJOBUGQ9nkuuvld/Y1+71ICaKjTwgVYyxxqmZWt1SKv2nOthcY1HUknG5Y44TQtH98aU7vve/Nf4T/ciWNH2FR3wKd8lzaXMQhku/je1RMj34dnvjr6J2eqXv54aN4vOrJlnIE2q+07StyXFrsp9c9JAxgld3lWDwQDYWiSCy4b3Q8qCU/xFxQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t1Ilu-0002CX-5X for bug-gnu-emacs@gnu.org; Thu, 17 Oct 2024 01:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Oct 2024 05:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73838 X-GNU-PR-Package: emacs Original-Received: via spool by 73838-submit@debbugs.gnu.org id=B73838.17291417568371 (code B ref 73838); Thu, 17 Oct 2024 05:10:02 +0000 Original-Received: (at 73838) by debbugs.gnu.org; 17 Oct 2024 05:09:16 +0000 Original-Received: from localhost ([127.0.0.1]:33033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Il9-0002Aw-GQ for submit@debbugs.gnu.org; Thu, 17 Oct 2024 01:09:15 -0400 Original-Received: from mail-wm1-f44.google.com ([209.85.128.44]:47164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1Il6-0002Ai-VI for 73838@debbugs.gnu.org; Thu, 17 Oct 2024 01:09:13 -0400 Original-Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4314c4cb752so5383855e9.2 for <73838@debbugs.gnu.org>; Wed, 16 Oct 2024 22:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729141666; x=1729746466; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=brupAr7YpdB1Ia3U0U9m/iOMb/prcv1S4SYu/Xr/vKo=; b=N8ZEUkGxuw136qA4Is5XPeSw7UiAvA2BjsDbhzdiLsIMyL3V1aqj/rkmlUzuzp7z2D 3sW+KGeKo8pE1yFnk9vt0EovIu03K8NeQGzm6Sa49pASX3JzSf1YaQiI2+vxzUADep0E RBYbtILwceAml6cTHuORt4WRwCfOpfaCWOYfnPE3Af8gFNBOYt4LjtqF90ITVyHIG3Fp uyoyNxS9VkyiYSwPIVw9dGmS+Lz4DTbEq5WkUVcV3e+zK9E1+iU2+RtjEeyTH+jQMOts QKPMNq7RWVas2FKWvXFi/UTLiB/TNNBv0rqhEQQdwyD00vwbFDXYptJAcx0D+KimNODh rHvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729141666; x=1729746466; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=brupAr7YpdB1Ia3U0U9m/iOMb/prcv1S4SYu/Xr/vKo=; b=sYLIEc9dNc7GHZXti0cu96Y5z40O9jYJY4tUpk/lq3uwSLZG1yVvcyRZY5tMOXvYMZ zP9l+tK2trjgRk1r5GaA5nhQDiEqwU0fmm6qrnh9R7Btfxp4lNjK/giFEB8YcRuK/9/C ZCf2OP5/zN7m8nUyhzrMG4Xo+oLHICWOZNW7aUGSbKwxYB5/pbf/7iAy+TjRJBOXeb8l c6yH3EjzRAZhRCdLtp0YJZ8StW/2MEa7jYFZO4PIRVNdc/KJWcOnzO16ef4Brz6DqK7s H5JS9k3b15js25qwyt+j4kT8/BW7ZMnMY2fQ6vfdSJZoSD7kQXlqV9dfvy4HWvbWVdqO qF/g== X-Gm-Message-State: AOJu0YwhrX23SsrDv+OwVSjYqRAInnAAIQgtddilbt8WhNx3YvoOlmeo 59Pe88G56ouKUMMvoRuD1kSE3UA2CgC4/zaDQ2t90YIfnwtifXAjMyMdXg== X-Google-Smtp-Source: AGHT+IHFqqkGLYkONJ6EiQxSxQDql817KefuhnMaVZuyOykm/49LAhUlz/CSiyfwezj6wkJjBXrP6A== X-Received: by 2002:a05:600c:5248:b0:42c:b5f1:44ff with SMTP id 5b1f17b1804b1-4311df56fc6mr201462095e9.24.1729141665727; Wed, 16 Oct 2024 22:07:45 -0700 (PDT) Original-Received: from pro2 (pd9e36829.dip0.t-ipconnect.de. [217.227.104.41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43158c5062csm13144345e9.41.2024.10.16.22.07.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 22:07:45 -0700 (PDT) In-Reply-To: <86iktrpe46.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 17 Oct 2024 07:06:33 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:293703 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 73838@debbugs.gnu.org >> Date: Wed, 16 Oct 2024 21:03:15 +0200 >>=20 >> > 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. >>=20 >> 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. >>=20 >> I've just dragged the FRAME_WINDOW_P out of this stuff because the >> whole if-statement is concerned with cursor =3D ... using FRAME_OUTPUT_D= ATA. > > My suggestion is to extend 'struct tty_display_info' so that > FRAME_OUTPUT_DATA on TTY frames will not access unrelated memory, when > these macros/inline functions are called. Alternatively, we could have > the macros/functions (FRAME_INTERNAL_BORDER etc.) test for TTY frame > and DTRT. FRAME_OUTPUT_DATA is meaningful only for window system frames. Each window system's "term" header defines it. For example xterm.h: #define FRAME_X_OUTPUT(f) ((f)->output_data.x) #define FRAME_OUTPUT_DATA(f) FRAME_X_OUTPUT (f) nsterm.h: #define FRAME_OUTPUT_DATA(f) ((f)->output_data.ns) and so on. So using FRAME_OUTPUT_DATA is per se only valid if FRAME_WINDOW_P. Which is equivalent to FRAME_NS_P in my case, or whatever someone uses. #ifdef HAVE_X_WINDOWS #define FRAME_WINDOW_P(f) FRAME_X_P (f) #endif #ifdef HAVE_NS #define FRAME_WINDOW_P(f) FRAME_NS_P(f) #endif #ifndef FRAME_WINDOW_P #define FRAME_WINDOW_P(f) ((void) (f), false) #endif I think changing that would be a major surgery. It's probably easier to add checks like I did in the patch to FRAME_OUTPUT_DATA if the frame in questioin is indeed a window system frame. It can be decided at run-time only anyway. The other idea is, IIUC, is to make code using FRAME_OUTPUT_DATA like this one if (FRAME_INTERNAL_BORDER_WIDTH (f) > 0 && !NILP (get_frame_param (f, Qdrag_internal_border))) { enum internal_border_part part =3D frame_internal_border_part (f, x, = y); switch (part) { case INTERNAL_BORDER_NONE: if (cursor !=3D FRAME_OUTPUT_DATA (f)->nontext_cursor) /* Reset cursor. */ cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; work by making sure that their if-conditions can't be true, if there any. In the above case by making FRAME_INTERNAL_BORDER_WIDTH return 0 if the frame is not FRAME_WINDOW_P. In other cases like this one if (EQ (window, f->tool_bar_window)) { note_tool_bar_highlight (f, x, y); cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; or here if (part =3D=3D ON_MODE_LINE || part =3D=3D ON_HEADER_LINE || part =3D=3D= ON_TAB_LINE || part =3D=3D ON_LEFT_MARGIN || part =3D=3D ON_RIGHT_MARGIN) { note_mode_line_or_margin_highlight (window, x, y, part); #ifdef HAVE_WINDOW_SYSTEM if (part =3D=3D ON_LEFT_MARGIN || part =3D=3D ON_RIGHT_MARGIN) { cursor =3D FRAME_OUTPUT_DATA (f)->nontext_cursor; /* Show non-text cursor (Bug#16647). */ goto set_cursor; } else #endif return; } by doing something else. I have to admit that I don't like that. I don't understand what is wrong to check FRAME_WINDOW_P before using something (using FRAME_OUTPUT_DATA) that requires FRAME_WINDOW_P to be valid.