[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving point around empty overlays with 'after-text
From: |
Ash |
Subject: |
Re: Moving point around empty overlays with 'after-text |
Date: |
Mon, 10 Apr 2023 17:22:06 -0700 |
User-agent: |
Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6 |
On Sun, Apr 9, 2023, at 8:31 PM, Platon Pronko wrote:
> On 2023-04-10 11:21, Ash wrote:
> >
> >
> > 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.
>
> I like this approach. Seems to be mostly backward-compatible.
>
> --
> Best regards,
> Platon Pronko
> PGP 2A62D77A7A2CB94E
>
Thank you :) One problem I realized later is that it's unclear how this
interacts with the front-advance and rear-advance properties of a nonempty text
overlay; if you know what region of text an inlay 'describes', then you may
want to use that region as the start/end of the overlay so it can evaporate if
you delete that region. This gets especially hairy if there are *multiple*
overlays, or one that ends at the same position another starts... I think for
now I'll just use the hack I wrote in the github issue and leave this yak
mostly unshorn. Thanks for the feedback :)
- Re: Moving point around empty overlays with 'after-text, (continued)
- Re: Moving point around empty overlays with 'after-text, tomas, 2023/04/10
- Re: Moving point around empty overlays with 'after-text, Platon Pronko, 2023/04/10
- Re: Moving point around empty overlays with 'after-text, Ash, 2023/04/09
- Re: Moving point around empty overlays with 'after-text, Platon Pronko, 2023/04/09
- Re: Moving point around empty overlays with 'after-text, Ash, 2023/04/09
- Re: Moving point around empty overlays with 'after-text, Platon Pronko, 2023/04/09
- Re: Moving point around empty overlays with 'after-text,
Ash <=
- Re: Moving point around empty overlays with 'after-text, Eli Zaretskii, 2023/04/10
- Re: Moving point around empty overlays with 'after-text, Platon Pronko, 2023/04/10
- Re: Moving point around empty overlays with 'after-text, Eli Zaretskii, 2023/04/10
- Re: Moving point around empty overlays with 'after-text, Platon Pronko, 2023/04/10
- Re: Moving point around empty overlays with 'after-text, Eli Zaretskii, 2023/04/10
- Re: Moving point around empty overlays with 'after-text, Platon Pronko, 2023/04/10