From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: `vertical-motion', `goto-line' set point to invisible text
Date: Tue, 05 Jul 2011 07:52:09 +0400 [thread overview]
Message-ID: <87pqlp5qqe.fsf@gmail.com> (raw)
In-Reply-To: <87sjql5uv3.fsf@gmail.com>
On Tue, 05 Jul 2011 06:22:56 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> On Mon, 04 Jul 2011 14:10:11 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > >> >> 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.
> >
>
> That makes sense. Thank you.
>
> Perhaps in case of notmuch the best way is to hide the preceding newline
> character instead of the trailing one. This way there will always be a
> visible newline between different messages and cursor-moving functions
> (e.g. `vertical-motion') should not move beyond it.
>
While trying this, I found another issue with how emacs adjusts the
point when it is idle. We have 3 lines and the second one is hidden.
But now we hide the newline on line1 instead of line2:
(progn (switch-to-buffer "test")
(insert "aline1\nbline2\ncline3\n")
(put-text-property 7 14 'invisible t)
(goto-char (point-min)))
Now if you run M-: (progn (end-of-visual-line) (point)), it moves to
point 14, which is end of line 2 as expected. But then emacs adjusts
the point and moves it to beginning of line3, C-x = says point is 15.
Also, global-hl-line-mode does not work correctly for line1. Just go to
the start of buffer and move forward to see some weird behavior.
Regards,
Dmitry
> Still looking for an answer to the following question earlier in this
> thread:
>
> I am looking for a function that does something like what you described
> below. I.e. moves point to the next suitable character in the given
> direction. At the moment I do it with smth like:
>
> ;; if point is invisible, skip forward to visible text
> (while (invisible-p p)
> (setq p (next-single-char-property-change p 'invisible)))
>
> Regards,
> Dmitry
>
> >
> > Stefan
next prev parent reply other threads:[~2011-07-05 3:52 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
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 [this message]
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=87pqlp5qqe.fsf@gmail.com \
--to=dmitry.kurochkin@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--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.