From andreas.roehler at online.de Sun Jan 17 17:03:57 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Sun, 17 Jan 2010 17:03:57 +0100 Subject: [Python-mode] [Merge] lp:~a-roehler/python-mode/python-mode.el into lp:python-mode In-Reply-To: <19280.41447.569060.613580@montanaro.dyndns.org> References: <19280.41447.569060.613580@montanaro.dyndns.org> Message-ID: <4B5334ED.5070805@online.de> Skip Montanaro wrote: > Barry> Skip, do you still want to review this or should we just approve > Barry> it and let Andreas land it? > > I say turn Andreas loose on it. I haven't looked at any python-mode code > for a couple years. > > S Hi Skip, Hi Barry, reconsidered these stuff, it's not ready for merge now. Intend coming up with a new approach. Is there a way to remove the merge-proposal? Should I delete the whole branch rather? IMO ready for merge is Michael Novikovs hide-show-support, suggest to proceed with. https://code.edge.launchpad.net/~freiksenet/python-mode/hide-show-support/+merge/12493 Thanks Andreas From barry at python.org Sun Jan 17 23:46:16 2010 From: barry at python.org (Barry Warsaw) Date: Sun, 17 Jan 2010 17:46:16 -0500 Subject: [Python-mode] [Merge] lp:~a-roehler/python-mode/python-mode.el into lp:python-mode In-Reply-To: <4B5334ED.5070805@online.de> References: <19280.41447.569060.613580@montanaro.dyndns.org> <4B5334ED.5070805@online.de> Message-ID: <40164740-832C-4051-965D-131A300D80BA@python.org> On Jan 17, 2010, at 11:03 AM, Andreas Roehler wrote: > Skip Montanaro wrote: >> Barry> Skip, do you still want to review this or should we just approve >> Barry> it and let Andreas land it? >> >> I say turn Andreas loose on it. I haven't looked at any python-mode code >> for a couple years. >> >> S > > Hi Skip, Hi Barry, > > reconsidered these stuff, it's not ready for merge now. > > Intend coming up with a new approach. > > Is there a way to remove the merge-proposal? Should I delete the whole branch rather? > > IMO ready for merge is Michael Novikovs hide-show-support, suggest to proceed with. > > https://code.edge.launchpad.net/~freiksenet/python-mode/hide-show-support/+merge/12493 Hi Andreas, I've rejected the merge proposal. You can mark your branch "Abandoned" but don't need to delete it. Feel free to proceed with Michael's patch. -Barry From andreas.roehler at online.de Mon Jan 18 14:25:53 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 18 Jan 2010 14:25:53 +0100 Subject: [Python-mode] [Merge] lp:~freiksenet/python-mode/hide-show-support into lp:python-mode In-Reply-To: References: <20100117224737.30756.35026.codereview@palladium.canonical.com> <4B541130.6020602@online.de> Message-ID: <4B546161.8050309@online.de> Barry Warsaw wrote: > On Jan 18, 2010, at 2:43 AM, Andreas Roehler wrote: > >> Barry Warsaw wrote: >>> Oops, that was the wrong branch. Andreas, please review this branch yourself and mark it approved if you want. Then merge this branch and push it. >> OK, merged locally. Got >> >> " M python-mode.el >> All changes applied successfully." >> >> Seems I have to do a commit still. >> After this: push into the trunk? > > Correct. > > Uses --fixes when you do a commit (see 'bzr help commit') and attach the bug number. Don't see a bug number here - it's just an extension. Going to commit without...(?) Andreas Then when you push, Launchpad should update all the data. > > From barry at python.org Mon Jan 18 15:05:07 2010 From: barry at python.org (Barry Warsaw) Date: Mon, 18 Jan 2010 09:05:07 -0500 Subject: [Python-mode] [Merge] lp:~freiksenet/python-mode/hide-show-support into lp:python-mode In-Reply-To: <4B546161.8050309@online.de> References: <20100117224737.30756.35026.codereview@palladium.canonical.com> <4B541130.6020602@online.de> <4B546161.8050309@online.de> Message-ID: <20100118090507.08d1930c@freewill> On Jan 18, 2010, at 02:25 PM, Andreas Roehler wrote: >Don't see a bug number here - it's just an extension. Going to commit >without...(?) Ah, then you don't need --fixes. It's generally good practice in the future to open a bug first, and link the branch to the bug. Plus you get more karma that way. :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From sesquile at gmail.com Tue Jan 19 02:27:54 2010 From: sesquile at gmail.com (m h) Date: Mon, 18 Jan 2010 18:27:54 -0700 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. Message-ID: Hey Folks- I'm using pdb (from gud.el) with emacs, which is working pretty good. I've got two gripes. * After I run pdb on a testfile, the point goes to the top of the buffer * I'd like to be able to click on files in the stacktrace (on unittest failures) and have emacs open the buffer to the correct line I figure if I can fix the later 80% of the other issues are covered. Any pointers or tips are greatly appreciated. I've searched gud.el for alist and find-file, but alas my elisp is not quite up to snuff to tell if this is actually supported. cheers, -matt From barry at python.org Tue Jan 19 15:28:34 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Jan 2010 09:28:34 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: References: Message-ID: <20100119092834.7243d840@freewill> On Jan 18, 2010, at 06:27 PM, m h wrote: >I'm using pdb (from gud.el) with emacs, which is working pretty good. >I've got two gripes. > > * After I run pdb on a testfile, the point goes to the top of the buffer > * I'd like to be able to click on files in the stacktrace (on >unittest failures) and have emacs open the buffer to the correct line > >I figure if I can fix the later 80% of the other issues are covered. >Any pointers or tips are greatly appreciated. I've searched gud.el >for alist and find-file, but alas my elisp is not quite up to snuff to >tell if this is actually supported. I'm afraid I can't help much. I generally use pdb-track instead of gud, and haven't really noticed any problems. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From sesquile at gmail.com Tue Jan 19 20:18:47 2010 From: sesquile at gmail.com (m h) Date: Tue, 19 Jan 2010 12:18:47 -0700 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20100119092834.7243d840@freewill> References: <20100119092834.7243d840@freewill> Message-ID: On Tue, Jan 19, 2010 at 7:28 AM, Barry Warsaw wrote: > On Jan 18, 2010, at 06:27 PM, m h wrote: > >>I'm using pdb (from gud.el) with emacs, which is working pretty good. >>I've got two gripes. >> >> ?* After I run pdb on a testfile, the point goes to the top of the buffer >> ?* I'd like to be able to click on files in the stacktrace (on >>unittest failures) and have emacs open the buffer to the correct line >> >>I figure if I can fix the later 80% of the other issues are covered. >>Any pointers or tips are greatly appreciated. ?I've searched gud.el >>for alist and find-file, but alas my elisp is not quite up to snuff to >>tell if this is actually supported. > > I'm afraid I can't help much. ?I generally use pdb-track instead of gud, and > haven't really noticed any problems. Wow, didn't you add python support to gud? Would you (or anyone else) care to mention their workflow? I've just been trying to get python-mode C-c C-c to allow me to use pdb. But I get an error: > (181)_test() (Pdb) Traceback (most recent call last): File "", line 186, in File "", line 181, in _test File "", line 181, in _test File "/usr/lib64/python2.6/bdb.py", line 46, in trace_dispatch return self.dispatch_line(frame) File "/usr/lib64/python2.6/bdb.py", line 65, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit How do I invoke pdbtrack from python-mode? I usually have unittests or doctests for my modules, when I've got problems I like to step through, so I insert a 'import pdb; pdb.set_trace' and run through M-x pdb. I'd be interested in what others are doing. -matt From barry at python.org Tue Jan 19 22:25:53 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Jan 2010 16:25:53 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: References: <20100119092834.7243d840@freewill> Message-ID: <20100119162553.40a3f66b@freewill> On Jan 19, 2010, at 12:18 PM, m h wrote: >Wow, didn't you add python support to gud? If I did, it was a million years ago and I don't remember it ;). >Would you (or anyone else) care to mention their workflow? I've just >been trying to get python-mode C-c C-c to allow me to use pdb. But I >get an error: > >> (181)_test() >(Pdb) >Traceback (most recent call last): > File "", line 186, in > File "", line 181, in _test > File "", line 181, in _test > File "/usr/lib64/python2.6/bdb.py", line 46, in trace_dispatch > return self.dispatch_line(frame) > File "/usr/lib64/python2.6/bdb.py", line 65, in dispatch_line > if self.quitting: raise BdbQuit >bdb.BdbQuit > >How do I invoke pdbtrack from python-mode? It's really easy. You still insert 'import pdb; pdb.set_trace()' at the spot in your code where you want to break. Then run your code from a shell buffer. When you hit the break point, you'll drop into pdb. pdb-track will notice the new prompt and you'll be able to interact with it right there. You'll use pdb commands but you'll get the nice two-screen view with code tracking. I owe Ken Manheimer a lifetime supply of [insert beverage] for this beautiful hack. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From sesquile at gmail.com Tue Jan 19 23:06:43 2010 From: sesquile at gmail.com (m h) Date: Tue, 19 Jan 2010 15:06:43 -0700 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20100119162553.40a3f66b@freewill> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> Message-ID: Thanks much for the responses! On Tue, Jan 19, 2010 at 2:25 PM, Barry Warsaw wrote: > On Jan 19, 2010, at 12:18 PM, m h wrote: > >>Wow, didn't you add python support to gud? > > If I did, it was a million years ago and I don't remember it ;). > :) >>Would you (or anyone else) care to mention their workflow? ?I've just >>been trying to get python-mode C-c C-c to allow me to use pdb. ?But I >>get an error: >> >>> (181)_test() >>(Pdb) >>Traceback (most recent call last): >> ?File "", line 186, in >> ?File "", line 181, in _test >> ?File "", line 181, in _test >> ?File "/usr/lib64/python2.6/bdb.py", line 46, in trace_dispatch >> ? ?return self.dispatch_line(frame) >> ?File "/usr/lib64/python2.6/bdb.py", line 65, in dispatch_line >> ? ?if self.quitting: raise BdbQuit >>bdb.BdbQuit >> >>How do I invoke pdbtrack from python-mode? > > It's really easy. ?You still insert 'import pdb; pdb.set_trace()' at the spot > in your code where you want to break. ?Then run your code from a shell buffer. > When you hit the break point, you'll drop into pdb. ?pdb-track will notice the > new prompt and you'll be able to interact with it right there. ?You'll use pdb > commands but you'll get the nice two-screen view with code tracking. > So just to be explicit about what 'run your code from a shell buffer'. I tried: 1- C-c ! 2- type `execfile('filename.py')` into python shell 3- hit breakpoint/nirvana Is that how you do it, or is there another way? It'd be nice not to have to type out part 2. Right now I have a macro bound to f-11 that re-runs my last pdb command. I guess M-p (like ctr-p in terminal) works ok too in that it scrolls through the command histories. So that get's rid of one of my problems (gud/pdb scrolls buffer to top). Anyway to make it recognize files and make them clickable in the python shell? cheers- -matt -matt From barry at python.org Wed Jan 20 00:36:59 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Jan 2010 18:36:59 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> Message-ID: <20100119183659.76623ff5@freewill> On Jan 19, 2010, at 03:06 PM, m h wrote: >So just to be explicit about what 'run your code from a shell buffer'. I tried: > >1- C-c ! >2- type `execfile('filename.py')` into python shell >3- hit breakpoint/nirvana Actually, no! Seriously, run it in a shell buffer. :) M-x shell RET % python filename.py hit breakpoint/nirvana :) >Is that how you do it, or is there another way? It'd be nice not to >have to type out part 2. Right now I have a macro bound to f-11 that >re-runs my last pdb command. I guess M-p (like ctr-p in terminal) >works ok too in that it scrolls through the command histories. > >So that get's rid of one of my problems (gud/pdb scrolls buffer to >top). Anyway to make it recognize files and make them clickable in >the python shell? "clickable"? Is that like using that mouse thing? To paraphrase a wise man, "There's no clicking in Emacs!" :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From sesquile at gmail.com Wed Jan 20 00:46:38 2010 From: sesquile at gmail.com (m h) Date: Tue, 19 Jan 2010 16:46:38 -0700 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20100119183659.76623ff5@freewill> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <20100119183659.76623ff5@freewill> Message-ID: (forgot to reply to list) On Tue, Jan 19, 2010 at 4:36 PM, Barry Warsaw wrote: > On Jan 19, 2010, at 03:06 PM, m h wrote: > >>So just to be explicit about what 'run your code from a shell buffer'. ?I tried: >> >>1- C-c ! >>2- type `execfile('filename.py')` into python shell >>3- hit breakpoint/nirvana > > Actually, no! ?Seriously, run it in a shell buffer. :) > > M-x shell RET > % python filename.py > hit breakpoint/nirvana > I was using M-x ansi-shell.... It worked in M-x shell. Thanks. > :) > >>Is that how you do it, or is there another way? ?It'd be nice not to >>have to type out part 2. ?Right now I have a macro bound to f-11 that >>re-runs my last pdb command. ?I guess M-p (like ctr-p in terminal) >>works ok too in ?that it scrolls through the command histories. >> >>So that get's rid of one of my problems (gud/pdb scrolls buffer to >>top). ?Anyway to make it recognize files and make them clickable in >>the python shell? > > "clickable"? ?Is that like using that mouse thing? ?To paraphrase a wise man, > "There's no clicking in Emacs!" :) > ;) Yeah, I'm trying to avoid that bad habit of 'clicking'. ok, how about 'hyperlinkable'? I've got an ack.el extension that searches for files, in it's buffer you can move the cursor over the file (with the keyboard!) and hit enter and it will pop you to that file/linum. -matt From jbauer at rubic.com Wed Jan 20 01:12:28 2010 From: jbauer at rubic.com (Jeff Bauer) Date: Tue, 19 Jan 2010 18:12:28 -0600 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20100119183659.76623ff5@freewill> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <20100119183659.76623ff5@freewill> Message-ID: <4B564A6C.9010402@rubic.com> > "clickable"? Is that like using that mouse thing? To > paraphrase a wise man, "There's no clicking in Emacs!" :) But the track ball scroll wheel is AWESOME. I've never tried running pdb from an emacs shell. Thanks for the tip! Jeff Bauer Rubicon, Inc. From sesquile at gmail.com Wed Jan 20 02:08:45 2010 From: sesquile at gmail.com (m h) Date: Tue, 19 Jan 2010 18:08:45 -0700 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20100119185853.6f4d68c8@freewill> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <20100119183659.76623ff5@freewill> <20100119185853.6f4d68c8@freewill> Message-ID: On Tue, Jan 19, 2010 at 4:58 PM, Barry Warsaw wrote: > On Jan 19, 2010, at 04:45 PM, m h wrote: > >>I was using M-x ansi-shell.... ?It worked in M-x shell. ?Thanks. > > M-x ansi-term? ?How old am I, I didn't even know about that one? :) > I got tipped off to it, and honestly can't remember why I'm using it instead of M-x shell. >>>>So that get's rid of one of my problems (gud/pdb scrolls buffer to >>>>top). ?Anyway to make it recognize files and make them clickable in >>>>the python shell? >>> >>> "clickable"? ?Is that like using that mouse thing? ?To paraphrase a wise man, >>> "There's no clicking in Emacs!" :) >>> >> >>;) ?Yeah, I'm trying to avoid that bad habit of 'clicking'. >> >>ok, how about 'hyperlinkable'? ?I've got an ack.el extension that >>searches for files, in it's buffer you can move the cursor over the >>file (with the keyboard!) and hit enter and it will pop you to that >>file/linum. > > I'm honestly unable to answer that question. ?It not something I do often > believe it or not. ?Mostly I use tags and some Bazaar hacks to find what I'm > looking for. ?Maybe someone else on the list has some ideas here? Yeah, someone sent me some ideas, I'll mess around with them, and report back if I figure something out. Thanks for the tip of pdb-track. cheers, -matt From barry at python.org Wed Jan 20 04:24:39 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Jan 2010 22:24:39 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <4B564A6C.9010402@rubic.com> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <20100119183659.76623ff5@freewill> <4B564A6C.9010402@rubic.com> Message-ID: <20100119222439.69d9e886@freewill> On Jan 19, 2010, at 06:12 PM, Jeff Bauer wrote: >> "clickable"? Is that like using that mouse thing? To >> paraphrase a wise man, "There's no clicking in Emacs!" :) > >But the track ball scroll wheel is AWESOME. Hi Jeff! Yes, I completely agree. :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From andreas.roehler at online.de Wed Jan 20 08:55:34 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Wed, 20 Jan 2010 08:55:34 +0100 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> Message-ID: <4B56B6F6.1080605@online.de> m h wrote: > Thanks much for the responses! > > On Tue, Jan 19, 2010 at 2:25 PM, Barry Warsaw wrote: >> On Jan 19, 2010, at 12:18 PM, m h wrote: >> >>> Wow, didn't you add python support to gud? >> If I did, it was a million years ago and I don't remember it ;). >> > > :) > >>> Would you (or anyone else) care to mention their workflow? I've just >>> been trying to get python-mode C-c C-c to allow me to use pdb. But I >>> get an error: >>> >>>> (181)_test() >>> (Pdb) >>> Traceback (most recent call last): >>> File "", line 186, in >>> File "", line 181, in _test >>> File "", line 181, in _test >>> File "/usr/lib64/python2.6/bdb.py", line 46, in trace_dispatch >>> return self.dispatch_line(frame) >>> File "/usr/lib64/python2.6/bdb.py", line 65, in dispatch_line >>> if self.quitting: raise BdbQuit >>> bdb.BdbQuit >>> >>> How do I invoke pdbtrack from python-mode? >> It's really easy. You still insert 'import pdb; pdb.set_trace()' at the spot >> in your code where you want to break. Then run your code from a shell buffer. >> When you hit the break point, you'll drop into pdb. pdb-track will notice the >> new prompt and you'll be able to interact with it right there. You'll use pdb >> commands but you'll get the nice two-screen view with code tracking. >> > > So just to be explicit about what 'run your code from a shell buffer'. I tried: > > 1- C-c ! > 2- type `execfile('filename.py')` into python shell > 3- hit breakpoint/nirvana > Hi, assume you called ipython with C-c !. The command then is simply run filename.py pdb works that way too Andreas From sesquile at gmail.com Sat Jan 23 07:57:18 2010 From: sesquile at gmail.com (m h) Date: Fri, 22 Jan 2010 23:57:18 -0700 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <4B56B6F6.1080605@online.de> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <4B56B6F6.1080605@online.de> Message-ID: Hey all- I got my original wish, compile-mode error navigation through the python stack trace of a unittest failure. Thanks to Gerard B for the hint. I'm doing this from pdbtrack (shell) instead of pure pdb, but it should work in both I believe. You need to enable compilation-shell-minor-mode. And have the following code in your .emacs: ;; if compilation-shell-minor-mode is on, then these regexes ;; will make errors linkable (defun matt-add-global-compilation-errors (list) (dolist (x list) (add-to-list 'compilation-error-regexp-alist (car x)) (setq compilation-error-regexp-alist-alist (cons x (assq-delete-all (car x) compilation-error-regexp-alist-alist))))) (matt-add-global-compilation-errors `( (matt-python ,(concat "^ *File \\(\"?\\)\\([^,\" \n <>]+\\)\\1" ", lines? \\([0-9]+\\)-?\\([0-9]+\\)?") 2 (3 . 4) nil 2 2) (matt-pdb-stack ,(concat "^>?[[:space:]]*\\(\\([-_./a-zA-Z0-9 ]+\\)" "(\\([0-9]+\\))\\)" "[_a-zA-Z0-9]+()[[:space:]]*->") 2 3 nil 0 1) (matt-python-unittest-err "^ File \"\\([-_./a-zA-Z0-9 ]+\\)\", line \\([0-9]+\\).*" 1 2) ) ) (defun matt-set-local-compilation-errors (errors) "Set the buffer local compilation errors. Ensures than any symbols given are defined in compilation-error-regexp-alist-alist." (dolist (e errors) (when (symbolp e) (unless (assoc e compilation-error-regexp-alist-alist) (error (concat "Error %s is not listed in " "compilation-error-regexp-alist-alist") e)))) (set (make-local-variable 'compilation-error-regexp-alist) errors)) Then you can use standard compile mode navigation to zip through the error stack trace. cheers, -matt From andreas.roehler at online.de Mon Jan 25 21:23:27 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 25 Jan 2010 21:23:27 +0100 Subject: [Python-mode] testing fixes-328781-bod-lands-in-string Message-ID: <4B5DFDBF.1030206@online.de> Hi Barry, attached a test-file, which does some move-checks on branch https://code.launchpad.net/~a-roehler/python-mode/fixes-328781-bod-lands-in-string/+merge/18030 Also it checks last merge introducing hide-show support. As tests went well, set branch for merge. BTW wrote tests with perspective of further extensions, every ...-test-forms addressing a patch: (defun ar-py-mode-tests-intern ... (ar-py-mode-mv-test-forms) (ar-py-mode-hs-test-forms) ) Comments welcome. So far Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ar-python-mode-tests.el.gz Type: application/x-gzip Size: 1803 bytes Desc: not available URL: From jbauer at rubic.com Wed Jan 27 03:17:10 2010 From: jbauer at rubic.com (Jeff Bauer) Date: Tue, 26 Jan 2010 20:17:10 -0600 Subject: [Python-mode] coding in emacs 23 Message-ID: <4B5FA226.9030403@rubic.com> After upgrading to emac23, I noticed one big difference in editing python code ... or, well editing anything. 0123456789012345678901234567890123456789 1 One-really-long-line-of-text-and-newline 2 -doesn't-appear-until-full-stop-HERE. 3 Second-line-of-code It used to be if my cursor was positioned on (0,1) and I pressed ^N, the cursor would jump down to the second line of code (0,3). Now it goes to (0,2) which is still considered (0,50). I think I preferred the older behavior for coding -- especially when I'm ThinkingInPython. Now I grab a line of code only to look up and realize I've only grabbed the first portion of the python statement. This also messes up the way I used to do some on-the-fly macros. Anyone else affected by this disconnect? -- Jeff Bauer Rubicon, Inc. From andreas.roehler at online.de Wed Jan 27 11:06:32 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Wed, 27 Jan 2010 11:06:32 +0100 Subject: [Python-mode] coding in emacs 23 In-Reply-To: <4B5FA226.9030403@rubic.com> References: <4B5FA226.9030403@rubic.com> Message-ID: <4B601028.5030402@online.de> Jeff Bauer wrote: > After upgrading to emac23, I noticed one big > difference in editing python code ... or, well > editing anything. > > 0123456789012345678901234567890123456789 > 1 One-really-long-line-of-text-and-newline > 2 -doesn't-appear-until-full-stop-HERE. > 3 Second-line-of-code > > It used to be if my cursor was positioned on > (0,1) and I pressed ^N, Hmm, probably a most basic key binding, ignore it nonetheless Could you describe this a little bit, tell the command name behind? BTW assume you are referring to python.el, not python-mode.el, right? Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ the cursor would jump > down to the second line of code (0,3). Now it > goes to (0,2) which is still considered (0,50). > > I think I preferred the older behavior for > coding -- especially when I'm ThinkingInPython. > Now I grab a line of code only to look up and > realize I've only grabbed the first portion of > the python statement. > > This also messes up the way I used to do some > on-the-fly macros. Anyone else affected by this > disconnect? > From bernhard.herzog at intevation.de Wed Jan 27 10:09:29 2010 From: bernhard.herzog at intevation.de (Bernhard Herzog) Date: Wed, 27 Jan 2010 10:09:29 +0100 Subject: [Python-mode] coding in emacs 23 In-Reply-To: <4B5FA226.9030403@rubic.com> References: <4B5FA226.9030403@rubic.com> Message-ID: <201001271009.29360.bernhard.herzog@intevation.de> On 27.01.2010, Jeff Bauer wrote: > After upgrading to emac23, I noticed one big > difference in editing python code ... or, well > editing anything. > > 0123456789012345678901234567890123456789 > 1 One-really-long-line-of-text-and-newline > 2 -doesn't-appear-until-full-stop-HERE. > 3 Second-line-of-code > > It used to be if my cursor was positioned on > (0,1) and I pressed ^N, the cursor would jump > down to the second line of code (0,3). Now it > goes to (0,2) which is still considered (0,50). That's a new default in Emacs 23 called visual line mode IIRC. You can get the old behavior back with the following setting in ~/.emacs: (setq line-move-visual nil) Bernhard -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From barry at python.org Wed Jan 27 13:16:46 2010 From: barry at python.org (Barry Warsaw) Date: Wed, 27 Jan 2010 07:16:46 -0500 Subject: [Python-mode] coding in emacs 23 In-Reply-To: <201001271009.29360.bernhard.herzog@intevation.de> References: <4B5FA226.9030403@rubic.com> <201001271009.29360.bernhard.herzog@intevation.de> Message-ID: <333C3955-FF15-4231-9E95-E15651F2C4C3@python.org> On Jan 27, 2010, at 4:09 AM, Bernhard Herzog wrote: > That's a new default in Emacs 23 called visual line mode IIRC. > You can get the old behavior back with the following setting in ~/.emacs: > > (setq line-move-visual nil) Yep, this one annoyed the crap out of me too when I upgraded, until I found out what was going on and "fixed" it. :) -Barry From jeffrubic at gmail.com Wed Jan 27 13:23:40 2010 From: jeffrubic at gmail.com (Jeff Bauer) Date: Wed, 27 Jan 2010 06:23:40 -0600 Subject: [Python-mode] coding in emacs 23 In-Reply-To: <201001271009.29360.bernhard.herzog@intevation.de> References: <4B5FA226.9030403@rubic.com> <201001271009.29360.bernhard.herzog@intevation.de> Message-ID: <4B60304C.6060907@rubic.com> On 01/27/2010 03:09 AM, Bernhard Herzog wrote: > On 27.01.2010, Jeff Bauer wrote: >> It used to be if my cursor was positioned on >> (0,1) and I pressed ^N, the cursor would jump >> down to the second line of code (0,3). Now it >> goes to (0,2) which is still considered (0,50). > > That's a new default in Emacs 23 called visual line mode IIRC. > You can get the old behavior back with the following setting in ~/.emacs: > > (setq line-move-visual nil) I see: http://www.emacswiki.org/emacs/VisualLineMode As the wiki suggests, it would make more sense to enable this for text mode and leave it disabled for editing code: (add-hook 'text-mode-hook 'turn-on-visual-line-mode) -Jeff