all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Eli Zaretskii <eliz@gnu.org>
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 11:32:29 -0400	[thread overview]
Message-ID: <jwvzitpb4nm.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83vb4d2pkt.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 23 Mar 2016 17:15:14 +0200")

>> 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"? ;-)

No: the character after position 3 is invisible, but the position 3 is not.
Inversely, the character after position 5 is visible while the position
is not.

> 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".

No.  You just have to remember that characters are between positions and
positions are between characters, so the two can't be conflated.

> (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.

That's not my choice and that's not hard coded.  It's the choice of the
stickiness settings for that particular invisible property.  It can be
controlled by text property stickiness and overlay's marker's
insertion types.

E.g. if you use overlays to make the text invisible, then (by default)
the position's invisibility is the same as the following character's
(which is what you seem to  like).  For text-properties, by default it's
the reverse (i.e. the position's visibility is the same as the
*preceding* character).

> 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.)

AFAIK there's no relevant interaction with the display engine.
The only real problem is that people don't realize that the reality
is more complex than what they expect.

>> 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?

The secondary bug is pretty cosmetic and (at least in this case) is
rather helpful, so I'm not sure it would be an improvement in itself.

The issue of the main bug is not so much that we don't know how to fix
it, but that noone has bothered to investigate it to try and figure out
what is actually happening.


        Stefan





  reply	other threads:[~2016-03-23 15:32 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
2016-03-23 15:32                           ` Stefan Monnier [this message]
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=jwvzitpb4nm.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=19200@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=jonas@bernoul.li \
    --cc=michael_heerdegen@web.de \
    /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.