Ihor Radchenko <[email protected]> writes: > "J.D. Smith" <[email protected]> writes: >> Is that because point moves to the position it would have occupied if >> there were no `*' at all? Maybe you prefer the movement to "stay >> adjacent" to the formerly hidden-marker text. > > Not really. > Let me explain better, using my observations with your latest code. > When I have > <point>*FOO*, the cursor is a block cursor on top of "F", which is not > right.
IMO it *is* correct, since the (default) block cursor indicates "outside of the hidden-marker-wrapped text". At that <point>, edits will happen "outside", so 'block is correct. > When I move C-f *<point>FOO*, the cursor is a *|FOO*. > I think a more intuitive approach would be > > <point>*FOO* -> |FOO > *<point>FOO* -> [F]OO I'm afraid I don't understand how this would be more intuitive. The "inside" cursor type is the bar. The outside cursor type is box. Expanding on your scenario, my current code does this: OUT<point>SIDE *FOO* -> OUT[S]IDE FOO ; definitely in outside text: default box cursor OUTSIDE <point>*FOO* -> OUTSIDE [F]OO ; adjacent to, but still outside: box OUTSIDE *<point>FOO* -> OUTSIDE |FOO ; inside (just): bar OUTSIDE *FO<point>O* -> OUTSIDE FO|O ; definitely inside: bar OUTSIDE *FOO<point>* -> OUTSIDE FOO| ; still inside! OUTSIDE *FOO*<point> -> OUTSIDE FOO[ ] ; now outside again: box So maybe what you prefer is for your default (outside) cursor to be 'bar and your "inside" cursor to be 'box? That should definitely be possible. > Aside: note that some users customize the default cursor shape. True. We could store the type at mode start. >> If you comment out the overlay moves, you'll see that this type of >> motion is more awkward with cursor-only changes, as point seems "not to >> make progress" as you move out from the hidden text. Some people might >> prefer that behavior, so it could be an option. Or could just: >> >> - Unhiding markers? Moving out keeps point adjacent. >> - Just changing cursor? Moving out continues naturally. > > As I said, unhiding markers could be an option - many users quite like > what org-appear does. But your approach alone is also viable. Yes, definitely both approaches should be an option. In terms of hiding/unhiding, does org-appear do anything differently that you know? I have only ever tried it out briefly. Here I'm talking about the behavior of moving point from inside to outside. Since in the "unhidden markers" view, you have a something to move across (the marker which is about to disappear) it makes sense to set `disable-point-adjustment' (which is always temporary). We can play with that later. >> Please try the below demo command `my/try-inside'. This version fixes >> both issues you noticed, and handles edits at the boundary better >> (though in real org, font-lock would supersede this). > > What I do > > Some<point> FOO or another > Some FOO or another > > C-f C-f C-f > Some F[O]O or another (block cursor) That definitely isn't intended. With this I get the expected: Some *F|OO* or another from emacs -Q. Can you try from that? It should never be a block inside. Do you customize your cursor (which shouldn't matter)? > C-n > > Some FOO or another > Some *F|OO* or another This is correct. > The above is inconsistent. I agree. If you could add some message logging to the cursor-sensor-function, perhaps you can see if it's not firing that first time for some reason? I find them to be very reliable, never seen a misfire.
