bug#51251: 29.0.50; Moving cursor on top of raised box leaves artifacts around in NS port

bug#51251: 29.0.50; Moving cursor on top of raised box leaves artifacts around in NS port

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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


Move the cursor over a raised box, like the buttons in a customize
buffer.  Parts of the cursor will remain in the box even after the
cursor is moved out of the button.

I was told that this also occurs on macOS.

I've attached a patch that fixes the problem for me, but it hasn't been
tested on macOS.

(BTW, I'm noticing a general lack of interest in the NS port, where
features from the other ports can take months or even years to land,
especially WRT to GNUStep support.  If there's a list of TODOs with the
NS port, please let me know.  I'd be happy to help bring it up-to-spec.)

Thanks.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-erasing-cursor-on-top-of-raised-boxes-in-NS-port.patch --]
[-- Type: text/x-patch, Size: 1119 bytes --]

From 960f0eb9ab657af85c532574b937d8851049b178 Mon Sep 17 00:00:00 2001
From: Po Lu <luangruo@yahoo.com>
Date: Sun, 17 Oct 2021 21:12:03 +0800
Subject: [PATCH] Fix erasing cursor on top of raised boxes in NS port

* src/nsterm.m (ns_draw_relief): Clear top and bottom line areas
first, if required.
---
 src/nsterm.m | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/src/nsterm.m b/src/nsterm.m
index c6f80f8035..007a69ac70 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3516,6 +3516,12 @@ larger if there are taller display elements (e.g., characters
 
   [(raised_p ? lightCol : darkCol) set];
 
+  if (top_p)
+    {
+      NSRectFill (NSMakeRect (NSMinX (outer), NSMinY (outer),
+			      NSWidth (outer), hthickness));
+    }
+
   if (top_p || left_p)
     {
       NSBezierPath *p = [NSBezierPath bezierPath];
@@ -3555,6 +3561,12 @@ larger if there are taller display elements (e.g., characters
       [p closePath];
       [p fill];
     }
+
+  if (bottom_p)
+    {
+      NSRectFill (NSMakeRect (NSMinX (outer), NSMaxY (inner),
+			      NSWidth (outer), hthickness));
+    }
 }
 
 
-- 
2.31.1


[-- Attachment #3: Type: text/plain, Size: 3187 bytes --]


In GNU Emacs 29.0.50 (build 283, x86_64-pc-linux-gnu, NS gnustep-gui-0.29.0)
 of 2021-10-17 built on trinity
Repository revision: e5daab7a59da403c668ac727aaa9177c46b81360
Repository branch: master
Windowing system distributor 'GNU', version 10.3.29
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure --with-ns'

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBSELINUX LIBSYSTEMD
LIBXML2 MODULES NOTIFY INOTIFY NS PDUMPER PNG RSVG SECCOMP SOUND THREADS
TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr help-fns radix-tree cl-print debug backtrace
help-mode find-func emacsbug message rmc puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs time-date
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils cus-theme eieio-custom xwidget url-handlers image-mode dired
dired-loaddefs exif browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars mailcap bookmark text-property-search
wid-browse tree-widget seq gv subr-x byte-opt bytecomp byte-compile
cconv cus-edit pp cus-start cus-load wid-edit cl-loaddefs cl-lib ispell
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify gnustep ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 96866 10077)
 (symbols 48 10162 1)
 (strings 32 31452 3082)
 (string-bytes 1 950843)
 (vectors 16 19045)
 (vector-slots 8 253053 19351)
 (floats 8 49 45)
 (intervals 56 453 0)
 (buffers 992 15))

bug#51251: 29.0.50; Moving cursor on top of raised box leaves artifacts around in NS port

[Alan Third]

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

On Sun, Oct 17, 2021 at 09:14:39PM +0800, Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> 
> Move the cursor over a raised box, like the buttons in a customize
> buffer.  Parts of the cursor will remain in the box even after the
> cursor is moved out of the button.
> 
> I was told that this also occurs on macOS.
> 
> I've attached a patch that fixes the problem for me, but it hasn't been
> tested on macOS.

Hmm, your patch effectively undoes the change in

    Fix NS inset rectangle corners
    9ce3fdc461c9ec799ccbdc9281e392b0b77efd2b

I've attached my attempt to fix it. (Also not tested on macOS, but I
can't see why it wouldn't work there.)
-- 
Alan Third

[-- Attachment #2: 0001-Fix-inset-rectangle-corners-when-sides-aren-t-drawn-.patch --]
[-- Type: text/x-diff, Size: 1207 bytes --]

From 2317d81c7060a3b2826b76b064502006ddb84f98 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sun, 17 Oct 2021 19:30:59 +0100
Subject: [PATCH] Fix inset rectangle corners when sides aren't drawn
 (bug#51251)

* src/nsterm.m (ns_draw_relief): Make the inner rectangle line up with
the outer rectangle's edges where the edges aren't drawn.
---
 src/nsterm.m | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index c6f80f8035..aa29c13eb2 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3512,7 +3512,12 @@ larger if there are taller display elements (e.g., characters
     }
 
   /* Calculate the inner rectangle.  */
-  inner = NSInsetRect (outer, hthickness, vthickness);
+  inner = NSMakeRect (NSMinX (outer) + (left_p ? hthickness : 0),
+                      NSMinY (outer) + (top_p ? vthickness : 0),
+                      NSWidth (outer) - (left_p ? hthickness : 0)
+                                      - (right_p ? hthickness : 0),
+                      NSHeight (outer) - (top_p ? vthickness : 0)
+                                       - (bottom_p ? vthickness : 0));
 
   [(raised_p ? lightCol : darkCol) set];
 
-- 
2.33.0

bug#51251: 29.0.50; Moving cursor on top of raised box leaves artifacts around in NS port

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alan Third <alan@idiocy.org> writes:

> I've attached my attempt to fix it. (Also not tested on macOS, but I
> can't see why it wouldn't work there.)

Works here, thanks.

bug#51251: 29.0.50; Moving cursor on top of raised box leaves artifacts around in NS port

[Alan Third]

On Mon, Oct 18, 2021 at 08:10:49AM +0800, Po Lu wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > I've attached my attempt to fix it. (Also not tested on macOS, but I
> > can't see why it wouldn't work there.)
> 
> Works here, thanks.

Excellent, pushed to Emacs 28.

Thanks.
-- 
Alan Third