From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 20847@debbugs.gnu.org
Subject: bug#20847: [display engine] 25.0.50; company-mode popup makes point jump to an entirely different location
Date: Tue, 23 Jun 2015 22:07:59 +0300 [thread overview]
Message-ID: <83k2uufdkg.fsf@gnu.org> (raw)
In-Reply-To: <5589A92A.5080709@yandex.ru>
> Cc: 20847@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 23 Jun 2015 21:44:58 +0300
>
> On 06/23/2015 07:39 PM, Eli Zaretskii wrote:
>
> > Would it be possible in this specific case to start the overlay from
> > the next line, i.e. leave the newline alone? I think if you do that,
> > things ought to work without any changes.
>
> I suppose.
>
> > Since the "tooltip" pops up
> > below this line, it seems to me that the newline which begins the
> > overlay now is not needed, is it?
>
> "now"?
"Now" as in "what Company does now".
> >> The current example shows that it's better to display the cursor on the
> >> margin, rather than after the overlay. What are the examples where this
> >> is not true?
> >
> > All the others ;-)
>
> A concrete example would help.
emacs -Q
M-: (overlay-put (make-overlay 65 66) 'before-string "how\ndo\nyou\ndo?") RET
> The fact that you'd *try to* display the cursor at the newline
> belonging to an overlay display string indicates that the overlay
> must start at that position, doesn't it? Or end.
Sorry, I don't follow: what do you mean by "you'd try"?
> If it starts earlier, then the cursor might be displayed before or after
We always display it after, when point is at buffer position that has
an overlay string property.
> (if wouldn't be displayed in the middle of the overlay string, right?).
Never (unless there's a character with 'cursor' property).
> > No, I think what makes this case special is the fact that (the visible
> > part of) the overlay begins on the line below the one where the user
> > types. So from the user POV, the current line is still occupied only
> > by buffer text, and so users will expect the cursor to be displayed as
> > if there were no overlay at all.
>
> If I had to pick, I'd probably always display the cursor before such
> overlays, not after.
That goes against what Emacs did since we began supporting overlay
strings. Among other problems, it makes strange effects when
inserting characters: they appear not where the cursor is.
> That seems consistent with the logic of expecting the cursor "to be
> displayed as if...".
Again, this case is IMO singular, in that none of the overlay string
characters are visible on that line. Thus "as if...".
> > By contrast, the "usual" case with overlays that span multiple lines
> > is that the situation with positioning the cursor arises when some of
> > the overlay string is visible on the current line, and then the user
> > expectation is to see the cursor after the string. That's what the
> > code which handles this situation tries to make happen.
>
> If the overlay display string ends at that newline, and point is at the
> end of the overlay, then the display engine exception under the
> discussion will be a no-op.
What exception? Sorry, I lost track: we are discussing many different
things simultaneously.
> If it ends later, why would we even try to display the cursor at
> that newline in the first place?
Because its corresponding buffer position matches point. That's how
cursor positioning works in Emacs: it always starts by looking for the
glyph on the screen that corresponds to the buffer position where
point is. If such a glyph is not found, for one of the many reasons
(invisible text, overlay or display string, hscroll, you name it),
then the fun begins: we try very hard to find some alternative
position that fits.
> >> Even if cursor would look weird in some case, at least point is not
> >> forcibly moved to a different position.
> >
> > We are in agreement regarding the best place of showing the cursor in
> > this case. The only problem is how to do that.
>
> Removing that exception might do the trick.
It will bring other problems.
> But then, maybe I don't really understand what it does.
I can tell you which parts of code to read, if you want.
next prev parent reply other threads:[~2015-06-23 19:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 1:04 bug#20847: [display engine] 25.0.50; company-mode popup makes point jump to an entirely different location Dmitry Gutov
2015-06-19 19:07 ` Eli Zaretskii
2015-06-20 11:51 ` Eli Zaretskii
2015-06-21 13:56 ` Dmitry Gutov
2015-06-21 16:43 ` Eli Zaretskii
2015-06-21 18:06 ` Dmitry Gutov
2015-06-21 18:24 ` Eli Zaretskii
2015-06-21 19:23 ` Eli Zaretskii
2015-06-21 20:17 ` Dmitry Gutov
2015-06-21 20:02 ` Dmitry Gutov
2015-06-22 2:45 ` Eli Zaretskii
2015-06-22 11:01 ` Dmitry Gutov
2015-06-22 13:40 ` Dmitry Gutov
2015-06-22 16:26 ` Eli Zaretskii
2015-06-22 21:06 ` Dmitry Gutov
2015-06-23 16:39 ` Eli Zaretskii
2015-06-23 18:44 ` Dmitry Gutov
2015-06-23 19:07 ` Eli Zaretskii [this message]
2015-06-23 21:15 ` Dmitry Gutov
2015-06-24 16:18 ` Eli Zaretskii
2015-06-29 15:48 ` Dmitry Gutov
2015-06-30 17:46 ` Eli Zaretskii
2015-06-30 19:41 ` Dmitry Gutov
2015-06-30 20:11 ` Eli Zaretskii
2015-06-30 20:20 ` Dmitry Gutov
2015-07-01 2:42 ` Eli Zaretskii
2015-07-01 10:21 ` Dmitry Gutov
2015-07-01 15:16 ` Eli Zaretskii
2015-07-01 16:36 ` Dmitry Gutov
2015-07-01 16:40 ` Eli Zaretskii
2015-06-21 13:30 ` Dmitry Gutov
2015-06-21 14:16 ` Dmitry Gutov
2015-06-21 16:24 ` Eli Zaretskii
2015-06-21 17:46 ` Dmitry Gutov
2015-06-21 18:09 ` Eli Zaretskii
2015-06-21 20:01 ` Dmitry Gutov
2015-06-22 2:43 ` Eli Zaretskii
2015-06-22 10:57 ` Dmitry Gutov
2015-06-22 16:23 ` Eli Zaretskii
2015-06-23 0:15 ` Dmitry Gutov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83k2uufdkg.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=20847@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.