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

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

[Brahimi Saifullah]

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))

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

[Lars Ingebrigtsen]

Brahimi Saifullah <brahimi.saifullah@gmail.com> writes:

> 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

I can reproduce the behaviour, but unless I misunderstand something,
this seems like it's working as designed.

The cursor is really "between" two characters conceptually -- this is
easier to understand if you use a "bar" cursor.  So if you put the point
here:

|xxxxx|
 ^

then it's before the first x and after the first |.  (You can confirm by
entering a character when it's at that point.)

The behaviour at the end is more puzzling, but as you've found out, it's
because the properties don't have rear-nonsticky, so you can't put point
right after the final x.

So I think everything here is working as designed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Brahimi Saifullah]

I see, thanks for the clarification.

What really had me confused was that, when your cursor is
in that position (the first X), `describe-char' claims:
>There are text properties here:
>  cursor-intangible    t

Perhaps the manual entry explaining this property should
clarify the nuances of the usual character after point v.
this concept of point being between the characters.

Still, I find this behavior odd from an usability standpoint.
I did some grep'ing in the core and ELPA packages to see how
often the workaround of front/rear-nonsticky is used.
From a glance I could only find a couple of packages explicitly
doing that, but then again you can count the amount of packages
extensively using `cursor-intangible' on the fingers of one hand.
All in all, not a very conclusive search besides confirming
the current behavior is indeed desirable in some situations.

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

[Brahimi Saifullah]

( I realize now I've probably failed to reply properly.
            I'm resending my previous message,
           apologies if you've gotten it already        )

---------------------------------------------------------------------

I see, thanks for the clarification.

What really had me confused was that, when your cursor is
in that position (the first X), `describe-char' claims:
>There are text properties here:
>  cursor-intangible    t

Perhaps the manual entry explaining this property should
clarify the nuances of the usual character after point v.
this concept of point being between the characters.

Still, I find this behavior odd from an usability standpoint.
I did some grep'ing in the core and ELPA packages to see how
often the workaround of front/rear-nonsticky is used.
From a glance I could only find a couple of packages explicitly
doing that, but then again you can count the amount of packages
extensively using `cursor-intangible' on the fingers of one hand.
All in all, not a very conclusive search besides confirming
the current behavior is indeed desirable in some situations.

---------------------------------------------------------------------

Addendum: If you disagree, or otherwise can't think of any further improvements
          to that section (I can't think of any tangible suggestion myself),
          feel free to close this.

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

[Lars Ingebrigtsen]

Brahimi Saifullah <brahimi.saifullah@gmail.com> writes:

> Perhaps the manual entry explaining this property should
> clarify the nuances of the usual character after point v.
> this concept of point being between the characters.

Yup.  I've now added an explanation (and a code example) to the entry in
the manual in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

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

> 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.

If you want `xxxxx` to be intangible, that means you presumably still
want to be able to move the cursor between the two `|` but the cursor
movement should be "as if" the `xxxxx` was absent (so the `xxxxx` will
be either attached to the first `|` or to the second).

If so, where do you want to place the cursor when it's between the two `|`?
One choice is to place it right after the first `|`, another is to place
it right before the second `|`.  Both choices make sense, AFAICT, and
you haven't explicitly specified which you want (other than in this bug
report, that is), so the behavior you see looks OK to me.

You can control this behavior via the stickiness property.

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

But now you allow the cursor to be either before the `xxxxx` or after
the `xxxxx`, so they're not really intangible any more.  It seems you
want them to be "atomic" instead, which we do not directly support (you
can simulate it by marking the first four `x` as `intangible`, for
example).

> The question is: Is this behavior intuitive?

Depends what you want, obviously.


        Stefan