all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Wed, 23 Mar 2016 17:15:14 +0200	[thread overview]
Message-ID: <83vb4d2pkt.fsf@gnu.org> (raw)
In-Reply-To: <jwvoaa6uepy.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Tue, 22 Mar 2016 22:13:04 -0400)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 19200@debbugs.gnu.org,  michael_heerdegen@web.de,  jonas@bernoul.li
> Date: Tue, 22 Mar 2016 22:13:04 -0400
> 
> >> - point adjustment doesn't bring us to position 3 after C-n
> > Why is that a problem?  Position 3 is invisible, so we shouldn't
> > expect to end up with point there.
> 
> No, you have it backwards: position 5 is invisible and position 3 is not.

So you are saying that we also have a display bug, in that what should
have been on the screen is "3" and not "5"? ;-)

> The "evidence" for that is that if you go to position 3 and insert a char,
> that char will be visible, whereas if you go to position 5 and insert
> a char, that char will be invisible.

You are talking about a different kind of "invisible", the kind that
is different from how the display engine, and any cursor-motion
commands that use its layout routines, interprets "invisible".  That
is why what you expect from the related code is hard to get: it is
barely supported by the relevant code.

(Personally, I think your notion of "invisible" is also confusing for
the user, in that it puts the cursor on a character whose position is
not the same as point.  The other notion of "invisible" also has its
disadvantages, so it's not easy to decide which one is "right", but at
least it doesn't fight an uphill battle against the display engine.)

> >> - M-: (point) has the side-effect of bringing us to position 3
> >> My guess here is that after the M-: command, at the end of
> >> command_loop_1, last_point_position refers to a position in another
> >> buffer (i.e. in the minibuffer), so it thinks there was a movement and
> >> hence re-runs adjust_point_for_property, which this time gets it right.
> > Maybe.  If this is the bug to solve, I could look into it.
> 
> No, this bug is secondary.  The main bug is that we end up at position
> 5 after C-n.

Since we don't know how to fix the main bug, would it be an
improvement to solve the secondary one?





  reply	other threads:[~2016-03-23 15:15 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
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 [this message]
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=83vb4d2pkt.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.