bug#971: 23.0.60; next-line, previous-line and goal-column

bug#971: 23.0.60; next-line, previous-line and goal-column

[martin rudalics]

 > When goal-column has a value larger than the window width, next line
 > and previous-line behave oddly. Visit file foo.txt, choose a window
 > width of, say, 40, and set goal-column to 50. If initially point is
 > at the beginning of line, next-line and previous-line put point in a
 > column smaller than goal-column. Executing next-line again puts
 > point at the end of the line past goal-column.
 >
 > Results also behave on the value of truncate-lines. The above refers
 > to truncate-lines being t. If it is nil, previous-line doesn't do
 > anything for me. (It does not move point backwards.)
 >
 > There is no such problem with emacs 22.2.

I suppose this has been fixed with Chong's recent change to
`vertical-motion'.  Can you confirm?

martin

bug#971: 23.0.60; next-line, previous-line and goal-column

[Roland Winkler]

On Thu Sep 18 2008 martin rudalics wrote:
>  > When goal-column has a value larger than the window width, next line
>  > and previous-line behave oddly. Visit file foo.txt, choose a window
>  > width of, say, 40, and set goal-column to 50. If initially point is
>  > at the beginning of line, next-line and previous-line put point in a
>  > column smaller than goal-column. Executing next-line again puts
>  > point at the end of the line past goal-column.
>  >
>  > Results also behave on the value of truncate-lines. The above refers
>  > to truncate-lines being t. If it is nil, previous-line doesn't do
>  > anything for me. (It does not move point backwards.)
>  >
>  > There is no such problem with emacs 22.2.
> 
> I suppose this has been fixed with Chong's recent change to
> `vertical-motion'.  Can you confirm?

No, the problem still persists. I just built a fresh emacs from CVS.
It still gives me the very same problems described in the original
report.

Roland

bug#971: 23.0.60; next-line, previous-line and goal-column

[Roland Winkler]

When goal-column has a value larger than the window width, next line
and previous-line behave oddly. Visit file foo.txt, choose a window
width of, say, 40, and set goal-column to 50. If initially point is
at the beginning of line, next-line and previous-line put point in a
column smaller than goal-column. Executing next-line again puts
point at the end of the line past goal-column.  

Results also behave on the value of truncate-lines. The above refers
to truncate-lines being t. If it is nil, previous-line doesn't do
anything for me. (It does not move point backwards.)

There is no such problem with emacs 22.2.

cat > foo.txt << EOF
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo bar |
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo bar
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo bar |
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo bar |
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo bar
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo bar |
| foo bar | foo bar | foo bar | foo bar | foo bar | foo bar | foo bar
EOF

In GNU Emacs 23.0.60.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.6)
 of 2008-09-07 on lukas

bug#971: 23.0.60; next-line, previous-line and goal-column

[Lars Magne Ingebrigtsen]

"Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de> writes:

> When goal-column has a value larger than the window width, next line
> and previous-line behave oddly. Visit file foo.txt, choose a window
> width of, say, 40, and set goal-column to 50. If initially point is
> at the beginning of line, next-line and previous-line put point in a
> column smaller than goal-column. Executing next-line again puts
> point at the end of the line past goal-column.  

I can verify that this bug still exists in Emacs 24.

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

bug#971: 23.0.60; next-line, previous-line and goal-column

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 11 Sep 2011 19:48:48 +0200
> Cc: 971@debbugs.gnu.org
> 
> "Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de> writes:
> 
> > When goal-column has a value larger than the window width, next line
> > and previous-line behave oddly. Visit file foo.txt, choose a window
> > width of, say, 40, and set goal-column to 50. If initially point is
> > at the beginning of line, next-line and previous-line put point in a
> > column smaller than goal-column. Executing next-line again puts
> > point at the end of the line past goal-column.  
> 
> I can verify that this bug still exists in Emacs 24.

This happens because the (now default) line-move-visual operation of
next-line is fundamentally incompatible with a non-nil setting of
goal-column, when the window with is smaller than goal-column's value.
If you reset line-move-visual to nil, the problem disappears.

line-move-visual (the function) tries to support goal-column, but in a
manner that cannot possibly work when we move by visual lines (as
opposed to logical lines) and the window is too narrow, because visual
lines simply don't have pixel coordinates that correspond to
goal-column in this case.  So it does the best it can: move to the end
of the visual line.

An easy way of solving this is dropping support for goal-column when
line-move-visual is non-nil.  If that's unacceptable, Someone™ will
have to come up with a specification for what Emacs should do in this
use case, because I cannot think of any reasonable behavior.

bug#971: 23.0.60; next-line, previous-line and goal-column

[Eli Zaretskii]

> Date: Fri, 16 Sep 2011 12:38:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 971@debbugs.gnu.org, Roland.Winkler@physik.uni-erlangen.de
> 
> An easy way of solving this is dropping support for goal-column when
> line-move-visual is non-nil.  If that's unacceptable, Someone™ will
> have to come up with a specification for what Emacs should do in this
> use case, because I cannot think of any reasonable behavior.

Actually, I can think of one reasonable behavior: if goal-column is
set to a non-nil value, ignore the value of line-move-visual and
always move by logical lines.  This will do the same as it does today
when lines are not wrapped, and do the only reasonable thing
otherwise.

Technically, this means that line-mode should call line-move-1 if
goal-column is set, even if line-move-visual is non-nil.

Thoughts?

bug#971: 23.0.60; next-line, previous-line and goal-column

[Stefan Monnier]

> An easy way of solving this is dropping support for goal-column when
> line-move-visual is non-nil.

Except of course when we truncate-lines.
That sounds about right.  Tho at the same time, line-move-visual is
a global setting whereas goal-column is typically buffer-local, so maybe
it would make more sense to ignore line-move-visual when goal-column
is set.


        Stefan

bug#971: 23.0.60; next-line, previous-line and goal-column

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>,  971@debbugs.gnu.org,  Roland.Winkler@physik.uni-erlangen.de
> Date: Fri, 16 Sep 2011 09:44:15 -0400
> 
> > An easy way of solving this is dropping support for goal-column when
> > line-move-visual is non-nil.
> 
> Except of course when we truncate-lines.
> That sounds about right.  Tho at the same time, line-move-visual is
> a global setting whereas goal-column is typically buffer-local, so maybe
> it would make more sense to ignore line-move-visual when goal-column
> is set.

I've committed a change (revision 105795 on the trunk) that ignores
line-move-visual's value when goal-column is non-nil.

I'm therefore closing this bug.