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.