Re: `vertical-motion', `goto-line' set point to invisible text

[Dmitry Kurochkin <dmitry.kurochkin@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