Re: Moving point around empty overlays with 'after-text

[Ash]

On Sun, Apr 9, 2023, at 7:00 PM, Platon Pronko wrote:
> On 2023-04-10 04:44, Ash wrote:
> > Yeah, I think doing this "right" might require adding a new property to 
> > overlays/strings (or giving an existing property a new value) to enable 
> > this behavior and modifying C code. Not sure how viable that is or if it's 
> > something the devs would want.
> 
> I think it's even worse than adding a property to the overlay. You need 
> common point manipulation functions to account for possibility of inlays, 
> i.e. (point) for position before and after inlay will be returning different 
> values, (forward-char) will correctly advance the point from the left side to 
> the right side of the inlay, etc.
> 
> (on second thought, making (point) return different values for positions 
> around overlays sounds horrifying, because this will break about half of all 
> Elisp code written)
> 
> But inlay hints seem to be a common functionality for any modern IDE nowdays, 
> so it might make sense to support them natively, without making major-mode 
> developers resort to horrible hacks like described before.
> 
> -- 
> Best regards,
> Platon Pronko
> PGP 2A62D77A7A2CB94E
> 

You could make it so only these special overlays (I'm going to call them 
inlay-type overlays or just inlays) have weird behavior with (point), but 
that'd still make things very complicated and I wouldn't do it. A sketch for 
what I would do is something like this:

When point is on a position with an inlay, the new variable 
point-is-after-inlay (name subject to bikeshedding) controls where point 
renders (before if nil, after if t). When inserting text, the inlay moves 
forward if point-is-after-inlay is nil, and doesn't move if it's t; this means 
characters appear where you'd expect.

We add a new (forward-char-respecting-inlay) function that sets 
point-is-after-inlay to t if point is at the start of an inlay *and* 
point-is-after-inlay is nil, or increments point if not (and the same for 
backwards). Possibly add an 'always-respect-inlay' mode that makes forward-char 
act like this, with the caveat that things might break in strange ways.

Each inlay has a 'bias' of 'before or 'after that indicates what 
point-is-before-inlay should be set to when navigating to it 'from afar' or 
other cases where there's no good heuristic for where to put it; in general, 
this should correspond to where the text is the inlay is semantically 
annotating.

There's probably all kinds of edge cases I haven't thought about, of course. 
Conversely, an even more general approach that would support multiple inlays in 
a row would be to have point-is-after-inlay be an *index* (and rename it 
'point-inlay-index' or some such). Not sure what a concrete use case for that 
would be.