next-line screws up column at the EOL

next-line screws up column at the EOL

[sds]

GNU Emacs 23.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 2.8.20)
 of 2007-09-18 on nyc-qws-005
 '-with-gtk' '-with-gif=no'

recently (starting with 2007-09-18) I noticed that up/down arrows (and
C-n/C-p) screw up the current column when the point is at EOL.

Specifically put the point after "2007-09-18" above and do C-n, the
point goes to "m" in "column".
put the point at EOL (after "and") and do C-n, the point goes to the BOL
on the next line (before "C-n/C-p") instead of the EOL on the next line
(after "EOL.")
Is this an intentional change?

-- 
Sam Steingold (http://sds.podval.org/) on Fedora Core release 5 (Bordeaux)
http://truepeace.org http://iris.org.il http://thereligionofpeace.com
http://palestinefacts.org http://ffii.org http://memri.org http://pmw.org.il
If abortion is murder, then oral sex is cannibalism.

Re: next-line screws up column at the EOL

[Glenn Morris]

sds@janestcapital.com wrote:

> GNU Emacs 23.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 2.8.20)
>  of 2007-09-18 on nyc-qws-005
>  '-with-gtk' '-with-gif=no'
[...]
> Specifically put the point after "2007-09-18" above and do C-n, the
> point goes to "m" in "column".
> put the point at EOL (after "and") and do C-n, the point goes to the BOL
> on the next line (before "C-n/C-p") instead of the EOL on the next line
> (after "EOL.")

It doesn't do that for me (also on a GTK x86-64 build).

Re: next-line screws up column at the EOL

[Richard Stallman]

This doesn't fail for me, in sources from Sep 23.

Re: next-line screws up column at the EOL

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Stallman wrote:
> This doesn't fail for me, in sources from Sep 23.

indeed, "emacs -q" DTRT.
but I set track-eol to t in .emacs, and since this change:

2007-09-16  Stefan Monnier  <monnier@iro.umontreal.ca>

	* simple.el (newline): Simplify use of prefix-numeric-value.
	(line-move-partial): Remove unused var `ppos'.
	(line-move-1): Replace 9999 with most-positive-fixnum.
	(move-end-of-line): Use more efficient single-property search.
	(move-beginning-of-line): Remove unused var `start'.
	(blink-matching-open): Restructure in a more functional style.

the behavior has changed: when track-eol is nil, the behavior is what I
want (and what I always got when I set track-eol to t),
while when track-eol is t, the behavior is screwed as I described in my
original message.

Sam


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG9+bOPp1Qsf2qnMcRAs/kAKCKbeKWWfON2vKGlfhJwhkS0nvd/wCdG+Ga
2fMIlK8x/9c2PUI+069ra9Q=
=Tz+E
-----END PGP SIGNATURE-----

Re: next-line screws up column at the EOL

[Stefan Monnier]

>> This doesn't fail for me, in sources from Sep 23.

> indeed, "emacs -q" DTRT.
> but I set track-eol to t in .emacs, and since this change:

> 2007-09-16  Stefan Monnier  <monnier@iro.umontreal.ca>

> 	* simple.el (newline): Simplify use of prefix-numeric-value.
> 	(line-move-partial): Remove unused var `ppos'.
> 	(line-move-1): Replace 9999 with most-positive-fixnum.
> 	(move-end-of-line): Use more efficient single-property search.
> 	(move-beginning-of-line): Remove unused var `start'.
> 	(blink-matching-open): Restructure in a more functional style.

> the behavior has changed: when track-eol is nil, the behavior is what I
> want (and what I always got when I set track-eol to t),
> while when track-eol is t, the behavior is screwed as I described in my
> original message.

I cannot reproduce your problem.  Can you give a recipe starting from
"emacs -Q"?  My guess is that some code somewhere uses "column + 1" so the
most-positive-fixnum causes a wraparound, but I can't find the relevant code.

        Stefan

Re: next-line screws up column at the EOL

[Glenn Morris]

Stefan Monnier wrote:

