From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: michael_heerdegen@web.de, jonas@bernoul.li, 19200@debbugs.gnu.org
Subject: bug#19200: Point adjustemnt moves *into* invisible text
Date: Mon, 21 Mar 2016 20:28:05 +0200 [thread overview]
Message-ID: <83h9fz65ze.fsf@gnu.org> (raw)
In-Reply-To: <jwvmvprvocz.fsf-monnier+Inbox@gnu.org> (message from Stefan Monnier on Mon, 21 Mar 2016 11:36:23 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 21 Mar 2016 11:36:23 -0400
> Cc: 19200@debbugs.gnu.org, Jonas Bernoulli <jonas@bernoul.li>
>
> >> The way point-adjustment is defined is too conservative for that.
> >> So I suggest you try and make you code more robust w.r.t the position of
> >> point within an invisible region in any case.
> > Well, we just want that cursor movement starting from a visible position
> > not end up at an invisible position - the docs seem to suggest that this
> > should not happen, right?
>
> It doesn't guarantee it in all cases, no. E.g. it won't work if the
> command that moves point started/ended in another buffer, or if the
> command set disable-point-adjustment, plus a few other cases.
>
> > We have the following, very simple situation:
>
> > Line N
> > { M invisible lines here }
> > Line N+M+1
>
> > Line N and Line N+M+1 are completely visible, and displayed after each
> > other. Point is at the start of Line N, no invisible text near that
> > position. Now I hit [down] one time and end up somewhere inside the
> > invisible text in between.
>
> I agree it's a bug. I'm just pointing out that even if we fix this bug,
> there will be other cases which ae not considered bugs where point will
> end up in the middle of the invisible text, and where it would be odd
> for your code to then operate on the selection at the "current line"
> since that's not the line that the user is actually seeing.
>
> So, yes, point-adjustment needs to be fixed (this is bug#19200), but
> Magit also needs to be fixed anyway (and after that fix, it won't care
> about bug#19200 nearly as much, I think).
Can someone tell me why you think point adjustment has anything to do
with the original report for this bug? Because I fail to see any
connection; maybe I'm missing something.
What I see is that vertical-motion, called by next-line's subroutines,
ends up at position 5, because when it tries to get to column zero, it
skips the invisible text between positions 3 and 5. It stops at 5
because the function called to move to the goal column can only move
within a single display line. IOW, this is a simple artifact of the
implementation of vertical-motion.
Michael, does the patch below fix the Magit problem? (It does fix the
simple test case presented by Stefan at the beginning of this bug
report.)
diff --git a/src/indent.c b/src/indent.c
index d5162e3..e10b084 100644
--- a/src/indent.c
+++ b/src/indent.c
@@ -2222,7 +2222,8 @@ whether or not it is currently displayed in some window. */)
an addition to the hscroll amount. */
if (lcols_given)
{
- move_it_in_display_line (&it, ZV, first_x + to_x, MOVE_TO_X);
+ if (it.current_x < first_x + to_x)
+ move_it_in_display_line (&it, ZV, first_x + to_x, MOVE_TO_X);
/* If we find ourselves in the middle of an overlay string
which includes a newline after current string position,
we need to move by lines until we get out of the string,
next prev parent reply other threads:[~2016-03-21 18:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 22:22 bug#19200: Point adjustemnt moves *into* invisible text Stefan Monnier
2016-03-20 22:58 ` Michael Heerdegen
2016-03-21 1:21 ` Stefan Monnier
2016-03-21 2:15 ` Michael Heerdegen
2016-03-21 2:23 ` Michael Heerdegen
2016-03-21 18:30 ` Eli Zaretskii
2016-03-21 12:08 ` Stefan Monnier
2016-03-21 14:52 ` Michael Heerdegen
2016-03-21 15:36 ` Stefan Monnier
2016-03-21 15:54 ` Michael Heerdegen
2016-03-21 18:08 ` Stefan Monnier
2016-03-21 18:28 ` Eli Zaretskii [this message]
2016-03-21 19:24 ` Michael Heerdegen
2016-03-21 19:40 ` Eli Zaretskii
2016-03-21 20:10 ` Michael Heerdegen
2016-03-21 20:21 ` Michael Heerdegen
2016-03-21 20:43 ` Stefan Monnier
2016-03-22 16:39 ` Eli Zaretskii
2016-03-22 18:36 ` Stefan Monnier
2016-03-22 18:52 ` Eli Zaretskii
2016-03-23 2:13 ` Stefan Monnier
2016-03-23 15:15 ` Eli Zaretskii
2016-03-23 15:32 ` Stefan Monnier
2016-03-23 15:42 ` Eli Zaretskii
2016-03-23 16:10 ` Stefan Monnier
2016-03-31 17:17 ` Eli Zaretskii
2016-03-31 18:04 ` Stefan Monnier
2016-03-31 23:32 ` Michael Heerdegen
2016-03-26 21:49 ` bug#19200: Point adjustment " John Wiegley
2016-03-21 18:31 ` bug#19200: Point adjustemnt " Eli Zaretskii
2016-03-21 18:50 ` Michael Heerdegen
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=83h9fz65ze.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=19200@debbugs.gnu.org \
--cc=jonas@bernoul.li \
--cc=michael_heerdegen@web.de \
--cc=monnier@iro.umontreal.ca \
/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.