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