> I cannot reproduce your problem. Can you give a recipe starting from
> "emacs -Q"? My guess is that some code somewhere uses "column + 1"
> so the most-positive-fixnum causes a wraparound, but I can't find
> the relevant code.

For me, in a 64-bit Emacs

(move-to-column most-positive-fixnum)

goes to column zero. In a 32-bit Emacs, it goes to the end of line.
HTH.

Re: next-line screws up column at the EOL

[Stefan Monnier]

>> I cannot reproduce your problem. Can you give a recipe starting from
>> "emacs -Q"? My guess is that some code somewhere uses "column + 1"
>> so the most-positive-fixnum causes a wraparound, but I can't find
>> the relevant code.

> For me, in a 64-bit Emacs

> (move-to-column most-positive-fixnum)

> goes to column zero. In a 32-bit Emacs, it goes to the end of line.
> HTH.

Ah, OK, thanks, that should be enough to find a fix,


        Stefan

Re: next-line screws up column at the EOL

[Stefan Monnier]

>> I cannot reproduce your problem. Can you give a recipe starting from
>> "emacs -Q"? My guess is that some code somewhere uses "column + 1"
>> so the most-positive-fixnum causes a wraparound, but I can't find
>> the relevant code.

> For me, in a 64-bit Emacs

> (move-to-column most-positive-fixnum)

Does the patch below fix the problem?


        Stefan


--- indent.c	29 aoû 2007 22:33:12 -0400	1.195
+++ indent.c	27 sep 2007 14:22:46 -0400	
@@ -932,19 +932,19 @@
      (column, force)
      Lisp_Object column, force;
 {
-  register int pos;
-  register int col = current_column ();
-  register int goal;
-  register int end;
+  register EMACS_INT pos;
+  register EMACS_INT col = current_column ();
+  register EMACS_INT goal;
+  register EMACS_INT end;
   register int tab_width = XINT (current_buffer->tab_width);
   register int ctl_arrow = !NILP (current_buffer->ctl_arrow);
   register struct Lisp_Char_Table *dp = buffer_display_table ();
   register int multibyte = !NILP (current_buffer->enable_multibyte_characters);
 
   Lisp_Object val;
-  int prev_col = 0;
+  EMACS_INT prev_col = 0;
   int c = 0;
-  int next_boundary, pos_byte;
+  EMACS_INT next_boundary, pos_byte;
 
   if (tab_width <= 0 || tab_width > 1000) tab_width = 8;
   CHECK_NATNUM (column);
@@ -970,7 +970,7 @@
     {
       while (pos == next_boundary)
 	{
-	  int prev = pos;
+	  EMACS_INT prev = pos;
 	  pos = skip_invisible (pos, &next_boundary, end, Qnil);
 	  if (pos != prev)
 	    pos_byte = CHAR_TO_BYTE (pos);
@@ -1090,7 +1090,7 @@
      and scan through it again.  */
   if (!NILP (force) && col > goal && c == '\t' && prev_col < goal)
     {
-      int goal_pt, goal_pt_byte;
+      EMACS_INT goal_pt, goal_pt_byte;
 
       /* Insert spaces in front of the tab to reach GOAL.  Do this
 	 first so that a marker at the end of the tab gets

Re: next-line screws up column at the EOL

[Glenn Morris]

Stefan Monnier wrote:

> Does the patch below fix the problem?

Works for me, though I do get a compiler warning:

indent.c: In function 'Fmove_to_column':
indent.c:974: warning: passing argument 2 of 'skip_invisible' from incompatible pointer type

Re: next-line screws up column at the EOL

[Stefan Monnier]

>> I cannot reproduce your problem. Can you give a recipe starting from
>> "emacs -Q"? My guess is that some code somewhere uses "column + 1"
>> so the most-positive-fixnum causes a wraparound, but I can't find
>> the relevant code.

> For me, in a 64-bit Emacs

> (move-to-column most-positive-fixnum)

> goes to column zero. In a 32-bit Emacs, it goes to the end of line.
> HTH.

I believe this is fixed now,


        Stefan