bug#33662: 26.1; Elisp manual, index entry `invisible/intangible text, and point' and target

[Drew Adams]

> > This index entry seems a bit wrong, or perhaps the targeted text is a
> > bit wrong - in this sense: There is no occurrence of "tangible" or
> > "intangible" in that node.  Using that index entry and arriving at
> that
> > node, a user can wonder what happened - why there is nothing there
> that
> > is explicitly about "intangible text".  Perhaps the node should make
> > some mention of intangibility.
> 
> The section is about text that is intangible in the sense that that
> point is automatically moved away from such text.
> 
> > The text of that node did mention intangible originally, but Stefan
> > removed that as part of fixing bug#10222.  I'll let Stefan explain
> why
> > he thought that was a good idea.
> 
> I removed mention of the `intangible` property since AFAICT the
> corresponding code does not look at the `intangible` property (which is
> not handled "After Commands" but directly during execution of the
> various point motion Elisp functions).
> 
> In my understanding "invisible/intangible" here refers to the concepts
> rather to the specific text-properties.
> 
> How 'bout the patch below?
>
> if point is within such a sequence, the
> -command loop normally moves point to the edge of the sequence.
> +command loop normally moves point to the edge of the sequence, making
> this
> +sequence effectively intangible.

Thanks for taking a look.  I can't really tell what the
right fix is.  I was looking for info about intangible
text (knowing nothing about it and guessing, wrongly,
that it might be something I could use in a particular
use case).

I used `i', and matched against that long index entry
(using regexp or substring completion matching):
`invisible/intangible text, and point'.

If that node is really about intangible text then your
change is maybe the right fix.  If it is not really
about that (or if it shouldn't really be about it)
then the fix is perhaps to change that index entry.

I'm guessing that that index entry should anyway be
changed somehow (perhaps become multiple entries,
maybe be removed altogether - dunno).  It's a long,
weird index entry.  And without substring matching
for `i' candidates it's unlikely that someone would
be able to use that entry to find that node for info
about "intangibility" anyway.

Since you're here ;-), and since you apparently wrote
`cursor-sensor.el', perhaps you could take a look at
bug #33664 also?  Thx.