unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#9034: point adjustment after `end-of-visual-line' moves to the next line
@ 2011-07-09 13:04 Dmitry Kurochkin
  2011-07-11  4:16 ` Stefan Monnier
  2021-08-25 16:32 ` bug#9034: point adjustment (with invisible text) " Lars Ingebrigtsen
  0 siblings, 2 replies; 11+ messages in thread
From: Dmitry Kurochkin @ 2011-07-09 13:04 UTC (permalink / raw)
  To: 9034

Package: emacs
Version: 24.0.50

If a line ends with invisible text, point adjustment moves to the next
line after `end-of-visual-line'.  To reproduce run:

  (progn (switch-to-buffer "test")
         (insert "aline1\nbline2\ncline3\n")
         (put-text-property 7 14 'invisible t) ; region [\nbline2]
         (goto-char (point-min)))

After that in the test buffer do M-: (progn (end-of-visual-line)
(point)).  `end-of-visual-line' moves point to position 14 as expected.
But after that the point is adjusted to position 15, as can be checked
by C-x =.

Sometimes the point is not adjusted to position 15 the first time you
run `end-of-visual-line'.  But it is if you run it more than once.
Perhaps it is related to the last point position.

It is definitely happens because of point adjustment, setting
global-disable-point-adjustment to non-nil fixes the problem.

Also, `move-end-of-line` always behaves correctly, so it it something
specific to `end-of-visual-line' or `vertical-motion'.

The issue was originally reported on the emacs-devel ML [1].

Regards,
  Dmitry

[1] http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00255.html





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment after `end-of-visual-line' moves to the next line
  2011-07-09 13:04 bug#9034: point adjustment after `end-of-visual-line' moves to the next line Dmitry Kurochkin
@ 2011-07-11  4:16 ` Stefan Monnier
  2011-07-11  8:27   ` Dmitry Kurochkin
  2021-08-25 16:32 ` bug#9034: point adjustment (with invisible text) " Lars Ingebrigtsen
  1 sibling, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2011-07-11  4:16 UTC (permalink / raw)
  To: Dmitry Kurochkin; +Cc: 9034

> If a line ends with invisible text, point adjustment moves to the next
> line after `end-of-visual-line'.  To reproduce run:

