unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Moving point around empty overlays with 'after-text
Date: Sat, 08 Apr 2023 13:06:04 +0300	[thread overview]
Message-ID: <83wn2mn0xf.fsf@gnu.org> (raw)
In-Reply-To: <9b1654ec-1ac6-4936-860b-2d77dcc4dac7@app.fastmail.com> (message from Ash on Fri, 07 Apr 2023 22:46:19 -0700)

> Date: Fri, 07 Apr 2023 22:46:19 -0700
> From: Ash <ext0l@catgirl.ai>
> 
> https://github.com/emacs-lsp/lsp-mode/issues/3263 is a bug in lsp-mode (emacs's
> own eglot has the same bug as far as I can tell) that appears to boil down to
> the behavior of emacs overlays and after-string. That is, if your buffer looks
> like
> 
> let my_value{: Vec<i32>} = vec![0, 1, 2];
> 
> (where the curly braces indicate the after-string property of an
> overlay), you need to put your cursor *after* the overlay to
> insert text at the end of the variable name, which comes *before*
> it, and it's impossible to put your cursor immediately between
> the overlay and the preceding text. I assume the behavior the
> user desires is that you can put your cursor either immediately
> before or immediately after the overlay and insert text, and that
> pressing the left/right arrow would move you over the overlay but
> leave the actual position of point unchahnged.
> 
> My suspicion is that this isn't fixable just by setting the right text/overlay
> properties, since both the cursor locations immediately before and after the
> overlay actually correspond to the same location in the underlying string. But
> I'm not good at text property arcana. Any advice?

Did you try to use on the overlay string the 'cursor' text property
whose value is zero?



  reply	other threads:[~2023-04-08 10:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-08  5:46 Moving point around empty overlays with 'after-text Ash
2023-04-08 10:06 ` Eli Zaretskii [this message]
2023-04-08 10:14   ` Platon Pronko
2023-04-08 10:10 ` Platon Pronko
2023-04-08 23:06   ` Ash
2023-04-09 12:15     ` Platon Pronko
2023-04-09 14:49       ` tomas
2023-04-10  1:52         ` Platon Pronko
2023-04-10  4:56           ` Eli Zaretskii
2023-04-10  5:22             ` Platon Pronko
2023-04-10  9:56               ` Yuri Khan
2023-04-11  8:49                 ` Platon Pronko
2023-04-11  9:41                   ` Yuri Khan
2023-04-10  5:35           ` tomas
2023-04-10  5:48             ` Platon Pronko
2023-04-09 20:44       ` Ash
2023-04-10  2:00         ` Platon Pronko
2023-04-10  3:21           ` Ash
2023-04-10  3:31             ` Platon Pronko
2023-04-11  0:22               ` Ash
2023-04-10  5:09             ` Eli Zaretskii
2023-04-10  5:37               ` Platon Pronko
2023-04-10  8:03                 ` Eli Zaretskii
2023-04-10  9:05                   ` Platon Pronko
2023-04-10  5:01           ` Eli Zaretskii
2023-04-10  5:26             ` Platon Pronko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wn2mn0xf.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).