all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* next-line screws up column at the EOL
@ 2007-09-19 16:58 sds
  2007-09-20  1:47 ` Glenn Morris
  2007-09-23 15:04 ` Richard Stallman
  0 siblings, 2 replies; 10+ messages in thread
From: sds @ 2007-09-19 16:58 UTC (permalink / raw)
  To: emacs-devel

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.

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

* Re: next-line screws up column at the EOL
  2007-09-19 16:58 next-line screws up column at the EOL sds
@ 2007-09-20  1:47 ` Glenn Morris
  2007-09-23 15:04 ` Richard Stallman
  1 sibling, 0 replies; 10+ messages in thread
From: Glenn Morris @ 2007-09-20  1:47 UTC (permalink / raw)
  To: emacs-devel

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).

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

* Re: next-line screws up column at the EOL
  2007-09-19 16:58 next-line screws up column at the EOL sds
  2007-09-20  1:47 ` Glenn Morris
@ 2007-09-23 15:04 ` Richard Stallman
  2007-09-24 16:33   ` Sam Steingold
  1 sibling, 1 reply; 10+ messages in thread
From: Richard Stallman @ 2007-09-23 15:04 UTC (permalink / raw)
  To: sds; +Cc: emacs-devel

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

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

* Re: next-line screws up column at the EOL
  2007-09-23 15:04 ` Richard Stallman
@ 2007-09-24 16:33   ` Sam Steingold
  2007-09-26 20:14     ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Sam Steingold @ 2007-09-24 16:33 UTC (permalink / raw)
  To: rms; +Cc: Stefan Monnier, emacs-devel

-----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-----

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

* Re: next-line screws up column at the EOL
  2007-09-24 16:33   ` Sam Steingold
@ 2007-09-26 20:14     ` Stefan Monnier
  2007-09-26 21:26       ` Glenn Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2007-09-26 20:14 UTC (permalink / raw)
  To: Sam Steingold; +Cc: rms, emacs-devel

>> 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

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

* Re: next-line screws up column at the EOL
  2007-09-26 20:14     ` Stefan Monnier
@ 2007-09-26 21:26       ` Glenn Morris
  2007-09-27 13:11         ` Stefan Monnier
                           ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Glenn Morris @ 2007-09-26 21:26 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Sam Steingold, rms, emacs-devel

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.

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

* Re: next-line screws up column at the EOL
  2007-09-26 21:26       ` Glenn Morris
@ 2007-09-27 13:11         ` Stefan Monnier
  2007-09-27 18:25         ` Stefan Monnier
  2007-09-27 18:59         ` Stefan Monnier
  2 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2007-09-27 13:11 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Sam Steingold, rms, emacs-devel

>> 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

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

* Re: next-line screws up column at the EOL
  2007-09-26 21:26       ` Glenn Morris
  2007-09-27 13:11         ` Stefan Monnier
@ 2007-09-27 18:25         ` Stefan Monnier
  2007-09-27 18:35           ` Glenn Morris
  2007-09-27 18:59         ` Stefan Monnier
  2 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2007-09-27 18:25 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Sam Steingold, rms, emacs-devel

>> 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

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

* Re: next-line screws up column at the EOL
  2007-09-27 18:25         ` Stefan Monnier
@ 2007-09-27 18:35           ` Glenn Morris
  0 siblings, 0 replies; 10+ messages in thread
From: Glenn Morris @ 2007-09-27 18:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Sam Steingold, rms, emacs-devel

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

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

* Re: next-line screws up column at the EOL
  2007-09-26 21:26       ` Glenn Morris
  2007-09-27 13:11         ` Stefan Monnier
  2007-09-27 18:25         ` Stefan Monnier
@ 2007-09-27 18:59         ` Stefan Monnier
  2 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2007-09-27 18:59 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Sam Steingold, rms, emacs-devel

>> 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

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

end of thread, other threads:[~2007-09-27 18:59 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-19 16:58 next-line screws up column at the EOL sds
2007-09-20  1:47 ` Glenn Morris
2007-09-23 15:04 ` Richard Stallman
2007-09-24 16:33   ` Sam Steingold
2007-09-26 20:14     ` Stefan Monnier
2007-09-26 21:26       ` Glenn Morris
2007-09-27 13:11         ` Stefan Monnier
2007-09-27 18:25         ` Stefan Monnier
2007-09-27 18:35           ` Glenn Morris
2007-09-27 18:59         ` Stefan Monnier

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.