>   (progn (switch-to-buffer "test")
>          (insert "aline1\nbline2\ncline3\n")
>          (put-text-property 7 14 'invisible t) ; region [\nbline2]
>          (goto-char (point-min)))

> After that in the test buffer do M-: (progn (end-of-visual-line)
> (point)).  `end-of-visual-line' moves point to position 14 as expected.
> But after that the point is adjusted to position 15, as can be checked
> by C-x =.

> Sometimes the point is not adjusted to position 15 the first time you
> run `end-of-visual-line'.  But it is if you run it more than once.
> Perhaps it is related to the last point position.

I can reproduce it with M-: (progn (goto-char 14) > (point))

> Also, `move-end-of-line` always behaves correctly, so it it something
> specific to `end-of-visual-line' or `vertical-motion'.

Apparently not since I can reproduce the problem with just goto-char.
Maybe it has to do with the use of M-: instead.


        Stefan





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment after `end-of-visual-line' moves to the next line
  2011-07-11  4:16 ` Stefan Monnier
@ 2011-07-11  8:27   ` Dmitry Kurochkin
  0 siblings, 0 replies; 11+ messages in thread
From: Dmitry Kurochkin @ 2011-07-11  8:27 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 9034

On Mon, 11 Jul 2011 00:16:31 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > If a line ends with invisible text, point adjustment moves to the next
> > line after `end-of-visual-line'.  To reproduce run:
> 
> >   (progn (switch-to-buffer "test")
> >          (insert "aline1\nbline2\ncline3\n")
> >          (put-text-property 7 14 'invisible t) ; region [\nbline2]
> >          (goto-char (point-min)))
> 
> > After that in the test buffer do M-: (progn (end-of-visual-line)
> > (point)).  `end-of-visual-line' moves point to position 14 as expected.
> > But after that the point is adjusted to position 15, as can be checked
> > by C-x =.
> 
> > Sometimes the point is not adjusted to position 15 the first time you
> > run `end-of-visual-line'.  But it is if you run it more than once.
> > Perhaps it is related to the last point position.
> 
> I can reproduce it with M-: (progn (goto-char 14) > (point))
> 

indeed

> > Also, `move-end-of-line` always behaves correctly, so it it something
> > specific to `end-of-visual-line' or `vertical-motion'.
> 
> Apparently not since I can reproduce the problem with just goto-char.

If visual-line-mode is enabled (so that C-e is mapped to
`end-of-visual-line' instead of `move-end-of-line'),
`end-of-visual-line' works correctly when run with C-e.

> Maybe it has to do with the use of M-: instead.
> 

Seems plausible.

Regards,
  Dmitry

> 
>         Stefan





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2011-07-09 13:04 bug#9034: point adjustment after `end-of-visual-line' moves to the next line Dmitry Kurochkin
  2011-07-11  4:16 ` Stefan Monnier
@ 2021-08-25 16:32 ` Lars Ingebrigtsen
  2021-08-25 16:43   ` Eli Zaretskii
  1 sibling, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-25 16:32 UTC (permalink / raw)
  To: Dmitry Kurochkin; +Cc: 9034

Dmitry Kurochkin <dmitry.kurochkin@gmail.com> writes:

>   (progn (switch-to-buffer "test")
>          (insert "aline1\nbline2\ncline3\n")
>          (put-text-property 7 14 'invisible t) ; region [\nbline2]
>          (goto-char (point-min)))
>
> After that in the test buffer do M-: (progn (end-of-visual-line)
> (point)).  `end-of-visual-line' moves point to position 14 as expected.
> But after that the point is adjusted to position 15, as can be checked
> by C-x =.

(I'm going through old bug reports that unfortunately got weren't
resolved at the time.)

This problem is still present in Emacs 28, and as previously noted, any
command you do (with `M-:') makes point advance to the next line.  (It's
not 100% reproducible -- sometimes nothing happens, and sometimes it
advances.)

So `C-e' and then, for instance `M-: 4 RET' will advance point here.

Also as previously noted, if Vglobal_disable_point_adjustment is on,
then this doesn't happen, so the problem almost has to be here:

command_loop_1
...
      if (current_buffer == prev_buffer
	  && XBUFFER (XWINDOW (selected_window)->contents) == current_buffer
	  && last_point_position != PT
	  && NILP (Vdisable_point_adjustment)
	  && NILP (Vglobal_disable_point_adjustment))
	{
	  if (last_point_position > BEGV
	      && last_point_position < ZV
	      && (composition_adjust_point (last_point_position,
					    last_point_position)
		  != last_point_position))
	    /* The last point was temporarily set within a grapheme
	       cluster to prevent automatic composition.  To recover
	       the automatic composition, we must update the
	       display.  */
	    windows_or_buffers_changed = 21;
	  if (!already_adjusted)
	    adjust_point_for_property (last_point_position,
				       MODIFF != prev_modiff);
	}

I haven't tried to debug any further -- is it obvious to anybody what's
failing here, by any chance?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2021-08-25 16:32 ` bug#9034: point adjustment (with invisible text) " Lars Ingebrigtsen
@ 2021-08-25 16:43   ` Eli Zaretskii
  2021-08-26 13:48     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2021-08-25 16:43 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: dmitry.kurochkin, 9034

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 25 Aug 2021 18:32:15 +0200
> Cc: 9034@debbugs.gnu.org
> 
> Also as previously noted, if Vglobal_disable_point_adjustment is on,
> then this doesn't happen, so the problem almost has to be here:
> 
> command_loop_1
> ...
>       if (current_buffer == prev_buffer
> 	  && XBUFFER (XWINDOW (selected_window)->contents) == current_buffer
> 	  && last_point_position != PT
> 	  && NILP (Vdisable_point_adjustment)
> 	  && NILP (Vglobal_disable_point_adjustment))
> 	{
> 	  if (last_point_position > BEGV
> 	      && last_point_position < ZV
> 	      && (composition_adjust_point (last_point_position,
> 					    last_point_position)
> 		  != last_point_position))
> 	    /* The last point was temporarily set within a grapheme
> 	       cluster to prevent automatic composition.  To recover
> 	       the automatic composition, we must update the
> 	       display.  */
> 	    windows_or_buffers_changed = 21;
> 	  if (!already_adjusted)
> 	    adjust_point_for_property (last_point_position,
> 				       MODIFF != prev_modiff);
> 	}
> 
> I haven't tried to debug any further -- is it obvious to anybody what's
> failing here, by any chance?  :-)

This code is chock-full of questionable heuristics, and in particular
tries to guess in which direction to move point out of the invisible
text.  The results are sometimes surprising.  The upside is that it
"mostly works".  But if someone can come up with a better heuristics,
I'm all ears.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2021-08-25 16:43   ` Eli Zaretskii
@ 2021-08-26 13:48     ` Lars Ingebrigtsen
  2021-08-26 15:46       ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-26 13:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dmitry.kurochkin, 9034

Eli Zaretskii <eliz@gnu.org> writes:

> This code is chock-full of questionable heuristics, and in particular
> tries to guess in which direction to move point out of the invisible
> text.  The results are sometimes surprising.  The upside is that it
> "mostly works".  But if someone can come up with a better heuristics,
> I'm all ears.

Ah, right.  But...  the super-confusing thing about this is that we're
not moving point in the buffer at all.  Just doing `M-: 4 RET' will
result in this code adjusting point in the buffer.  Doing, for instance,
`M-x foo RET' (where `foo' does nothing) does not result in this point
movement.

So is `M-:' doing some weird thing in the original buffer to trigger
this oddity?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2021-08-26 13:48     ` Lars Ingebrigtsen
@ 2021-08-26 15:46       ` Eli Zaretskii
  2021-08-26 16:33         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2021-08-26 15:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: dmitry.kurochkin, 9034

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dmitry.kurochkin@gmail.com,  9034@debbugs.gnu.org
> Date: Thu, 26 Aug 2021 15:48:32 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This code is chock-full of questionable heuristics, and in particular
> > tries to guess in which direction to move point out of the invisible
> > text.  The results are sometimes surprising.  The upside is that it
> > "mostly works".  But if someone can come up with a better heuristics,
> > I'm all ears.
> 
> Ah, right.  But...  the super-confusing thing about this is that we're
> not moving point in the buffer at all.

The original recipe moved from point-min to an end of a line.

> Just doing `M-: 4 RET' will result in this code adjusting point in
> the buffer.  Doing, for instance, `M-x foo RET' (where `foo' does
> nothing) does not result in this point movement.
> 
> So is `M-:' doing some weird thing in the original buffer to trigger
> this oddity?

Doing M-: in what part of the recipe?





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2021-08-26 15:46       ` Eli Zaretskii
@ 2021-08-26 16:33         ` Lars Ingebrigtsen
  2021-08-26 16:48           ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-26 16:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dmitry.kurochkin, 9034

Eli Zaretskii <eliz@gnu.org> writes:

>> Just doing `M-: 4 RET' will result in this code adjusting point in
>> the buffer.  Doing, for instance, `M-x foo RET' (where `foo' does
>> nothing) does not result in this point movement.
>> 
>> So is `M-:' doing some weird thing in the original buffer to trigger
>> this oddity?
>
> Doing M-: in what part of the recipe?

Eval this:

  (progn (switch-to-buffer "test")
         (insert "aline1\nbline2\ncline3\n")
         (put-text-property 7 14 'invisible t) ; region [\nbline2]
         (goto-char (point-min)))

Then

C-e
M-: 4 RET

This will move point to the start of the next line about half the time.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2021-08-26 16:33         ` Lars Ingebrigtsen
@ 2021-08-26 16:48           ` Eli Zaretskii
  2021-08-26 17:05             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2021-08-26 16:48 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: dmitry.kurochkin, 9034

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dmitry.kurochkin@gmail.com,  9034@debbugs.gnu.org
> Date: Thu, 26 Aug 2021 18:33:29 +0200
> 
> Eval this:
> 
>   (progn (switch-to-buffer "test")
>          (insert "aline1\nbline2\ncline3\n")
>          (put-text-property 7 14 'invisible t) ; region [\nbline2]
>          (goto-char (point-min)))
> 
> Then
> 
> C-e
> M-: 4 RET
> 
> This will move point to the start of the next line about half the time.

I cannot reproduce this: no matter how many times I do the "C-e M-:"
dance, point stays put.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2021-08-26 16:48           ` Eli Zaretskii
@ 2021-08-26 17:05             ` Lars Ingebrigtsen
  2021-08-26 17:13               ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-26 17:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dmitry.kurochkin, 9034

Eli Zaretskii <eliz@gnu.org> writes:

> I cannot reproduce this: no matter how many times I do the "C-e M-:"
> dance, point stays put.

Does it help if you only do the `C-e' once?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9034: point adjustment (with invisible text) moves to the next line
  2021-08-26 17:05             ` Lars Ingebrigtsen
@ 2021-08-26 17:13               ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2021-08-26 17:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: dmitry.kurochkin, 9034

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dmitry.kurochkin@gmail.com,  9034@debbugs.gnu.org
> Date: Thu, 26 Aug 2021 19:05:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I cannot reproduce this: no matter how many times I do the "C-e M-:"
> > dance, point stays put.
> 
> Does it help if you only do the `C-e' once?

I tried that as well, to no avail.

I think a more efficient way of understanding what's going on with M-:
is to step through the code in keyboard.c with a debugger.





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-08-26 17:13 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-09 13:04 bug#9034: point adjustment after `end-of-visual-line' moves to the next line Dmitry Kurochkin
2011-07-11  4:16 ` Stefan Monnier
2011-07-11  8:27   ` Dmitry Kurochkin
2021-08-25 16:32 ` bug#9034: point adjustment (with invisible text) " Lars Ingebrigtsen
2021-08-25 16:43   ` Eli Zaretskii
2021-08-26 13:48     ` Lars Ingebrigtsen
2021-08-26 15:46       ` Eli Zaretskii
2021-08-26 16:33         ` Lars Ingebrigtsen
2021-08-26 16:48           ` Eli Zaretskii
2021-08-26 17:05             ` Lars Ingebrigtsen
2021-08-26 17:13               ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).