cursor-intangible and rear-nonsticky t

cursor-intangible and rear-nonsticky t

[JD Smith]

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


I’m trying to make a bit of leading text (the ` …: ` continued block prompt in python shell) skippable, so that cursor navigation passes right by without entering it.  I used 'intangible at first and it works well.  Noticing Stefan’s concerns about 'intangible, I tried to switch to 'cursor-intangible with `cursor-intangible-mode' enabled.  But I encountered some strange issues:

If '(rear-nonsticky t) is among the text properties, the `pre-redisplay-functions' do not apparently get called, and so 'cursor-intangible fails to function.  
On MacOS ports, enabling `cursor-intangible-mode' causes the frame to aggressively regrab focus and re-raise when it loses focus.  This makes it unusable.

I expect the latter is a bug, but perhaps the former is expected? Thanks.

[-- Attachment #2: Type: text/html, Size: 1224 bytes --]

Re: cursor-intangible and rear-nonsticky t

[Stefan Monnier]

> If '(rear-nonsticky t) is among the text properties, the
> `pre-redisplay-functions' do not apparently get called, and so
> 'cursor-intangible fails to function.  

I don't think that's really what happens.  I suspect the issue comes
from the difference between `get-pos-property` and `get-char-property`:
positions (like `point`) are not placed on a character but between two
characters.  But text properties only apply to characters.  So the
properties that are "on a position" are based on what properties would
a character inherit if it where inserted at that position.

By default text properties are front-nonstick and rear-sticky, so
basically a position gets its properties from the char right before it.
But if you set (rear-nonsticky t), then you get no properties at all at
that position.

So, I suspect that you're applying (rear-nonsticky t) a bit too
generously, e.g. to all the chars in the prompt rather than only to the
last one.

> On MacOS ports, enabling `cursor-intangible-mode' causes the frame to
> aggressively regrab focus and re-raise when it loses focus.  This makes
> it unusable.

That's very weird and clearly a bug.


        Stefan

Re: cursor-intangible and rear-nonsticky t

[Stefan Monnier]

> So, I suspect that you're applying (rear-nonsticky t) a bit too
> generously, e.g. to all the chars in the prompt rather than only to the
> last one.

IIRC another way to do it is to only place the `cursor-intangible`
property between BEG and END-1, i.e. not on the last char of the prompt
and then you don't need any (rear-nonsticky t).


        Stefan

Re: cursor-intangible and rear-nonsticky t

[JD Smith]

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



> On Apr 5, 2021, at 12:47 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> If '(rear-nonsticky t) is among the text properties, the
>> `pre-redisplay-functions' do not apparently get called, and so
>> 'cursor-intangible fails to function.  
> 
> I don't think that's really what happens.  I suspect the issue comes
> from the difference between `get-pos-property` and `get-char-property`:
> positions (like `point`) are not placed on a character but between two
> characters.  But text properties only apply to characters.  So the
> properties that are "on a position" are based on what properties would
> a character inherit if it where inserted at that position.
> 
> By default text properties are front-nonstick and rear-sticky, so
> basically a position gets its properties from the char right before it.
> But if you set (rear-nonsticky t), then you get no properties at all at
> that position.
> 
> So, I suspect that you're applying (rear-nonsticky t) a bit too
> generously, e.g. to all the chars in the prompt rather than only to the
> last one.

Interesting, so `rear-nonsticky t` is rather powerful in suppressing text-properties within contiguous text.  

I believe `comint-output-filter` is the one responsible for setting `rear-nonsticky t` across the entire prompt:

	    (let ((prompt-start (save-excursion (forward-line 0) (point)))
		  (inhibit-read-only t))
             ...
	      (add-text-properties prompt-start (point) '(rear-nonsticky t)))


[-- Attachment #2: Type: text/html, Size: 13198 bytes --]

Re: cursor-intangible and rear-nonsticky t

[Stefan Monnier]

> I believe `comint-output-filter` is the one responsible for setting
> `rear-nonsticky t` across the entire prompt:
>
> 	    (let ((prompt-start (save-excursion (forward-line 0) (point)))
> 		  (inhibit-read-only t))
>              ...
> 	      (add-text-properties prompt-start (point) '(rear-nonsticky t)))

That's unfortunate.  Deserves a bug report, methinks.


        Stefan

Re: cursor-intangible and rear-nonsticky t

[JD Smith]

> On Apr 5, 2021, at 1:01 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> I believe `comint-output-filter` is the one responsible for setting
>> `rear-nonsticky t` across the entire prompt:
>> 
>> 	    (let ((prompt-start (save-excursion (forward-line 0) (point)))
>> 		  (inhibit-read-only t))
>>             ...
>> 	      (add-text-properties prompt-start (point) '(rear-nonsticky t)))
> 
> That's unfortunate.  Deserves a bug report, methinks.


Will do.  Between that and the focus-grabbing on MacOS ports, plain old ‘intangible is looking better and better.  It also doesn’t seem to care about over-generous application of ‘rear-nonsticky t. 

Re: cursor-intangible and rear-nonsticky t

[Stefan Monnier]

>>> I believe `comint-output-filter` is the one responsible for setting
>>> `rear-nonsticky t` across the entire prompt:
>>> 
>>> 	    (let ((prompt-start (save-excursion (forward-line 0) (point)))
>>> 		  (inhibit-read-only t))
>>>             ...
>>> 	      (add-text-properties prompt-start (point) '(rear-nonsticky t)))
>> 
>> That's unfortunate.  Deserves a bug report, methinks.
>
> Will do.  Between that and the focus-grabbing on MacOS ports, plain old
> ‘intangible is looking better and better.

The problem above is easy to workaround until the problem is fixed
upstream (by overriding comint's `rear-nonsticky` property with your
own).  For the MacOS issue, I have no idea: maybe it'll be difficult to
workaround, or maybe it's specific to unusual setups (really, I'm at
pains to imagine how `cursor-intangible-mode` can cause the problems you
describe, so I'd tend to suspect an interaction with some wild-west
package doing dangerous things).

> It also doesn’t seem to care about over-generous application of
> ‘rear-nonsticky t. 

It has its share of brokenness, don't worry ;-)


        Stefan

Re: cursor-intangible and rear-nonsticky t

[JD Smith]

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



> On Apr 5, 2021, at 2:47 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> The problem above is easy to workaround until the problem is fixed
> upstream


Yes a simple ‘(cursor-intangible t rear-nonsticky nil) seems to do it. 

> I'd tend to suspect an interaction with some wild-west
> package doing dangerous things)

Your suspicions are well-calibrated.  I haven’t yet figured out the culprit, but it was a package interaction issue. 

[-- Attachment #2: Type: text/html, Size: 2381 bytes --]

Re: cursor-intangible and rear-nonsticky t

[Stefan Monnier]

>> The problem above is easy to workaround until the problem is fixed
>> upstream
> Yes a simple ‘(cursor-intangible t rear-nonsticky nil) seems to do it. 

You might want to be more considerate of comint and preserve the
nonstickiness behavior for the properties that it places, e.g. something
like:

    (cursor-intangible t rear-nonsticky (field read-only inhibit-line-move-field-capture))

[ This value of `rear-nonsticky` is the I used in the patch I just
  installed into `master`.  ]

>> I'd tend to suspect an interaction with some wild-west
>> package doing dangerous things)
> Your suspicions are well-calibrated.  I haven’t yet figured out the culprit,
> but it was a package interaction issue.

Even if it doesn't end up with a bug report in Emacs, I'd be interested
to know what was the culprit and how it ended up behaving that way.


        Stefan