Subject: bug#51095: 28.0.50; Counter-intuitive `cursor-intangible-mode' behavior

From: Brahimi Saifullah <[email-masked]>
Date: Fri, 08 Oct 2021 11:35:11 -0300

Let's start with the following example:
emacs -Q
M-: (insert "|" (propertize "xxxxx" 'cursor-intangible t) "|")
M-x cursor-intangible-mode

Result:
|xxxxx|
  ^^^^^ You can't move the cursor here

What I expected:
|xxxxx|
 ^^^^^ You can't move the cursor here

To clarify, although all the `X's are set to be intangible, you can still move
your cursor to the first one.  Furthermore, even though neither `|' has a text
property, you cannot move your cursor to the last one.

I tracked this behavior to the following function:
(from cursor-sensor.el, attached for convenience)

(defun cursor-sensor--intangible-p (pos)
  (let ((p (get-pos-property pos 'cursor-intangible)))
    (if p
        (let (a b)
          (if (and (setq a (get-char-property pos 'cursor-intangible))
                   (setq b (if (> pos (point-min))
                               (get-char-property (1- pos) 'cursor-intangible)))
                   (not (eq a b)))
              ;; If we're right between two different intangible thingies,
              ;; we can stop here.  This is not quite consistent with the
              ;; interpretation of "if it's sticky, then this boundary is
              ;; itself intangible", but it's convenient (and it better matches
              ;; the behavior of `intangible', making it easier to port code).
              nil p))
      p)))

This is the result of using `get-pos-property' instead of `get-char-property'.
If my understanding is correct, the difference in the former is its handling of
stickiness.  Thus I came up with the following:

(insert "|"
        (propertize
         (concat
          (propertize "x" 'front-sticky t)
          "xxx"
          (propertize "x" 'rear-nonsticky t))
         'cursor-intangible t)
        "|")

Basically, make the first character front-sticky, and the last character
rear-nonsticky.  Now it works as expected.

The question is: Is this behavior intuitive?
Is a Lisp program supposed to know that the portion of the text it has set to
be intangible is not actually accurate and must be manually adjusted?
To me it sounds not only unintuitive, but also like a bug.

In GNU Emacs 28.0.50 (build 1, x86_64-w64-mingw32)
 of 2021-09-21 built on COMPUTADOR
Repository revision: e4a9aa940beb032e97de6d4e4a23c2c9d94fdeb6
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19041
System Description: Microsoft Windows 10 Enterprise (v10.0.2004.19041.1237)

Configured using:
 'configure --with-native-compilation --with-json --with-imagemagick
 --without-pop'

Configured features:
ACL DBUS GIF GMP GNUTLS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBXML2
MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS XPM ZLIB

Important settings:
  value of $LC_CTYPE: pt_BR.UTF-8
  value of $LANG: PTB
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  cursor-intangible-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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 emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cursor-sensor pp cl-extra seq byte-opt gv bytecomp byte-compile cconv
cl-print time-date subr-x thingatpt help-fns radix-tree help-mode
cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars 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 w32notify dbusbind w32 lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 79446 8863)
 (symbols 48 7032 0)
 (strings 32 23818 1385)
 (string-bytes 1 730132)
 (vectors 16 14529)
 (vector-slots 8 305875 14414)
 (floats 8 30 40)
 (intervals 56 288 1)
 (buffers 992 13))