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: dmitry.kurochkin@gmail.com, emacs-devel@gnu.org
Subject: Re: `vertical-motion', `goto-line' set point to invisible text
Date: Mon, 04 Jul 2011 14:10:11 -0400	[thread overview]
Message-ID: <jwvaacu7wqg.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83y60eoz6w.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 04 Jul 2011 18:14:31 +0300")

>> >> AFAIK none of those positions are *inside* invisible text
>> > Try "M-x describe-text-properties RET", and you will see this isn't
>> > true.
>> AFAIK, describe-text-properties describes the properties of the char
>> *after* point, so if you're at the beginning of invisible text (yet not
>> inside it), describe-text-properties will show the `invisible' property.

> So how many character positions are invisible after this:
>        (insert "line1\nline2\nline3\n")
>        (goto-line 2)
>        (put-text-property (line-beginning-position)
>                           (line-beginning-position 2)
>                           'invisible 'invis1)
> ?

Without running the code, I'd say 6 ("line2\n").  Why?

> Also, since we show cursor on the character after point,

By default, yes.

> which is invisible, what exactly do we mean to achieve in this case by
> adjust_point_for_property?

The intention is just to avoid having point in the middle of invisible
text and have things like C-f and C-b appear to do nothing (because
they only move within some invisible text chunk).
Also it's so that inserting text will usually result in this text being
visible (and hopefully inserted right where the cursor was displayed).

None of those properties are guaranteed by adjust_point_for_property,
sadly, but it's the motivation behind it.

> Finally, what do you think of this:

>   (progn (switch-to-buffer "test")
> 	 (insert "aline1\nbline2\ncline3\n")
> 	 (goto-line 2)
> 	 (put-text-property (line-beginning-position)
> 			    (line-beginning-position 2)
> 			    'invisible 'invis1)
> 	 (add-to-invisibility-spec 'invis1)
> 	 (goto-char (point-max)))

> Eval this in *scratch*, then type "C-p C-x =".  You will see that
> Emacs reports that point is position 8 and the character at point is
> `b', whereas what is shown (correctly) under the cursor is `c' whose
> buffer position is 15.  Do you think this is correct behavior?

In this area, I don't think there's a clear cut definition of what is
correct and what is not.  Depending on what is being done some behavior
is preferable, and in other cases another behavior is preferable.
If point is anywhere between "bline2\n" the display will be identical,
so the fact that the cursor is drawn over the "c" that follows it does
not necessarily imply that point should be "at the end of "bline2\n",
since the cursor is also drawn right after the "aline1\n" and by that
logic point should be at the beginning of "bline2\n".

What tilts the decision one way rather than the other here is the
stickiness: for all positions other than right before "bline2\n",
self-insert-command at point will result in an invisible char being
inserted, which is very rarely the intention of the user.  Of course, in
a read-only buffer this consideration may not matter, but note that this
stickiness issue also happens to be a way by which Elisp packages can
control in which part of the invisible text point will end up.


        Stefan



  reply	other threads:[~2011-07-04 18:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-03  2:59 `vertical-motion', `goto-line' set point to invisible text Dmitry Kurochkin
2011-07-03  6:55 ` Eli Zaretskii
2011-07-03  7:31   ` Dmitry Kurochkin
2011-07-03 13:33     ` Eli Zaretskii
2011-07-04  2:08       ` Dmitry Kurochkin
2011-07-03 14:50 ` Stefan Monnier
2011-07-03 15:14   ` Eli Zaretskii
2011-07-04 14:01     ` Stefan Monnier
2011-07-04 15:14       ` Eli Zaretskii
2011-07-04 18:10         ` Stefan Monnier [this message]
2011-07-04 20:06           ` Eli Zaretskii
2011-07-04 20:06           ` Eli Zaretskii
2011-07-05  2:22           ` Dmitry Kurochkin
2011-07-05  2:55             ` Eli Zaretskii
2011-07-05  3:52             ` Dmitry Kurochkin
2011-07-05  7:56               ` Eli Zaretskii
2011-07-09 13:13                 ` Dmitry Kurochkin

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=jwvaacu7wqg.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=dmitry.kurochkin@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@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.
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.