From andreas.roehler at online.de Wed Oct 6 22:34:05 2010 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Wed, 06 Oct 2010 22:34:05 +0200 Subject: [Python-mode] python-mode-reassembled.el Message-ID: <4CACDD3D.3010008@online.de> Hi Barry, hi folks, after some re-design done in https://code.launchpad.net/~a-roehler/python-mode/python-mode-components, re-arranged the changed code alongside with the unchanged into a single file again for your convenience: ~a-roehler/python-mode/python-mode-components : /python-mode-reassembled.el Most bugs reported last year should be gone. Maybe have a look at functions below ";; Block" which implement some new behaviour or are newly introduced. Also `ar-py-indent-line-forward' might be of some interest. Hopefully I'll write some explanations next weeks. Comments welcome Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.roehler at online.de Thu Oct 7 13:33:51 2010 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Thu, 07 Oct 2010 13:33:51 +0200 Subject: [Python-mode] [Bug 652005] Re: py-beginning-of-block feature request In-Reply-To: <20101006114053.27166.48155.malone@soybean.canonical.com> References: <20100930122721.24755.33328.malonedeb@soybean.canonical.com> <20101006114053.27166.48155.malone@soybean.canonical.com> Message-ID: <4CADB01F.3010900@online.de> Am 06.10.2010 13:40, schrieb Barry Warsaw: > Hi Andreas, I think it's fine if you discuss this on python-mode@ > > Changes in https://code.launchpad.net/~a-roehler/python-mode/python-mode-components Hi Barry, hi folks as rewrite of python-mode.el is conceived part of a larger project started at https://code.launchpad.net/s-x-emacs-werkstatt/ didn't change a single function but a bunch of them acccording to the rules applied. These rules might be and should be discussed, didn't find the right place for discussion so far. Lanchpads Blueprint seems rather fine-grained, not suitable for general reflections. Nonetheless I'd happy seeing python-mode Blueprint activated, as its fine for simple feature requests. Just the reason for changing `py-beginning-of-block' as an example. Rules applied :- have regular behaviour, meet and establish expectations as much as possible. Regular behaviour :- have regular return values Regular behaviour :- used options as respective functions use Return values :- if function moves point - return point Used options :- if function moves point - have a repeat count or no option The `nomark' option has been uncommon, probably singular in Emacs. No need for that. Using standard operations as moving point no need to read the doku should exist. Dropped the repeat count too for `py-beginning-of-block', as `py-beginning-of-block-or-clause' like `py-beginning-of-def-or-class' also has that except/irregularity as def/class switch. A well founded except/irregularity so far, kept and proliferated that. Cheers Andreas From andreas.roehler at online.de Thu Oct 14 09:00:07 2010 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Thu, 14 Oct 2010 09:00:07 +0200 Subject: [Python-mode] obsolete bugs, Blueprints Message-ID: <4CB6AA77.4020809@online.de> Hi Skip, hi folks, seeing Barry gave administration rights to us, we may now adress the ancient bugs one by one, close the obsolete. Closing the obsolete should speed up further development, as the number of good ancient reports is considerable and probably no one will dig through there easily. As I'm still capable of all kind of errors: should some nasty things happen, please don't hesitate to tell me. Suggest to activate the button `Blueprints', which provides a tracker for feature requests AFAIU. Maybe category `Answers' should be enabled too (?) Remember interesting discussion on this list some months ago: would welcome if people dig out proposals from the archiv http://mail.python.org/mailman/listinfo/python-mode and make a fresh entry at `Blueprints'. Thus it remains at the table. AFAIU `Blueprints' allows further discussing and also ranging issues with respect for it's importance. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From andreas.roehler at online.de Thu Oct 14 13:48:13 2010 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Thu, 14 Oct 2010 13:48:13 +0200 Subject: [Python-mode] go-to-initial-line Message-ID: <4CB6EDFD.4020300@online.de> Hi Barry, hi Skip, hi python-mode folks, just checked in a fix for `go-to-initial-line'. It's pretty sure from my perspective, there will be lot more bugs of these kind be inside the venerable trunk. Could build a kind machine from abtract reasoning producing it's reports. However, fixing them on the base given is rather difficult. For the very reason this fix is a rather wooden part of plastic. Bien sure, developers already have remarked that difficulty and commented it `tricky' inside the code. IMHO it's difficulty relies in the fact, that every time cursor changes a state a couple of questions have be to asked again. It's a matter of design so far, therefor the re-design in python-mode-components. The natural solution for me was writing a recursive function employing `cond', so everytime a condition has been met, the whole circle starts from the beginning. That should avoid a whole bunch of bugs. Would appreciate it much, if you could try the python-mode-reassembled.el from inside https://code.launchpad.net/~a-roehler/python-mode/python-mode-components `python-mode-reassembled.el' keeps the python-mode ranges of functions basically, but should avoid the bugs mentioned. Thanks all, happy testing, Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From christoph.conrad at gmx.de Sat Oct 30 12:57:11 2010 From: christoph.conrad at gmx.de (Christoph Conrad) Date: Sat, 30 Oct 2010 12:57:11 +0200 Subject: [Python-mode] Bug in python-mode.el 5.1.0? Message-ID: <87aalwt0ah.fsf@ID-24456.user.uni-berlin.de> Hi, i assume the following code should be changed: ;; TBD: a horrible hack, but why create new Custom variables? ;; -cco- OLD: (let ((cmd (concat py-which-shell (if (string-equal py-which-bufname (let ((cmd (concat shell (if (string-equal py-which-bufname "Jython") " -" "")))) Regards, Christoph From christoph.conrad at gmx.de Sat Oct 30 12:57:11 2010 From: christoph.conrad at gmx.de (Christoph Conrad) Date: Sat, 30 Oct 2010 12:57:11 +0200 Subject: [Python-mode] Bug in python-mode.el 5.1.0? Message-ID: <87aalwt0ah.fsf@ID-24456.user.uni-berlin.de> Hi, i assume the following code should be changed: ;; TBD: a horrible hack, but why create new Custom variables? ;; -cco- OLD: (let ((cmd (concat py-which-shell (if (string-equal py-which-bufname (let ((cmd (concat shell (if (string-equal py-which-bufname "Jython") " -" "")))) Regards, Christoph From christoph.conrad at gmx.de Sat Oct 30 13:35:15 2010 From: christoph.conrad at gmx.de (Christoph Conrad) Date: Sat, 30 Oct 2010 13:35:15 +0200 Subject: [Python-mode] Two other bugs in python-mode.el 5.1.0? Message-ID: <871v77ewug.fsf@ID-24456.user.uni-berlin.de> Hi, i also assume the following code should be changed: ;; added: -cco- ((equal arg 'python) (setq arg 1)) ((equal arg 'cpython) (setq arg 1)) ((equal arg 'jython) (setq arg -1))) else it fails on ((< 0 arg) ========= ;; -cco- (start-process py-which-bufname buf shell arg file) (start-process py-which-bufname buf (format "%s" shell) arg file) cause shell can be a symbol Regards, Christoph