From andreas.roehler at online.de Wed Mar 9 22:24:47 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Wed, 09 Mar 2011 22:24:47 +0100 Subject: [Python-mode] highlight-indentation Message-ID: <4D77F01F.8030201@online.de> Hi Barry, just seeing highlight-indentation by Anton Johansson - thanks a lot to him BTW - which I suggest to include into next release. It delivers graphical bars indicating the indent-level, makes em more impressive. Might be useful in certain circumstances. Source: https://github.com/antonj/Highlight-Indentation-for-Emacs/blob/master/highlight-indentation.el Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Fri Mar 11 13:47:54 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 11 Mar 2011 07:47:54 -0500 Subject: [Python-mode] highlight-indentation In-Reply-To: <4D77F01F.8030201@online.de> References: <4D77F01F.8030201@online.de> Message-ID: <20110311074754.3f5b3840@neurotica> On Mar 09, 2011, at 10:24 PM, Andreas R?hler wrote: >just seeing highlight-indentation by Anton Johansson - thanks a lot to him >BTW - which I suggest to include into next release. > >It delivers graphical bars indicating the indent-level, makes em more >impressive. Might be useful in certain circumstances. Hi Andreas, Anton, Indeed, I agree that this could be very useful in some situations. It can be a little distracting, so it probably should not be turned on by default, but for those cases where the indentation is really hard to follow, I think this could be a very nice addition. Is this file going to be added to Emacs? It seems more general than just for Python (e.g. turn it on in python-mode.el). One minor nit: I wonder if it makes sense to highlight columns that are not in the leading whitespace. For example, turn it on and look at the define-key lines starting at about line 845 in python-mode.el. There are some highlighted indentation extents after the "\C-c:" string. Those don't seem useful. Thanks for pointing it out, and thanks to Anton for writing it. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Fri Mar 11 18:30:55 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 11 Mar 2011 18:30:55 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <20110311074754.3f5b3840@neurotica> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> Message-ID: <4D7A5C4F.7050208@online.de> Am 11.03.2011 13:47, schrieb Barry Warsaw: > On Mar 09, 2011, at 10:24 PM, Andreas R?hler wrote: > >> just seeing highlight-indentation by Anton Johansson - thanks a lot to him >> BTW - which I suggest to include into next release. >> >> It delivers graphical bars indicating the indent-level, makes em more >> impressive. Might be useful in certain circumstances. > > Hi Andreas, Anton, > Hi Barry, > Indeed, I agree that this could be very useful in some situations. good news :-) It can be > a little distracting, so it probably should not be turned on by default, as it's just a function, user may call them or not. It doesn't interfere. BTW exists still another nice tool of the same author at: http://stackoverflow.com/questions/1587972/how-to-display-indentation-guides-in-emacs (defun aj-toggle-fold () "Toggle fold all lines larger than indentation on current line" (interactive) (let ((col 1)) (save-excursion (back-to-indentation) (setq col (+ 1 (current-column))) (set-selective-display (if selective-display nil (or col 1)))))) (global-set-key [(M C i)] 'aj-toggle-fold) Maybe have look. but > for those cases where the indentation is really hard to follow, I think this > could be a very nice addition. > > Is this file going to be added to Emacs? It seems more general than just for > Python (e.g. turn it on in python-mode.el). > > One minor nit: I wonder if it makes sense to highlight columns that are not in > the leading whitespace. For example, turn it on and look at the define-key > lines starting at about line 845 in python-mode.el. There are some > highlighted indentation extents after the "\C-c:" string. Those don't seem > useful. Yes, seeing that too. AFAIU it will be hard to cure, as the function sets consecutive whitespaces as keywords. Trailing whitespaces are marked that way too. Also it only occurs if large whitespaces are somewhere between. For the purpose of quickly indicating multiple indents it's fine. So don't see a need to ask for a change at this state. Andreas > > Thanks for pointing it out, and thanks to Anton for writing it. > > Cheers, > -Barry From barry at python.org Sat Mar 12 04:28:58 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 11 Mar 2011 22:28:58 -0500 Subject: [Python-mode] highlight-indentation In-Reply-To: <4D7A5C4F.7050208@online.de> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> Message-ID: <20110311222858.37857a7f@neurotica> Hi Andreas, I noticed that you committed this file to our bzr tree. I'm concerned about doing this without Anton's approval (and maybe even with it). Anton probably has his own source code repository, so at the very least it would be more effort for us to keep our copy up-to-date with his. python-mode.el doesn't depend on his code, so it's really not necessary for us to have a copy in our tree. As cool as Anton's module is, and it definitely could help Python programmers, it's probably a better idea to add a reference to his work (and his download site or source repository) in our README file or in the comments at the top of python-mode.el. If Anton really wants us to keep the canonical version of his mode in our bzr tree, we could discuss that. Anton, what do you think? Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Sat Mar 12 13:44:40 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Sat, 12 Mar 2011 13:44:40 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <20110311222858.37857a7f@neurotica> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> Message-ID: <4D7B6AB8.6030800@online.de> Am 12.03.2011 04:28, schrieb Barry Warsaw: > Hi Andreas, > > I noticed that you committed this file to our bzr tree. Hi Barry, took preceding exchange for an approval. Will be more carful next time. I'm concerned about > doing this without Anton's approval (and maybe even with it). Anton probably > has his own source code repository, so at the very least it would be more > effort for us to keep our copy up-to-date with his. python-mode.el doesn't > depend on his code, so it's really not necessary for us to have a copy in our > tree. > > As cool as Anton's module is, and it definitely could help Python programmers, > it's probably a better idea to add a reference to his work (and his download > site or source repository) in our README file or in the comments at the top of > python-mode.el. > > If Anton really wants us to keep the canonical version of his mode in our bzr > tree, we could discuss that. Anton, what do you think? > > Cheers, > -Barry As for the approval: thought that's precisely what the GPL is for. So if an author publishs it's code under GPL, that's for the very reason others may take it, isn't it? Beside I gave credits with commit message, inside the header and also dropped a notice to the author. Which doesn't mean your concerns are invalid, posed them for me also and answered them as given above. Likewise as for the technical aspects of repository: Having useful Emacs code all around the net, it's just the situation we are in. It's not all bad with that, makes some pleasure to look around, trying this and that. As for my concern here I'm heading for an IDE, where people open Emacs and find ererything ready for Python edits as far as the state of art delivers it. That means the question you raised concerning whitespaces for examples must be discussed before and at place. You can't know what our creative folks will be have in mind next, if it will be suitable, more or less, buggy more or less and so on. It's not done with links delivered. If we will provide an Python-IDE we must be able to tell: here is it's specification, it will work for these conditions, makings that requirements. Therefor we must collect the code for the specified purpose, IMHO :-) Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From sesquile at gmail.com Sat Mar 12 23:17:16 2011 From: sesquile at gmail.com (m h) Date: Sat, 12 Mar 2011 22:17:16 +0000 Subject: [Python-mode] anyone going to pycon emacs bof? Message-ID: Just wondering... -matt From barry at python.org Sat Mar 12 21:46:22 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 12 Mar 2011 15:46:22 -0500 Subject: [Python-mode] anyone going to pycon emacs bof? In-Reply-To: References: Message-ID: <20110312154622.2256f993@neurotica> On Mar 12, 2011, at 10:17 PM, m h wrote: >Just wondering... Is there one? I probably missed it on the big board, but I'd be up for meeting with other Emacsers. I'm in the testing BOF tonight though. ;) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Sun Mar 13 09:15:11 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Sun, 13 Mar 2011 09:15:11 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> Message-ID: <4D7C7D0F.2030304@online.de> Hi Anton, thanks a lot BTW. Added a link onto your repo into the header. In order to get a wider audience with resp. to other modes an entry at http://www.emacswiki.org/emacs-en might be useful. As for bug-tracking think we should forward any report to you, if it concerns your file(s). OTOH would not charge the users which such specific requests. Agreed? Thanks again. Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ Am 12.03.2011 11:38, schrieb Anton Johansson: > Hello, > > I'm absolutely cool with you guys using the code in any way you find > suitable, nice to see some people finding it useful! > > Like you have discussed before, there are some issues with > highlight-indentation.el that could be handled better, for example > highlighting spaces that are not in the leading whitespace. If you can > find a good way to link to my repo so that people can submit possible > fixes that would be good since the code is also usable in other modes. > > Cheers > -Anton > > On Sat, Mar 12, 2011 at 4:28 AM, Barry Warsaw wrote: >> Hi Andreas, >> >> I noticed that you committed this file to our bzr tree. I'm concerned about >> doing this without Anton's approval (and maybe even with it). Anton probably >> has his own source code repository, so at the very least it would be more >> effort for us to keep our copy up-to-date with his. python-mode.el doesn't >> depend on his code, so it's really not necessary for us to have a copy in our >> tree. >> >> As cool as Anton's module is, and it definitely could help Python programmers, >> it's probably a better idea to add a reference to his work (and his download >> site or source repository) in our README file or in the comments at the top of >> python-mode.el. >> >> If Anton really wants us to keep the canonical version of his mode in our bzr >> tree, we could discuss that. Anton, what do you think? >> >> Cheers, >> -Barry >> > From andrea.crotti.0 at gmail.com Sun Mar 13 12:49:44 2011 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Sun, 13 Mar 2011 12:49:44 +0100 Subject: [Python-mode] Error during indentation Message-ID: I get a strange error when I have a situation like this: --8<---------------cut here---------------start------------->8--- 1 class Foo(object): 2 """ 3 Some doc 4 """ 5 --8<---------------cut here---------------end--------------->8--- if I go to line 5 and press tab I get the error as below, using: GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-03-04 and python-mode from bzr (can I get automatically the revision from emacs?) --8<---------------cut here---------------start------------->8--- Debugger entered--Lisp error: (wrong-type-argument integerp t) make-string(1 t) py-goto-beginning-of-tqs(t) py-compute-indentation(t) py-indent-line() indent-for-tab-command(nil) call-interactively(indent-for-tab-command) (progn (setq this-command command) (call-interactively command)) (if (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (progn (setq this-command command) (call-interactively command))) (when (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (setq this-command command) (call-interactively command)) (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 (this-command-keys-vector)) (keys-2 (and yas/trigger-key from-trigger-key-p (stringp yas/trigger-key) (read-kbd-macro yas/trigger-key))) (command-1 (and keys-1 (key-binding keys-1))) (command-2 (and keys-2 (key-binding keys-2))) (command (or (and (symbolp command-1) (not (string-match "yas/expand" (symbol-name command-1))) command-1) (and (symbolp command-2) command-2)))) (when (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (setq this-command command) (call-interactively command))) (cond ((eq yas/fallback-behavior (quote return-nil)) nil) ((eq yas/fallback-behavior (quote call-other-command)) (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 (this-command-keys-vector)) (keys-2 (and yas/trigger-key from-trigger-key-p (stringp yas/trigger-key) (read-kbd-macro yas/trigger-key))) (command-1 (and keys-1 (key-binding keys-1))) (command-2 (and keys-2 (key-binding keys-2))) (command (or (and (symbolp command-1) (not ...) command-1) (and (symbolp command-2) command-2)))) (when (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (setq this-command command) (call-interactively command)))) ((and (listp yas/fallback-behavior) (cdr yas/fallback-behavior) (eq (quote apply) (car yas/fallback-behavior))) (if (cddr yas/fallback-behavior) (apply (cadr yas/fallback-behavior) (cddr yas/fallback-behavior)) (when (commandp (cadr yas/fallback-behavior)) (setq this-command (cadr yas/fallback-behavior)) (call-interactively (cadr yas/fallback-behavior))))) (t nil)) yas/fallback(trigger-key) (if (and templates-and-pos (first templates-and-pos)) (yas/expand-or-prompt-for-template (first templates-and-pos) (second templates-and-pos) (third templates-and-pos)) (yas/fallback (quote trigger-key))) (let (templates-and-pos) (unless (and yas/expand-only-for-last-commands (not (member last-command yas/expand-only-for-last-commands))) (setq templates-and-pos (if field (save-restriction (narrow-to-region (yas/field-start field) (yas/field-end field)) (yas/current-key)) (yas/current-key)))) (if (and templates-and-pos (first templates-and-pos)) (yas/expand-or-prompt-for-template (first templates-and-pos) (second templates-and-pos) (third templates-and-pos)) (yas/fallback (quote trigger-key)))) yas/expand() call-interactively(yas/expand nil nil) --8<---------------cut here---------------end--------------->8--- From barry at python.org Sun Mar 13 13:28:35 2011 From: barry at python.org (Barry Warsaw) Date: Sun, 13 Mar 2011 08:28:35 -0400 Subject: [Python-mode] Error during indentation In-Reply-To: References: Message-ID: <20110313082835.531c6571@neurotica> On Mar 13, 2011, at 12:49 PM, Andrea Crotti wrote: >I get a strange error when I have a situation like this: >--8<---------------cut here---------------start------------->8--- > 1 class Foo(object): > 2 """ > 3 Some doc > 4 """ > 5 >--8<---------------cut here---------------end--------------->8--- >if I go to line 5 and press tab I get the error as below, using: >GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of >2011-03-04 >and python-mode from bzr (can I get automatically the revision from emacs?) I cannot reproduce this with Emacs 23.2.1 on Ubuntu Natty and python-mode.el r400. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Sun Mar 13 16:10:36 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Sun, 13 Mar 2011 16:10:36 +0100 Subject: [Python-mode] Error during indentation In-Reply-To: References: Message-ID: <4D7CDE6C.1070700@online.de> Am 13.03.2011 12:49, schrieb Andrea Crotti: > > I get a strange error when I have a situation like this: > --8<---------------cut here---------------start------------->8--- > 1 class Foo(object): > 2 """ > 3 Some doc > 4 """ > 5 > --8<---------------cut here---------------end--------------->8--- > if I go to line 5 and press tab I get the error as below, using: > GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of > 2011-03-04 > and python-mode from bzr (can I get automatically the revision from emacs?) you may subscribe for mail at https://code.launchpad.net/~python-mode-devs/python-mode/python-mode then you will get a mail always the branch is updated Afterwards do bzr branch lp:python-mode BTW : can't reproduce the bug. Andreas > > --8<---------------cut here---------------start------------->8--- > Debugger entered--Lisp error: (wrong-type-argument integerp t) > make-string(1 t) > py-goto-beginning-of-tqs(t) > py-compute-indentation(t) > py-indent-line() > indent-for-tab-command(nil) > call-interactively(indent-for-tab-command) > (progn (setq this-command command) (call-interactively command)) > (if (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (progn (setq this-command command) (call-interactively command))) > (when (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (setq this-command command) (call-interactively command)) > (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 (this-command-keys-vector)) (keys-2 (and yas/trigger-key from-trigger-key-p (stringp yas/trigger-key) (read-kbd-macro yas/trigger-key))) (command-1 (and keys-1 (key-binding keys-1))) (command-2 (and keys-2 (key-binding keys-2))) (command (or (and (symbolp command-1) (not (string-match "yas/expand" (symbol-name command-1))) command-1) (and (symbolp command-2) command-2)))) (when (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (setq this-command command) (call-interactively command))) > (cond ((eq yas/fallback-behavior (quote return-nil)) nil) ((eq yas/fallback-behavior (quote call-other-command)) (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 (this-command-keys-vector)) (keys-2 (and yas/trigger-key from-trigger-key-p (stringp yas/trigger-key) (read-kbd-macro yas/trigger-key))) (command-1 (and keys-1 (key-binding keys-1))) (command-2 (and keys-2 (key-binding keys-2))) (command (or (and (symbolp command-1) (not ...) command-1) (and (symbolp command-2) command-2)))) (when (and (commandp command) (not (string-match "yas/expand" (symbol-name command)))) (setq this-command command) (call-interactively command)))) ((and (listp yas/fallback-behavior) (cdr yas/fallback-behavior) (eq (quote apply) (car yas/fallback-behavior))) (if (cddr yas/fallback-behavior) (apply (cadr yas/fallback-behavior) (cddr yas/fallback-behavior)) (when (commandp (cadr yas/fallback-behavior)) (setq this-command (cadr yas/fallback-behavior)) (call-interactively (cadr yas/f all > back-behavior))))) (t nil)) > yas/fallback(trigger-key) > (if (and templates-and-pos (first templates-and-pos)) (yas/expand-or-prompt-for-template (first templates-and-pos) (second templates-and-pos) (third templates-and-pos)) (yas/fallback (quote trigger-key))) > (let (templates-and-pos) (unless (and yas/expand-only-for-last-commands (not (member last-command yas/expand-only-for-last-commands))) (setq templates-and-pos (if field (save-restriction (narrow-to-region (yas/field-start field) (yas/field-end field)) (yas/current-key)) (yas/current-key)))) (if (and templates-and-pos (first templates-and-pos)) (yas/expand-or-prompt-for-template (first templates-and-pos) (second templates-and-pos) (third templates-and-pos)) (yas/fallback (quote trigger-key)))) > yas/expand() > call-interactively(yas/expand nil nil) > > --8<---------------cut here---------------end--------------->8--- > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > From andrea.crotti.0 at gmail.com Sun Mar 13 21:09:53 2011 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Sun, 13 Mar 2011 21:09:53 +0100 Subject: [Python-mode] Error during indentation Message-ID: <204CDE48-55DB-47EB-B485-8C5320C28548@gmail.com> Barry Warsaw writes: > On Mar 13, 2011, at 12:49 PM, Andrea Crotti wrote: > >>I get a strange error when I have a situation like this: >>--8<---------------cut here---------------start------------->8--- >> 1 class Foo(object): >> 2 """ >> 3 Some doc >> 4 """ >> 5=09 >>--8<---------------cut here---------------end--------------->8--- >>if I go to line 5 and press tab I get the error as below, using: >>GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of >>2011-03-04 >>and python-mode from bzr (can I get automatically the revision from emacs= ?) > > I cannot reproduce this with Emacs 23.2.1 on Ubuntu Natty and python-mode= .el > r400. > > -Barry > I thought it was something else interfering, but I've: - update to rev400 - byte-compiled python-mode - started a new emacs24 -Q in the scratch buffer wrote as above, and still the same error... --8<---------------cut here---------------start------------->8--- Debugger entered--Lisp error: (wrong-type-argument integerp t) make-string(1 t) (and delim (make-string 1 delim)) (let ((skip (and delim (make-string 1 delim))) (continue t)) (when skip (= save-excursion (while continue (py-safe (search-backward skip)) (setq conti= nue (and (not (bobp)) (=3D (char-before) 92)))) (if (and (=3D (char-before)= delim) (=3D (char-before (1- ...)) delim)) (setq skip (make-string 3 delim= )))) (py-safe (search-backward skip)))) py-goto-beginning-of-tqs(t) (cond ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipp= s))) (save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-ba= ckward "^[ ]*\\([^ \n#]\\|#[ \n]\\)" nil (quote move)) (back-to-indentat= ion) (current-column)))) ((py-continuation-line-p) (let ((startpos (point))= (open-bracket-pos (py-nesting-level)) endpos searching found state cind cl= ine) (if open-bracket-pos (progn (setq endpos (py-point (quote bol))) (py-g= oto-initial-line) (setq cind (current-indentation)) (setq cline cind) (doli= st (bp (nth 9 ...) cind) (if (search-forward "\n" bp t) (setq cline cind)) = (goto-char (1+ bp)) (skip-chars-forward " ") (setq cind (if ... ... ...)))= ) (forward-line -1) (if (py-continuation-line-p) (current-indentation) (end= -of-line) (setq endpos (point) searching t) (back-to-indentation) (setq sta= rtpos (point)) (while searching (skip-chars-forward "^=3D" endpos) (if (=3D= ... endpos) (setq searching nil) (forward-char 1) (setq state ...) (if ...= ...))) (if (or (not found) (looking-at "[ ]*\\\\")) (progn (goto-char sta= rtpos) (skip-chars-forward "^ \n"))) (+ (current-column) (if (py-statement= -opens-block-p) py-continuation-offset 0) 1))))) ((bobp) (current-indentati= on)) ((and (looking-at "[ ]*#[^ \n]") (fboundp (quote forward-comment)) (= <=3D (current-indentation) (save-excursion (forward-comment (- (point-max))= ) (current-indentation)))) (current-indentation)) (t (if (and (eq py-honor-= comment-indentation nil) (fboundp (quote forward-comment))) (forward-commen= t (- (point-max))) (let ((prefix-re (concat py-block-comment-prefix "[ ]*"= )) done) (while (not done) (re-search-backward "^[ ]*\\([^ \n#]\\|#\\)" n= il (quote move)) (setq done (or (bobp) (and ... ...) (and ... ...)))))) (py= -goto-beginning-of-tqs (nth 3 (parse-partial-sexp bod (point)))) (setq plac= eholder (point)) (py-goto-initial-line) (py-goto-beginning-of-tqs (save-exc= ursion (nth 3 (parse-partial-sexp placeholder (point))))) (+ (current-inden= tation) (if (py-statement-opens-block-p) py-indent-offset (if (and honor-bl= ock-close-p (py-statement-closes-block-p)) (- py-indent-offset) 0))))) (let* ((bod (py-point (quote bod))) (pps (parse-partial-sexp bod (point))= ) (boipps (parse-partial-sexp bod (py-point (quote boi)))) placeholder) (co= nd ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipps))) = (save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-backwar= d "^[ ]*\\([^ \n#]\\|#[ \n]\\)" nil (quote move)) (back-to-indentation) = (current-column)))) ((py-continuation-line-p) (let ((startpos (point)) (ope= n-bracket-pos (py-nesting-level)) endpos searching found state cind cline) = (if open-bracket-pos (progn (setq endpos (py-point ...)) (py-goto-initial-l= ine) (setq cind (current-indentation)) (setq cline cind) (dolist (bp ... ci= nd) (if ... ...) (goto-char ...) (skip-chars-forward " ") (setq cind ...))= ) (forward-line -1) (if (py-continuation-line-p) (current-indentation) (end= -of-line) (setq endpos (point) searching t) (back-to-indentation) (setq sta= rtpos (point)) (while searching (skip-chars-forward "^=3D" endpos) (if ... = ... ... ... ...)) (if (or ... ...) (progn ... ...)) (+ (current-column) (if= ... py-continuation-offset 0) 1))))) ((bobp) (current-indentation)) ((and = (looking-at "[ ]*#[^ \n]") (fboundp (quote forward-comment)) (<=3D (curre= nt-indentation) (save-excursion (forward-comment (- ...)) (current-indentat= ion)))) (current-indentation)) (t (if (and (eq py-honor-comment-indentation= nil) (fboundp (quote forward-comment))) (forward-comment (- (point-max))) = (let ((prefix-re (concat py-block-comment-prefix "[ ]*")) done) (while (no= t done) (re-search-backward "^[ ]*\\([^ \n#]\\|#\\)" nil (quote move)) (s= etq done (or ... ... ...))))) (py-goto-beginning-of-tqs (nth 3 (parse-parti= al-sexp bod (point)))) (setq placeholder (point)) (py-goto-initial-line) (p= y-goto-beginning-of-tqs (save-excursion (nth 3 (parse-partial-sexp placehol= der (point))))) (+ (current-indentation) (if (py-statement-opens-block-p) p= y-indent-offset (if (and honor-block-close-p (py-statement-closes-block-p))= (- py-indent-offset) 0)))))) (save-excursion (beginning-of-line) (let* ((bod (py-point (quote bod))) (= pps (parse-partial-sexp bod (point))) (boipps (parse-partial-sexp bod (py-p= oint (quote boi)))) placeholder) (cond ((or (and (nth 3 pps) (nth 3 boipps)= ) (and (nth 4 pps) (nth 4 boipps))) (save-excursion (if (not py-align-multi= line-strings-p) 0 (re-search-backward "^[ ]*\\([^ \n#]\\|#[ \n]\\)" nil = (quote move)) (back-to-indentation) (current-column)))) ((py-continuation-l= ine-p) (let ((startpos (point)) (open-bracket-pos (py-nesting-level)) endpo= s searching found state cind cline) (if open-bracket-pos (progn (setq endpo= s ...) (py-goto-initial-line) (setq cind ...) (setq cline cind) (dolist ...= ... ... ... ...)) (forward-line -1) (if (py-continuation-line-p) (current-= indentation) (end-of-line) (setq endpos ... searching t) (back-to-indentati= on) (setq startpos ...) (while searching ... ...) (if ... ...) (+ ... ... 1= ))))) ((bobp) (current-indentation)) ((and (looking-at "[ ]*#[^ \n]") (fb= oundp (quote forward-comment)) (<=3D (current-indentation) (save-excursion = (forward-comment ...) (current-indentation)))) (current-indentation)) (t (i= f (and (eq py-honor-comment-indentation nil) (fboundp (quote forward-commen= t))) (forward-comment (- (point-max))) (let ((prefix-re ...) done) (while (= not done) (re-search-backward "^[ ]*\\([^ \n#]\\|#\\)" nil ...) (setq don= e ...)))) (py-goto-beginning-of-tqs (nth 3 (parse-partial-sexp bod (point))= )) (setq placeholder (point)) (py-goto-initial-line) (py-goto-beginning-of-= tqs (save-excursion (nth 3 (parse-partial-sexp placeholder ...)))) (+ (curr= ent-indentation) (if (py-statement-opens-block-p) py-indent-offset (if (and= honor-block-close-p ...) (- py-indent-offset) 0))))))) py-compute-indentation(t) (let* ((ci (current-indentation)) (move-to-indentation-p (<=3D (current-c= olumn) ci)) (need (py-compute-indentation (not arg))) (cc (current-column))= ) (if (and (equal last-command this-command) (/=3D cc 0)) (progn (beginning= -of-line) (delete-horizontal-space) (indent-to (* (/ (- cc 1) py-indent-off= set) py-indent-offset))) (progn (if (py-outdent-p) (setq need (- need py-in= dent-offset))) (if (or py-tab-always-indent move-to-indentation-p) (progn (= if (/=3D ci need) (save-excursion (beginning-of-line) (delete-horizontal-sp= ace) (indent-to need))) (if move-to-indentation-p (back-to-indentation))) (= insert-tab))))) py-indent-line() indent-for-tab-command(nil) call-interactively(indent-for-tab-command nil nil) --8<---------------cut here---------------end--------------->8--- From andreas.roehler at online.de Mon Mar 14 13:39:10 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Mon, 14 Mar 2011 13:39:10 +0100 Subject: [Python-mode] Error during indentation In-Reply-To: <204CDE48-55DB-47EB-B485-8C5320C28548@gmail.com> References: <204CDE48-55DB-47EB-B485-8C5320C28548@gmail.com> Message-ID: <4D7E0C6E.2010601@online.de> Am 13.03.2011 21:09, schrieb Andrea Crotti: > Barry Warsaw writes: > >> On Mar 13, 2011, at 12:49 PM, Andrea Crotti wrote: >> >>> I get a strange error when I have a situation like this: >>> --8<---------------cut here---------------start------------->8--- >>> 1 class Foo(object): >>> 2 """ >>> 3 Some doc >>> 4 """ >>> 5=09 >>> --8<---------------cut here---------------end--------------->8--- >>> if I go to line 5 and press tab I get the error as below, using: >>> GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of >>> 2011-03-04 >>> and python-mode from bzr (can I get automatically the revision from emacs= > ?) >> >> I cannot reproduce this with Emacs 23.2.1 on Ubuntu Natty and python-mode= > .el >> r400. >> >> -Barry >> > > I thought it was something else interfering, but I've: > - update to rev400 > - byte-compiled python-mode > - started a new emacs24 -Q > > in the scratch buffer wrote as above, and still the same error... > --8<---------------cut here---------------start------------->8--- > > Debugger entered--Lisp error: (wrong-type-argument integerp t) > make-string(1 t) > (and delim (make-string 1 delim)) > (let ((skip (and delim (make-string 1 delim))) (continue t)) (when skip (= > save-excursion (while continue (py-safe (search-backward skip)) (setq conti= > nue (and (not (bobp)) (=3D (char-before) 92)))) (if (and (=3D (char-before)= > delim) (=3D (char-before (1- ...)) delim)) (setq skip (make-string 3 delim= > )))) (py-safe (search-backward skip)))) > py-goto-beginning-of-tqs(t) Hi Andrea, thanks. Have some idea meanwhile wherefrom these bug. It's in the line above, resp. it's receiving function. Ironically you get this bug, because syntax setting is OK now with Emacs 24. AFAIS bug results, because the delimiting char of a triple-quoted-string is no longer of 7, string quote, but of 15, generic string. syntax-ppss and friends than don't send the delimiting char as integer, but `t'. The receiving functions refuses correctly to make a string from: wrong-type-argument integerp t) With some luck I'll send a fix next days... Andreas > (cond ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipp= > s))) (save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-ba= > ckward "^[ ]*\\([^ \n#]\\|#[ \n]\\)" nil (quote move)) (back-to-indentat= > ion) (current-column)))) ((py-continuation-line-p) (let ((startpos (point))= > (open-bracket-pos (py-nesting-level)) endpos searching found state cind cl= > ine) (if open-bracket-pos (progn (setq endpos (py-point (quote bol))) (py-g= > oto-initial-line) (setq cind (current-indentation)) (setq cline cind) (doli= > st (bp (nth 9 ...) cind) (if (search-forward "\n" bp t) (setq cline cind)) = > (goto-char (1+ bp)) (skip-chars-forward " ") (setq cind (if ... ... ...)))= > ) (forward-line -1) (if (py-continuation-line-p) (current-indentation) (end= > -of-line) (setq endpos (point) searching t) (back-to-indentation) (setq sta= > rtpos (point)) (while searching (skip-chars-forward "^=3D" endpos) (if (=3D= > ... endpos) (setq searching nil) (forward-char 1) (setq state ...) (if ...= > ...))) (if (or (not found) (looking-at "[ ]*\\\\")) (progn (goto-char sta= > rtpos) (skip-chars-forward "^ \n"))) (+ (current-column) (if (py-statement= > -opens-block-p) py-continuation-offset 0) 1))))) ((bobp) (current-indentati= > on)) ((and (looking-at "[ ]*#[^ \n]") (fboundp (quote forward-comment)) (= > <=3D (current-indentation) (save-excursion (forward-comment (- (point-max))= > ) (current-indentation)))) (current-indentation)) (t (if (and (eq py-honor-= > comment-indentation nil) (fboundp (quote forward-comment))) (forward-commen= > t (- (point-max))) (let ((prefix-re (concat py-block-comment-prefix "[ ]*"= > )) done) (while (not done) (re-search-backward "^[ ]*\\([^ \n#]\\|#\\)" n= > il (quote move)) (setq done (or (bobp) (and ... ...) (and ... ...)))))) (py= > -goto-beginning-of-tqs (nth 3 (parse-partial-sexp bod (point)))) (setq plac= > eholder (point)) (py-goto-initial-line) (py-goto-beginning-of-tqs (save-exc= > ursion (nth 3 (parse-partial-sexp placeholder (point))))) (+ (current-inden= > tation) (if (py-statement-opens-block-p) py-indent-offset (if (and honor-bl= > ock-close-p (py-statement-closes-block-p)) (- py-indent-offset) 0))))) > (let* ((bod (py-point (quote bod))) (pps (parse-partial-sexp bod (point))= > ) (boipps (parse-partial-sexp bod (py-point (quote boi)))) placeholder) (co= > nd ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipps))) = > (save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-backwar= > d "^[ ]*\\([^ \n#]\\|#[ \n]\\)" nil (quote move)) (back-to-indentation) = > (current-column)))) ((py-continuation-line-p) (let ((startpos (point)) (ope= > n-bracket-pos (py-nesting-level)) endpos searching found state cind cline) = > (if open-bracket-pos (progn (setq endpos (py-point ...)) (py-goto-initial-l= > ine) (setq cind (current-indentation)) (setq cline cind) (dolist (bp ... ci= > nd) (if ... ...) (goto-char ...) (skip-chars-forward " ") (setq cind ...))= > ) (forward-line -1) (if (py-continuation-line-p) (current-indentation) (end= > -of-line) (setq endpos (point) searching t) (back-to-indentation) (setq sta= > rtpos (point)) (while searching (skip-chars-forward "^=3D" endpos) (if ... = > ... ... ... ...)) (if (or ... ...) (progn ... ...)) (+ (current-column) (if= > ... py-continuation-offset 0) 1))))) ((bobp) (current-indentation)) ((and = > (looking-at "[ ]*#[^ \n]") (fboundp (quote forward-comment)) (<=3D (curre= > nt-indentation) (save-excursion (forward-comment (- ...)) (current-indentat= > ion)))) (current-indentation)) (t (if (and (eq py-honor-comment-indentation= > nil) (fboundp (quote forward-comment))) (forward-comment (- (point-max))) = > (let ((prefix-re (concat py-block-comment-prefix "[ ]*")) done) (while (no= > t done) (re-search-backward "^[ ]*\\([^ \n#]\\|#\\)" nil (quote move)) (s= > etq done (or ... ... ...))))) (py-goto-beginning-of-tqs (nth 3 (parse-parti= > al-sexp bod (point)))) (setq placeholder (point)) (py-goto-initial-line) (p= > y-goto-beginning-of-tqs (save-excursion (nth 3 (parse-partial-sexp placehol= > der (point))))) (+ (current-indentation) (if (py-statement-opens-block-p) p= > y-indent-offset (if (and honor-block-close-p (py-statement-closes-block-p))= > (- py-indent-offset) 0)))))) > (save-excursion (beginning-of-line) (let* ((bod (py-point (quote bod))) (= > pps (parse-partial-sexp bod (point))) (boipps (parse-partial-sexp bod (py-p= > oint (quote boi)))) placeholder) (cond ((or (and (nth 3 pps) (nth 3 boipps)= > ) (and (nth 4 pps) (nth 4 boipps))) (save-excursion (if (not py-align-multi= > line-strings-p) 0 (re-search-backward "^[ ]*\\([^ \n#]\\|#[ \n]\\)" nil = > (quote move)) (back-to-indentation) (current-column)))) ((py-continuation-l= > ine-p) (let ((startpos (point)) (open-bracket-pos (py-nesting-level)) endpo= > s searching found state cind cline) (if open-bracket-pos (progn (setq endpo= > s ...) (py-goto-initial-line) (setq cind ...) (setq cline cind) (dolist ...= > ... ... ... ...)) (forward-line -1) (if (py-continuation-line-p) (current-= > indentation) (end-of-line) (setq endpos ... searching t) (back-to-indentati= > on) (setq startpos ...) (while searching ... ...) (if ... ...) (+ ... ... 1= > ))))) ((bobp) (current-indentation)) ((and (looking-at "[ ]*#[^ \n]") (fb= > oundp (quote forward-comment)) (<=3D (current-indentation) (save-excursion = > (forward-comment ...) (current-indentation)))) (current-indentation)) (t (i= > f (and (eq py-honor-comment-indentation nil) (fboundp (quote forward-commen= > t))) (forward-comment (- (point-max))) (let ((prefix-re ...) done) (while (= > not done) (re-search-backward "^[ ]*\\([^ \n#]\\|#\\)" nil ...) (setq don= > e ...)))) (py-goto-beginning-of-tqs (nth 3 (parse-partial-sexp bod (point))= > )) (setq placeholder (point)) (py-goto-initial-line) (py-goto-beginning-of-= > tqs (save-excursion (nth 3 (parse-partial-sexp placeholder ...)))) (+ (curr= > ent-indentation) (if (py-statement-opens-block-p) py-indent-offset (if (and= > honor-block-close-p ...) (- py-indent-offset) 0))))))) > py-compute-indentation(t) > (let* ((ci (current-indentation)) (move-to-indentation-p (<=3D (current-c= > olumn) ci)) (need (py-compute-indentation (not arg))) (cc (current-column))= > ) (if (and (equal last-command this-command) (/=3D cc 0)) (progn (beginning= > -of-line) (delete-horizontal-space) (indent-to (* (/ (- cc 1) py-indent-off= > set) py-indent-offset))) (progn (if (py-outdent-p) (setq need (- need py-in= > dent-offset))) (if (or py-tab-always-indent move-to-indentation-p) (progn (= > if (/=3D ci need) (save-excursion (beginning-of-line) (delete-horizontal-sp= > ace) (indent-to need))) (if move-to-indentation-p (back-to-indentation))) (= > insert-tab))))) > py-indent-line() > indent-for-tab-command(nil) > call-interactively(indent-for-tab-command nil nil) > --8<---------------cut here---------------end--------------->8--- > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > From anton.johansson at gmail.com Sat Mar 12 11:38:44 2011 From: anton.johansson at gmail.com (Anton Johansson) Date: Sat, 12 Mar 2011 11:38:44 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <20110311222858.37857a7f@neurotica> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> Message-ID: Hello, I'm absolutely cool with you guys using the code in any way you find suitable, nice to see some people finding it useful! Like you have discussed before, there are some issues with highlight-indentation.el that could be handled better, for example highlighting spaces that are not in the leading whitespace. If you can find a good way to link to my repo so that people can submit possible fixes that would be good since the code is also usable in other modes. Cheers -Anton On Sat, Mar 12, 2011 at 4:28 AM, Barry Warsaw wrote: > Hi Andreas, > > I noticed that you committed this file to our bzr tree. ?I'm concerned about > doing this without Anton's approval (and maybe even with it). ?Anton probably > has his own source code repository, so at the very least it would be more > effort for us to keep our copy up-to-date with his. ?python-mode.el doesn't > depend on his code, so it's really not necessary for us to have a copy in our > tree. > > As cool as Anton's module is, and it definitely could help Python programmers, > it's probably a better idea to add a reference to his work (and his download > site or source repository) in our README file or in the comments at the top of > python-mode.el. > > If Anton really wants us to keep the canonical version of his mode in our bzr > tree, we could discuss that. ?Anton, what do you think? > > Cheers, > -Barry > From anton.johansson at gmail.com Mon Mar 14 10:04:27 2011 From: anton.johansson at gmail.com (Anton Johansson) Date: Mon, 14 Mar 2011 10:04:27 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <4D7C7D0F.2030304@online.de> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> <4D7C7D0F.2030304@online.de> Message-ID: <1F62368C-3EDD-440E-A445-2031F224F82A@gmail.com> Hi, if you can forward bug tracking automatically, please do, otherwise it's ok don't overwork it :) Also the full functionality of highlight-indentation is basically: (setq highlight-indent-offset 4) ;; Spaces indent level (font-lock-add-keywords nil `((,(format "\\( \\) \\{%s\\}" (- highlight-indent-offset 1)) (1 'highlight-indent-face)))) so if you find a better place to extract that to syntax highlighting code it might be better... Cheers -- Anton On Mar 13, 2011, at 09:15 , Andreas R?hler wrote: > Hi Anton, > > thanks a lot BTW. > > Added a link onto your repo into the header. > > In order to get a wider audience with resp. to other modes an entry > at > > http://www.emacswiki.org/emacs-en > > might be useful. > > > As for bug-tracking think we should forward any report to you, if it concerns your file(s). OTOH would not charge the users which such specific requests. > > Agreed? > > Thanks again. > > > Andreas > > -- > https://code.launchpad.net/~a-roehler/python-mode/python-mode-components > https://code.launchpad.net/s-x-emacs-werkstatt/ > > > > > Am 12.03.2011 11:38, schrieb Anton Johansson: >> Hello, >> >> I'm absolutely cool with you guys using the code in any way you find >> suitable, nice to see some people finding it useful! >> >> Like you have discussed before, there are some issues with >> highlight-indentation.el that could be handled better, for example >> highlighting spaces that are not in the leading whitespace. If you can >> find a good way to link to my repo so that people can submit possible >> fixes that would be good since the code is also usable in other modes. >> >> Cheers >> -Anton >> >> On Sat, Mar 12, 2011 at 4:28 AM, Barry Warsaw wrote: >>> Hi Andreas, >>> >>> I noticed that you committed this file to our bzr tree. I'm concerned about >>> doing this without Anton's approval (and maybe even with it). Anton probably >>> has his own source code repository, so at the very least it would be more >>> effort for us to keep our copy up-to-date with his. python-mode.el doesn't >>> depend on his code, so it's really not necessary for us to have a copy in our >>> tree. >>> >>> As cool as Anton's module is, and it definitely could help Python programmers, >>> it's probably a better idea to add a reference to his work (and his download >>> site or source repository) in our README file or in the comments at the top of >>> python-mode.el. >>> >>> If Anton really wants us to keep the canonical version of his mode in our bzr >>> tree, we could discuss that. Anton, what do you think? >>> >>> Cheers, >>> -Barry >>> >> > From andrea.crotti.0 at gmail.com Mon Mar 14 16:38:43 2011 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Mon, 14 Mar 2011 16:38:43 +0100 Subject: [Python-mode] Error during indentation In-Reply-To: <4D7E0C6E.2010601@online.de> References: <204CDE48-55DB-47EB-B485-8C5320C28548@gmail.com> <4D7E0C6E.2010601@online.de> Message-ID: Andreas R?hler writes: > Hi Andrea, > > thanks. Have some idea meanwhile wherefrom these bug. It's in the line > above, resp. it's receiving function. > > Ironically you get this bug, because syntax setting is OK now with Emacs 24. > > AFAIS bug results, because the delimiting char of a > triple-quoted-string is no longer of 7, string quote, but of 15, > generic string. > > syntax-ppss and friends than don't send the delimiting char as > integer, but `t'. The receiving functions refuses correctly to make a > string from: > > wrong-type-argument integerp t) > > With some luck I'll send a fix next days... > > Andreas > Thanks very good I'll be glad to try the fix then :) Actually the workaround is not so bad, it's enough to write 4 spaces by hand, but it would be good to get fixed also for the future emacs24 (which by the way is very stable and looks faster). From barry at python.org Mon Mar 14 17:49:51 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 14 Mar 2011 12:49:51 -0400 Subject: [Python-mode] highlight-indentation In-Reply-To: <4D7B6AB8.6030800@online.de> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> <4D7B6AB8.6030800@online.de> Message-ID: <20110314124951.04d73e3e@neurotica> @pycon so just a quick reply... On Mar 12, 2011, at 01:44 PM, Andreas R?hler wrote: >As for the approval: thought that's precisely what the >GPL is for. Well, the GPL makes it *legal*, but approval keeps us nice. :) -B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From lists at onerussian.com Tue Mar 15 04:39:44 2011 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 14 Mar 2011 23:39:44 -0400 Subject: [Python-mode] running Python tests Message-ID: <20110315033943.GP6021@onerussian.com> Dear Python-mode gurus, could someone look into adopting at least minimalistic convenience to run unittests from within emacs? e.g. https://bitbucket.org/jpellerin/nosemacs seems to be doing its minimal job just fine -- =------------------------------------------------------------------= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic From andreas.roehler at online.de Tue Mar 15 12:42:36 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 15 Mar 2011 12:42:36 +0100 Subject: [Python-mode] running Python tests In-Reply-To: <20110315033943.GP6021@onerussian.com> References: <20110315033943.GP6021@onerussian.com> Message-ID: <4D7F50AC.1050306@online.de> Am 15.03.2011 04:39, schrieb Yaroslav Halchenko: > Dear Python-mode gurus, > > could someone look into adopting at least minimalistic convenience to > run unittests from within emacs? e.g. > > https://bitbucket.org/jpellerin/nosemacs > > seems to be doing its minimal job just fine > Hi Yaroslav, thanks pointing to it. BTW what about joining the team, make a notice as a blueprint, push up your branch, propose for merge etc? We still need a lot of stuff - reasonable auto-completion, refactoring, pydb etc. Pymacs seems broken. Definitly we should have a specification. Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From lists at onerussian.com Tue Mar 15 13:48:16 2011 From: lists at onerussian.com (Yaroslav Halchenko) Date: Tue, 15 Mar 2011 08:48:16 -0400 Subject: [Python-mode] running Python tests In-Reply-To: <4D7F50AC.1050306@online.de> References: <20110315033943.GP6021@onerussian.com> <4D7F50AC.1050306@online.de> Message-ID: <20110315124816.GX6021@onerussian.com> Hi Andreas, Thank you for the invitation -- unfortunately I am already overloaded with other projects so would not be able to provide adequate time to python-mode. Moreover my elisp knowledge is quite basic :-/ FWIW I use python-mode together with rope to get me some quick navigation facilities (haven't actually used it for refactoring ;) ) > Pymacs seems broken. With which version? I recall fixing something to make rope work back again after some not so recent upgrade -- now all seems to be fine with GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) ii pymacs 0.23-1.1 interface between Emacs Lisp and Python ii python-rope 0.9.2-1 Python refactoring library ii python-ropemacs 0.6c2-4 Emacs mode for Python refactoring On Tue, 15 Mar 2011, Andreas R?hler wrote: > thanks pointing to it. > BTW what about joining the team, make a notice as a blueprint, push > up your branch, propose for merge etc? > We still need a lot of stuff - reasonable auto-completion, > refactoring, pydb etc. > Pymacs seems broken. > Definitly we should have a specification. -- =------------------------------------------------------------------= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic From barry at python.org Tue Mar 15 17:23:45 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Mar 2011 12:23:45 -0400 Subject: [Python-mode] Fw: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added Message-ID: <20110315122345.6a39a10d@neurotica> Hi Andreas. Did you really mean to commit a directory listing as a .el file? ;) -Barry Begin forwarded message: Date: Tue, 15 Mar 2011 11:11:16 -0000 From: noreply at launchpad.net To: Barry Warsaw Subject: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added ------------------------------------------------------------ revno: 402 committer: Andreas Roehler branch nick: python-mode timestamp: Tue 2011-03-15 11:08:05 +0100 message: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added added: py-bug-numbered-tests.el -- lp:python-mode https://code.launchpad.net/~python-mode-devs/python-mode/python-mode Your team python-mode.el developers is subscribed to branch lp:python-mode. To unsubscribe from this branch go to https://code.launchpad.net/~python-mode-devs/python-mode/python-mode/+edit-subscription -------------- next part -------------- A non-text attachment was scrubbed... Name: revision-diff.txt Type: text/x-diff Size: 3391 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Tue Mar 15 19:28:55 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Tue, 15 Mar 2011 19:28:55 +0100 Subject: [Python-mode] Fw: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added In-Reply-To: <20110315122345.6a39a10d@neurotica> References: <20110315122345.6a39a10d@neurotica> Message-ID: <4D7FAFE7.8030506@online.de> Am 15.03.2011 17:23, schrieb Barry Warsaw: > Hi Andreas. Did you really mean to commit a directory listing as a .el file? > ;) > > -Barry OMG, seems something swapped over... Sorry and thanks. It's okay at my home board BTW, no magic. Just got the wrong buffer when saving. Andreas > > Begin forwarded message: > > Date: Tue, 15 Mar 2011 11:11:16 -0000 > From: noreply at launchpad.net > To: Barry Warsaw > Subject: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added > > > ------------------------------------------------------------ > revno: 402 > committer: Andreas Roehler > branch nick: python-mode > timestamp: Tue 2011-03-15 11:08:05 +0100 > message: > py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added > added: > py-bug-numbered-tests.el > > > -- > lp:python-mode > https://code.launchpad.net/~python-mode-devs/python-mode/python-mode > > Your team python-mode.el developers is subscribed to branch lp:python-mode. > To unsubscribe from this branch go to https://code.launchpad.net/~python-mode-devs/python-mode/python-mode/+edit-subscription > > > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode From andreas.roehler at online.de Tue Mar 15 19:47:44 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Tue, 15 Mar 2011 19:47:44 +0100 Subject: [Python-mode] apropos py-bug-numbered-tests Message-ID: <4D7FB450.9000207@online.de> Hi Barry, test concerning last bug report `goto-beginning-of-tqs-lp:735328-test' should go through with python-mode.el, some others too, but not all. To tackle remaining bugs, would change some lisp of python-mode.el towards more common forms. For example `py-save' now is as macro `ignore-errors' available. Also `py-point' forms IMHO rather obfuscate the code. Did see the explanation for it, but don't think it pays. Do I have green light for such a clean up? Would commit every logical step, so it should be easy to revert, should some mistake occur. Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From sesquile at gmail.com Tue Mar 15 20:37:35 2011 From: sesquile at gmail.com (m h) Date: Tue, 15 Mar 2011 13:37:35 -0600 Subject: [Python-mode] running Python tests In-Reply-To: <20110315033943.GP6021@onerussian.com> References: <20110315033943.GP6021@onerussian.com> Message-ID: On a somewhat related note, I've got a module that provides code coveraeg[0] reporting. It's somewhat functional right now, but needs a little bit of work to be more robust. One feature I'm planning to add when I get some time is a way to invoke tests for a function/class and get coverage info from that. Then while editing/changing one could quickly see if they have testing gaps. cheers, matt [0] https://github.com/mattharrison/pycoverage.el On Mon, Mar 14, 2011 at 9:39 PM, Yaroslav Halchenko wrote: > Dear Python-mode gurus, > > could someone look into adopting at least minimalistic convenience to > run unittests from within emacs? e.g. > > https://bitbucket.org/jpellerin/nosemacs > > seems to be doing its minimal job just fine > > -- > =------------------------------------------------------------------= > Keep in touch ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? www.onerussian.com > Yaroslav Halchenko ? ? ? ? ? ? ? ? www.ohloh.net/accounts/yarikoptic > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > From sesquile at gmail.com Tue Mar 15 20:41:27 2011 From: sesquile at gmail.com (m h) Date: Tue, 15 Mar 2011 13:41:27 -0600 Subject: [Python-mode] running Python tests In-Reply-To: <20110315124816.GX6021@onerussian.com> References: <20110315033943.GP6021@onerussian.com> <4D7F50AC.1050306@online.de> <20110315124816.GX6021@onerussian.com> Message-ID: On Tue, Mar 15, 2011 at 6:48 AM, Yaroslav Halchenko wrote: > Hi Andreas, > > Thank you for the invitation -- unfortunately I am already overloaded > with other projects so would not be able to provide adequate time to > python-mode. ?Moreover my elisp knowledge is quite basic :-/ > > FWIW I use python-mode together with rope to get me some quick > navigation facilities (haven't actually used it for refactoring ;) ) > >> Pymacs seems broken. The emacs-for-python and emacs-starter-kit at https://github.com/gabrielelanaro/ both seem to have good rope support out of the box and were working with python-mode.el. (I'm trying out the new python.el and it works that too). -matt From barry at python.org Tue Mar 15 21:09:24 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Mar 2011 16:09:24 -0400 Subject: [Python-mode] apropos py-bug-numbered-tests In-Reply-To: <4D7FB450.9000207@online.de> References: <4D7FB450.9000207@online.de> Message-ID: <20110315160924.7c7ffd13@neurotica> On Mar 15, 2011, at 07:47 PM, Andreas R?hler wrote: >To tackle remaining bugs, would >change some lisp of python-mode.el towards more common >forms. For example `py-save' now is as macro >`ignore-errors' available. The question is cross-Emacsen compatibility, and also compatibility with older Emacsen. E.g. how far back does ignore-errors support and does it work with XEmacs? >Also `py-point' forms IMHO rather obfuscate the code. Did >see the explanation for it, but don't think it pays. I do like py-point a lot. Code was more verbose without it, so I do think it helps, and should be pretty easy to understand. OTOH, I guess you're doing the most work on the code now, so you get to decide. However I wouldn't necessarily recommend ripping it all out (IOW, "if it ain't broke, don't fix it"). >Do I have green light for such a clean up? I'll leave it up to you, with the above caveats. >Would commit every logical step, so it should be easy to >revert, should some mistake occur. Maybe getting the tests working first would be a good idea? That way, you have some baseline to prove that your changes aren't breaking the code. What do you think? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Tue Mar 15 21:55:18 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Tue, 15 Mar 2011 21:55:18 +0100 Subject: [Python-mode] apropos py-bug-numbered-tests In-Reply-To: <20110315160924.7c7ffd13@neurotica> References: <4D7FB450.9000207@online.de> <20110315160924.7c7ffd13@neurotica> Message-ID: <4D7FD236.2060702@online.de> Am 15.03.2011 21:09, schrieb Barry Warsaw: > On Mar 15, 2011, at 07:47 PM, Andreas R?hler wrote: > >> To tackle remaining bugs, would >> change some lisp of python-mode.el towards more common >> forms. For example `py-save' now is as macro >> `ignore-errors' available. > > The question is cross-Emacsen compatibility, and also compatibility with older > Emacsen. E.g. how far back does ignore-errors support and does it work with > XEmacs? 21.5 says: `ignore-errors' is a compiled Lisp macro -- loaded from "cl-macs" (ignore-errors &rest BODY) Documentation: Execute BODY; if an error occurs, return nil. Otherwise, return result of last form in BODY. ;;; That should work. BTW in cases, XEmacs misses a form, think it's better to implement it for XE as we have done, rather than maintain python-mode specific forms. > >> Also `py-point' forms IMHO rather obfuscate the code. Did >> see the explanation for it, but don't think it pays. > > I do like py-point a lot. Sure :-) Code was more verbose without it, so I do think it > helps, and should be pretty easy to understand. OTOH, I guess you're doing > the most work on the code now, so you get to decide. However I wouldn't > necessarily recommend ripping it all out (IOW, "if it ain't broke, don't fix > it"). > >> Do I have green light for such a clean up? > > I'll leave it up to you, with the above caveats. Listen, Barry: the code is intrinsic for me to an extend, that I don't know how to fix the remaining bugs mentioned. All these bugs are absent in the components branch, because it's simplified from the scratch - more or less... Tried to backport some solution and could resolve some issues. But again and again going trapped into some wire. Obviously no one else could solve that over the years also. That's not a surprise. We are in some labyrinth, before some gordic knots. OTOH it's a pleasure for me to see solutions from different sides, python.el, components- and python-mode. So if you permit, will try to range things still. Tell if cannot bear it any longer :-) Andreas > >> Would commit every logical step, so it should be easy to >> revert, should some mistake occur. > > Maybe getting the tests working first would be a good idea? That way, you > have some baseline to prove that your changes aren't breaking the code. What > do you think? > > -Barry From barry at python.org Tue Mar 15 22:06:09 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Mar 2011 17:06:09 -0400 Subject: [Python-mode] apropos py-bug-numbered-tests In-Reply-To: <4D7FD236.2060702@online.de> References: <4D7FB450.9000207@online.de> <20110315160924.7c7ffd13@neurotica> <4D7FD236.2060702@online.de> Message-ID: <20110315170609.0d704846@neurotica> On Mar 15, 2011, at 09:55 PM, Andreas R?hler wrote: >Listen, Barry: the code is intrinsic for me to an extend, that I don't know >how to fix the remaining bugs mentioned. All these bugs are absent in the >components branch, because it's simplified from the scratch - more or less... > >Tried to backport some solution and could resolve some issues. But again and >again going trapped into some wire. > >Obviously no one else could solve that over the years also. That's not a >surprise. We are in some labyrinth, before some gordic knots. > >OTOH it's a pleasure for me to see solutions from different sides, python.el, >components- and python-mode. So if you permit, will try to range things >still. > >Tell if cannot bear it any longer :-) Do what you need to do! And remember that some code in python-mode.el is *ancient* so I'm not surprised if better and cleaner ways of doing things are now possible. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Tue Mar 15 22:21:03 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Mar 2011 17:21:03 -0400 Subject: [Python-mode] r401 is broken Message-ID: <20110315172103.347352ce@neurotica> Hi Andreas, r401 broke TAB indentation in Emacs 23. In the attached file, set the cursor at the end of line 48, then hit return and tab. Point does not indent. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: test_templates.py Type: text/x-python Size: 2309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Tue Mar 15 22:33:44 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Tue, 15 Mar 2011 22:33:44 +0100 Subject: [Python-mode] r401 is broken In-Reply-To: <20110315172103.347352ce@neurotica> References: <20110315172103.347352ce@neurotica> Message-ID: <4D7FDB38.4070501@online.de> Am 15.03.2011 22:21, schrieb Barry Warsaw: > Hi Andreas, > > r401 broke TAB indentation in Emacs 23. In the attached file, set the cursor > at the end of line 48, then hit return and tab. Point does not indent. > > Cheers, > -Barry > > there was a typo, done now. Will see again tomorrow. From andreas.roehler at online.de Thu Mar 17 15:47:15 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Thu, 17 Mar 2011 15:47:15 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <1F62368C-3EDD-440E-A445-2031F224F82A@gmail.com> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> <4D7C7D0F.2030304@online.de> <1F62368C-3EDD-440E-A445-2031F224F82A@gmail.com> Message-ID: <4D821EF3.4050108@online.de> Am 14.03.2011 10:04, schrieb Anton Johansson: > Hi, if you can forward bug tracking automatically, please do, Hi, launchpad sends notifications once a bug is tracked there. Must be registered, which goes smoothly, no special requirings. With an lp account I may subscribe to related bugs. Also you may subscribe yourself to what matter whatever and do some other funny things. Beside bug-tracking feature-request may be tracked. Blue-prints are for that AFAIU. Than it has Milestones where ToDo's might be listed and Releases prepared. highlight-indentation integration could be part of a milestone for example. So far best regards, Andreas otherwise it's ok don't overwork it :) Also the full functionality of highlight-indentation is basically: > > (setq highlight-indent-offset 4) ;; Spaces indent level > (font-lock-add-keywords nil `((,(format "\\( \\) \\{%s\\}" (- highlight-indent-offset 1)) (1 'highlight-indent-face)))) > > so if you find a better place to extract that to syntax highlighting code it might be better... > > Cheers > -- Anton > > On Mar 13, 2011, at 09:15 , Andreas R?hler wrote: > >> Hi Anton, >> >> thanks a lot BTW. >> >> Added a link onto your repo into the header. >> >> In order to get a wider audience with resp. to other modes an entry >> at >> >> http://www.emacswiki.org/emacs-en >> >> might be useful. >> >> >> As for bug-tracking think we should forward any report to you, if it concerns your file(s). OTOH would not charge the users which such specific requests. >> >> Agreed? >> >> Thanks again. >> >> >> Andreas >> >> -- >> https://code.launchpad.net/~a-roehler/python-mode/python-mode-components >> https://code.launchpad.net/s-x-emacs-werkstatt/ >> >> >> >> >> Am 12.03.2011 11:38, schrieb Anton Johansson: >>> Hello, >>> >>> I'm absolutely cool with you guys using the code in any way you find >>> suitable, nice to see some people finding it useful! >>> >>> Like you have discussed before, there are some issues with >>> highlight-indentation.el that could be handled better, for example >>> highlighting spaces that are not in the leading whitespace. If you can >>> find a good way to link to my repo so that people can submit possible >>> fixes that would be good since the code is also usable in other modes. >>> >>> Cheers >>> -Anton >>> >>> On Sat, Mar 12, 2011 at 4:28 AM, Barry Warsaw wrote: >>>> Hi Andreas, >>>> >>>> I noticed that you committed this file to our bzr tree. I'm concerned about >>>> doing this without Anton's approval (and maybe even with it). Anton probably >>>> has his own source code repository, so at the very least it would be more >>>> effort for us to keep our copy up-to-date with his. python-mode.el doesn't >>>> depend on his code, so it's really not necessary for us to have a copy in our >>>> tree. >>>> >>>> As cool as Anton's module is, and it definitely could help Python programmers, >>>> it's probably a better idea to add a reference to his work (and his download >>>> site or source repository) in our README file or in the comments at the top of >>>> python-mode.el. >>>> >>>> If Anton really wants us to keep the canonical version of his mode in our bzr >>>> tree, we could discuss that. Anton, what do you think? >>>> >>>> Cheers, >>>> -Barry >>>> >>> >> > > From andreas.roehler at online.de Fri Mar 25 09:51:57 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Fri, 25 Mar 2011 09:51:57 +0100 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements Message-ID: <4D8C57AD.2050208@online.de> Hi Barry, hi all, while considering the request valid, even if the current non-indent is an option, what's the recommendable indent? Would not choose the block-indent step, rather signal it's something different at stake. What about indenting it to the end of first element of previous line? ;;;;;;;;;;; (longer, sequence, of_items, that, needs, to_be, wrapped) = input_list packed_entry = (long, sequence, of_items, that, needs, to_be, wrapped) ;;;;;;;;;; Would introduce two boolean variables py-multiline-assignement-first-column: "If a multiline-assignement element in first-column should be indented" py-multiline-indent-to-first-element: "If a multiline-assignement in first-column should be indented to the end of it's first element. " Also: (defcustom py-indent-in-delimiter 1 "When inside a multiline-assignement: How many colums indent should be more than opening bracket, brace or parenthesis. " :type 'integer :group 'python) (make-variable-buffer-local 'py-indent-in-delimiter) Cheers From andreas.roehler at online.de Fri Mar 25 11:02:05 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 25 Mar 2011 11:02:05 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <20110314124951.04d73e3e@neurotica> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> <4D7B6AB8.6030800@online.de> <20110314124951.04d73e3e@neurotica> Message-ID: <4D8C681D.4080904@online.de> Am 14.03.2011 17:49, schrieb Barry Warsaw: > @pycon so just a quick reply... > > On Mar 12, 2011, at 01:44 PM, Andreas R?hler wrote: > >> As for the approval: thought that's precisely what the >> GPL is for. > > Well, the GPL makes it *legal*, but approval keeps us nice. :) > > -B Hi Barry, makes me some headache, will see if I'm able to explain the --in the precise case purely abstract-- reasons: First at the GPL: its often blamed and disputed and has some quirks. But seen from the world outside it provides indeed some miraculous, which you may call freedom. BTW I'm not going to relate it to other licences providing free software, just the phenomen Emacs and GPL at stake here. GPL just works, it provides permissions to use, change, distribute etc. Lets further assume any person publishing code under GPL knows what it's doing. If not, we should not try to fix that by extra personal permissions handed over, but by teaching the meaning of the GPL. OTOH if someone is going to state obvious things, these statements change its meaning. Same when asking questions already answered. The danger here is raising wrong expectations. If you ask for a use, did you ask for a permission to change too? What, if the author later changes it's mind? Will you pull the code than out again? See diskussions lately around python.el, what kind of difficulties may arise, when confidence in GPL should not be enough. Nonetheless always trying to be as polite as my habits permit... :-) Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From skip at pobox.com Fri Mar 25 14:07:08 2011 From: skip at pobox.com (skip at pobox.com) Date: Fri, 25 Mar 2011 08:07:08 -0500 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <4D8C57AD.2050208@online.de> References: <4D8C57AD.2050208@online.de> Message-ID: <19852.37756.356308.174624@montanaro.dyndns.org> Andreas> What about indenting it to the end of first element of previous Andreas> line? That is precisely the problem. That's what it does today, and if the lhs of the assignment is a complex expression, the continuation is indented way too far. I would much prefer just to simply indent by the normal block indent. Skip From andreas.roehler at online.de Fri Mar 25 14:35:43 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Mar 2011 14:35:43 +0100 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <19852.37756.356308.174624@montanaro.dyndns.org> References: <4D8C57AD.2050208@online.de> <19852.37756.356308.174624@montanaro.dyndns.org> Message-ID: <4D8C9A2F.5000205@online.de> Am 25.03.2011 14:07, schrieb skip at pobox.com: > > Andreas> What about indenting it to the end of first element of previous > Andreas> line? > > That is precisely the problem. That's what it does today, and if the lhs of > the assignment is a complex expression, the continuation is indented way too > far. I would much prefer just to simply indent by the normal block indent. > > Skip > Hi Skip, I'll introduce a defcustom for that just set `py-multiline-indent-to-first-element' --or however it will be called finally-- onto the value you prefer. Default will be 2 probably, just my taste, but that may change. :-) Andreas From andreas.roehler at online.de Fri Mar 25 15:01:28 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Mar 2011 15:01:28 +0100 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <4D8C9A2F.5000205@online.de> References: <4D8C57AD.2050208@online.de> <19852.37756.356308.174624@montanaro.dyndns.org> <4D8C9A2F.5000205@online.de> Message-ID: <4D8CA038.4020506@online.de> Am 25.03.2011 14:35, schrieb Andreas R?hler: > Am 25.03.2011 14:07, schrieb skip at pobox.com: >> >> Andreas> What about indenting it to the end of first element of previous >> Andreas> line? >> >> That is precisely the problem. That's what it does today, and if the >> lhs of >> the assignment is a complex expression, the continuation is indented >> way too >> far. I would much prefer just to simply indent by the normal block >> indent. >> >> Skip >> > > Hi Skip, > > I'll introduce a defcustom for that > > just set > > `py-multiline-indent-to-first-element' > Sorry, that's my mistake. Thats will be boolean, as it's name says. When indenting to common indent-offset, use the defcustom than created for that purpose. `py-multiline-indent-to-first-element' must be nil than, as the indent of the first element shouldn't matter. Andreas From barry at python.org Fri Mar 25 16:08:25 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Mar 2011 11:08:25 -0400 Subject: [Python-mode] highlight-indentation In-Reply-To: <4D8C681D.4080904@online.de> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> <4D7B6AB8.6030800@online.de> <20110314124951.04d73e3e@neurotica> <4D8C681D.4080904@online.de> Message-ID: <20110325110825.26cc52c6@neurotica.wooz.org> Hi Andreas, I don't disagree with anything you wrote, and of course we're allowed to use anything GPL'd. I don't think even politeness mandates pre-approval in order to *use* GPL code. The "let's be nice" comment wasn't directed at you personally, or really anybody here - I think we're all being nice, helpful, and polite, which to me is one of the most important principles of FLOSS. :) It also wasn't a comment on our use of GPL code. It was related to our bringing in a copy of someone else's file, which is already under their own VCS, into our VCS. Doing so could give the impression that we're the authoritative copy of the file. I wouldn't want to usurp someone else's authority on that without their approval. I hope that makes sense. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Fri Mar 25 16:54:08 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Mar 2011 11:54:08 -0400 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <4D8C57AD.2050208@online.de> References: <4D8C57AD.2050208@online.de> Message-ID: <20110325115408.70ced387@neurotica.wooz.org> On Mar 25, 2011, at 09:51 AM, Andreas R?hler wrote: >while considering the request valid, even if the current >non-indent is an option, > >what's the recommendable indent? > >Would not choose the block-indent step, rather signal >it's something different at stake. > >What about indenting it to the end of first element of >previous line? > >;;;;;;;;;;; >(longer, sequence, of_items, > that, needs, to_be, wrapped) = input_list > >packed_entry = (long, sequence, of_items, > that, needs, to_be, wrapped) >;;;;;;;;;; I must be missing something because these two snippets get indented like this for me, running r405: -----snip snip----- (longer, sequence, of_items, that, needs, to_be, wrapped) = input_list packed_entry = (long, sequence, of_items, that, needs, to_be, wrapped) -----snip snip----- which seems exactly right to me! If you do introduce a variable to control this, please do retain the current behavior as default. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From skip at pobox.com Fri Mar 25 19:44:55 2011 From: skip at pobox.com (skip at pobox.com) Date: Fri, 25 Mar 2011 13:44:55 -0500 Subject: [Python-mode] highlight-indentation Message-ID: <19852.58023.591507.711055@montanaro.dyndns.org> I agree wholeheartedly with Barry's previous message on the indentation topic. Let me provide you with an analogy from a totally different realm. If I take the dog out in the evening for a bathroom walk, I doubt that I really need to tell my wife. After all, it's part of my nightly routine to walk Lily before coming up to bed. There is no signed contract which dictates that I tell her I'm walking the dog. If Ellen happens to come downstairs she will notice the absence of me, the dog and the leash, and not jump to the conclusion that a neighbor has snuck in to walk the dog while I've flown off to the Caribbean with some floozy (or gone "hiking in the Appalachians" as a certain former politician from South Carolina did). Still, as I head out the door, I let her know that Lily and I will be back in a few minutes. It's just the nice thing to do. Skip From andreas.roehler at online.de Fri Mar 25 20:11:18 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Mar 2011 20:11:18 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <20110325110825.26cc52c6@neurotica.wooz.org> References: <4D77F01F.8030201@online.de> <20110311074754.3f5b3840@neurotica> <4D7A5C4F.7050208@online.de> <20110311222858.37857a7f@neurotica> <4D7B6AB8.6030800@online.de> <20110314124951.04d73e3e@neurotica> <4D8C681D.4080904@online.de> <20110325110825.26cc52c6@neurotica.wooz.org> Message-ID: <4D8CE8D6.3080708@online.de> Am 25.03.2011 16:08, schrieb Barry Warsaw: > Hi Andreas, > > I don't disagree with anything you wrote, and of course we're allowed to use > anything GPL'd. I don't think even politeness mandates pre-approval in order > to *use* GPL code. > > The "let's be nice" comment wasn't directed at you personally, or really > anybody here - I think we're all being nice, helpful, and polite, which to me > is one of the most important principles of FLOSS. :) > > It also wasn't a comment on our use of GPL code. It was related to our > bringing in a copy of someone else's file, which is already under their own > VCS, into our VCS. Doing so could give the impression that we're the > authoritative copy of the file. I wouldn't want to usurp someone else's > authority on that without their approval. > > I hope that makes sense. Me too :-) Somehow the VCS seems at stake now. Okay, let's go on. Thanks and sorry should I have provoked too much writing. Let's go into another turn. Andreas > > Cheers, > -Barry From andreas.roehler at online.de Fri Mar 25 20:58:22 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 25 Mar 2011 20:58:22 +0100 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <20110325115408.70ced387@neurotica.wooz.org> References: <4D8C57AD.2050208@online.de> <20110325115408.70ced387@neurotica.wooz.org> Message-ID: <4D8CF3DE.2060502@online.de> Am 25.03.2011 16:54, schrieb Barry Warsaw: > On Mar 25, 2011, at 09:51 AM, Andreas R?hler wrote: > >> while considering the request valid, even if the current >> non-indent is an option, >> >> what's the recommendable indent? >> >> Would not choose the block-indent step, rather signal >> it's something different at stake. >> >> What about indenting it to the end of first element of >> previous line? >> >> ;;;;;;;;;;; >> (longer, sequence, of_items, >> that, needs, to_be, wrapped) = input_list >> >> packed_entry = (long, sequence, of_items, >> that, needs, to_be, wrapped) >> ;;;;;;;;;; > > I must be missing something because these two snippets get indented like this > for me, running r405: > > -----snip snip----- > (longer, sequence, of_items, > that, needs, to_be, wrapped) = input_list > > packed_entry = (long, sequence, of_items, > that, needs, to_be, wrapped) > -----snip snip----- > > which seems exactly right to me! Noticed. As different styles are possible, think we can deliver what has been requested for. > > If you do introduce a variable to control this, please do retain the current > behavior as default. Okay. Would help having an appropriate name for these indents. What about calling the first an `left-inbound indent' --default will be 1--, the second `right-inbound-indent' --default will be (1+ column of opening parentesis)-- > > Cheers, > -Barry From andreas.roehler at online.de Fri Mar 25 22:20:02 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Mar 2011 22:20:02 +0100 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <19852.57296.784656.603762@montanaro.dyndns.org> References: <4D8C57AD.2050208@online.de> <20110325115408.70ced387@neurotica.wooz.org> <19852.57296.784656.603762@montanaro.dyndns.org> Message-ID: <4D8D0702.7040400@online.de> Am 25.03.2011 19:32, schrieb skip at pobox.com: > I find this indentation truly grating: > > self.last_abc_attr = self.last_xyz_attr = \ > self.last_abc_other = \ > self.last_xyz_other = None > > Now, I can move self.last_xyz_attr to a continuation line, but though the > result is slightly different, it is, in my opinion, just as bad: > > self.last_abc_attr = \ > self.last_xyz_attr = \ > self.last_abc_other = \ > self.last_xyz_other = None > > What I would like to see is this (given a four-space block indent): > > self.last_abc_attr = \ > self.last_xyz_attr = \ > self.last_abc_other = \ > self.last_xyz_other = None > > or, if the second expression remained on the first line: > > self.last_abc_attr = self.last_xyz_attr = \ > self.last_abc_other = \ > self.last_xyz_other = None > > I don't care if this behavior is the default. I just want to be able to > control it. Currently, I have to manually format lines like this, and if > I'm not careful and reindent an entire function or file, then python-mode > undoes my work. > > Skip > Hi Skip, think that may be done. As it's a different thing though than indenting inside tuples, lists etc., would you mind making a bug entry giving your last examples? Andreas From barry at python.org Fri Mar 25 22:14:24 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Mar 2011 17:14:24 -0400 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <4D8CF3DE.2060502@online.de> References: <4D8C57AD.2050208@online.de> <20110325115408.70ced387@neurotica.wooz.org> <4D8CF3DE.2060502@online.de> Message-ID: <20110325171424.61c8acf0@neurotica.wooz.org> On Mar 25, 2011, at 08:58 PM, Andreas R?hler wrote: >> -----snip snip----- >> (longer, sequence, of_items, >> that, needs, to_be, wrapped) = input_list >> >> packed_entry = (long, sequence, of_items, >> that, needs, to_be, wrapped) >> -----snip snip----- >What about calling the first an `left-inbound indent' --default will be 1--, >the second `right-inbound-indent' --default will be (1+ column of opening >parentesis)-- Those names seem pretty good to me. I would make both of them default to column_of_first_nonwhitespace_after_paren. E.g. ( one, two, three, four, five, six ) = things and ( one, two, three) = things Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From skip at pobox.com Fri Mar 25 23:25:49 2011 From: skip at pobox.com (skip at pobox.com) Date: Fri, 25 Mar 2011 17:25:49 -0500 Subject: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements In-Reply-To: <4D8D0702.7040400@online.de> References: <4D8C57AD.2050208@online.de> <20110325115408.70ced387@neurotica.wooz.org> <19852.57296.784656.603762@montanaro.dyndns.org> <4D8D0702.7040400@online.de> Message-ID: <19853.5741.284771.104311@montanaro.dyndns.org> Andreas> As it's a different thing though than indenting inside tuples, Andreas> lists etc., would you mind making a bug entry giving your last Andreas> examples? This bug is close enough: https://bugs.launchpad.net/python-mode/+bug/629916 I just added a comment. Skip From andreas.roehler at online.de Sat Mar 26 19:08:29 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Sat, 26 Mar 2011 19:08:29 +0100 Subject: [Python-mode] myrkwid ready to merge? Message-ID: <4D8E2B9D.4020808@online.de> Hi Barry, AFAIS all indent-bugs reported are done with Myrkwid branch. Provided tests from inside Emacs for it: py-bug-numbered-tests.el Also tests may be run in batch-mode: python-mode-tests.sh Please have a look if it's ready: https://code.launchpad.net/~a-roehler/python-mode/myrkwid The core is re-written, so would not merge without your consent. API however should be unchanged, beside some extra delivered. Functions moving point are designed around `py-beginning-of-statement', `py-end-of-statement' with `py-travel-current-indent' stepping downwards. Also `py-compute-indentation' redone. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From david at deadpansincerity.com Mon Mar 28 16:41:28 2011 From: david at deadpansincerity.com (David Miller) Date: Mon, 28 Mar 2011 15:41:28 +0100 Subject: [Python-mode] Python mode decorators-face Message-ID: Hi - I frequently use decorators from libraries named like: @patch.object(Foo, 'bar') def func(arg): # etc The regex for py-decorators-face only matches the patch section, leaving the object part set to the default face ( M-x describe-face => Face: default) To my eye this looks like the wrong highlighting, was wondering if this was considered a feature or a bug :) The alteration to the regex is dead simple, was wondering if I should go through the launchpad bug-report - patch cycle or just continue to override it my end? Love regards etc David Miller http://www.deadpansincerity.com 07854 880 883 -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Mon Mar 28 16:51:00 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 28 Mar 2011 10:51:00 -0400 Subject: [Python-mode] Python mode decorators-face In-Reply-To: References: Message-ID: <20110328105100.5da4298b@neurotica.wooz.org> On Mar 28, 2011, at 03:41 PM, David Miller wrote: >I frequently use decorators from libraries named like: > >@patch.object(Foo, 'bar') >def func(arg): > # etc > >The regex for py-decorators-face only matches the patch section, leaving the >object part set to the default face ( M-x describe-face => Face: default) > >To my eye this looks like the wrong highlighting, was wondering if this was >considered a feature or a bug :) The fact that Foo and 'bar' are not in decorator face is a feature, but the fact that @patch.object (and perhaps the parentheses) is not is a bug, IMO. >The alteration to the regex is dead simple, was wondering if I should go >through the launchpad bug-report - patch cycle or just continue to override >it my end? Please do submit a bug report! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Mon Mar 28 16:55:41 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 28 Mar 2011 10:55:41 -0400 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <4D8E2B9D.4020808@online.de> References: <4D8E2B9D.4020808@online.de> Message-ID: <20110328105541.1c69a917@neurotica.wooz.org> On Mar 26, 2011, at 07:08 PM, Andreas R?hler wrote: >AFAIS all indent-bugs reported are done with Myrkwid branch. > >Provided tests from inside Emacs for it: py-bug-numbered-tests.el > >Also tests may be run in batch-mode: python-mode-tests.sh > >Please have a look if it's ready: > >https://code.launchpad.net/~a-roehler/python-mode/myrkwid The diff is pretty big, but I'll try to find some time to review the python-mode.el parts. In the meantime, I'll grab your branch and use it for a few days. Before it gets merged, I think Skip should definitely do the same to test for XEmacs compatibility. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Mon Mar 28 17:34:15 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 28 Mar 2011 11:34:15 -0400 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <4D8E2B9D.4020808@online.de> References: <4D8E2B9D.4020808@online.de> Message-ID: <20110328113415.11e118cb@neurotica.wooz.org> One other thing I noticed is that both branches are of the old bzr format. I'd like to upgrade trunk to 2a format, which I can do via the Launchpad web u/i, but if I do that, all other branches you have (either on Launchpad or locally) will also have to be upgraded. Since you've got the big myrkwid branch waiting to get merged, let's do the branch format updates after that lands. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Mon Mar 28 21:15:33 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Mon, 28 Mar 2011 21:15:33 +0200 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <20110328105541.1c69a917@neurotica.wooz.org> References: <4D8E2B9D.4020808@online.de> <20110328105541.1c69a917@neurotica.wooz.org> Message-ID: <4D90DE55.4060009@online.de> Am 28.03.2011 16:55, schrieb Barry Warsaw: > On Mar 26, 2011, at 07:08 PM, Andreas R?hler wrote: > >> AFAIS all indent-bugs reported are done with Myrkwid branch. >> >> Provided tests from inside Emacs for it: py-bug-numbered-tests.el >> >> Also tests may be run in batch-mode: python-mode-tests.sh >> >> Please have a look if it's ready: >> >> https://code.launchpad.net/~a-roehler/python-mode/myrkwid > > The diff is pretty big, but I'll try to find some time to review the > python-mode.el parts. its just the move-, mark parts which have changed. The diff is confusing. In the meantime, I'll grab your branch and use it for a > few days. Before it gets merged, I think Skip should definitely do the same > to test for XEmacs compatibility. If XEmacs tqs-syntax is still broken, he will not have more fun than with the trunk. XEmacs users for now should be best off with components branch. Might remain some dependencies still to solve, but the basics for non-pps parsing are available. Should Skip report XEmacs related bugs of components branch, I'm ready to implement the missing parts - cc to him. Cheers > > Cheers, > -Barry From barry at python.org Tue Mar 29 20:36:48 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 29 Mar 2011 14:36:48 -0400 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <4D90DE55.4060009@online.de> References: <4D8E2B9D.4020808@online.de> <20110328105541.1c69a917@neurotica.wooz.org> <4D90DE55.4060009@online.de> Message-ID: <20110329143648.7c7b6980@neurotica.wooz.org> Andreas, when I find problems with the myrkwid branch, do you want me to mention them here or submit bug reports? Here's the first problem I've noticed. Open up Python 3.3's setup.py (i.e. on the mercurial default branch). Go to the end of line 371, which is on the return statement (last line) of the get_platform() method. Hit return. This puts you on a new line, but at column 12. The first problem is that that should really indent to column 4 because of the preceding return statement. Now that you're in col 12, hit delete or backspace. This should move the indentation back one level each time, but instead it doesn't move at all, although you do get a message in the echo. Gotta fix that before it's merged to trunk! ;) Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Tue Mar 29 20:45:19 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 29 Mar 2011 14:45:19 -0400 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <20110329143648.7c7b6980@neurotica.wooz.org> References: <4D8E2B9D.4020808@online.de> <20110328105541.1c69a917@neurotica.wooz.org> <4D90DE55.4060009@online.de> <20110329143648.7c7b6980@neurotica.wooz.org> Message-ID: <20110329144519.52574af0@neurotica.wooz.org> On Mar 29, 2011, at 02:36 PM, Barry Warsaw wrote: >Andreas, when I find problems with the myrkwid branch, do you want me to >mention them here or submit bug reports? Here's the first problem I've >noticed. > >Open up Python 3.3's setup.py (i.e. on the mercurial default branch). Go to >the end of line 371, which is on the return statement (last line) of the >get_platform() method. Hit return. This puts you on a new line, but at >column 12. The first problem is that that should really indent to column 4 >because of the preceding return statement. > >Now that you're in col 12, hit delete or backspace. This should move the >indentation back one level each time, but instead it doesn't move at all, >although you do get a message in the echo. I'll note this is also broken in the trunk, but in a different way. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Tue Mar 29 22:00:34 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 29 Mar 2011 22:00:34 +0200 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <20110329143648.7c7b6980@neurotica.wooz.org> References: <4D8E2B9D.4020808@online.de> <20110328105541.1c69a917@neurotica.wooz.org> <4D90DE55.4060009@online.de> <20110329143648.7c7b6980@neurotica.wooz.org> Message-ID: <4D923A62.70605@online.de> Am 29.03.2011 20:36, schrieb Barry Warsaw: > Andreas, when I find problems with the myrkwid branch, do you want me to > mention them here or submit bug reports? Here's the first problem I've > noticed. > > Open up Python 3.3's setup.py (i.e. on the mercurial default branch). Go to > the end of line 371, which is on the return statement (last line) of the > get_platform() method. Hit return. This puts you on a new line, but at > column 12. The first problem is that that should really indent to column 4 > because of the preceding return statement. See it. Added a bug-report. Thanks again. Andreas > > Now that you're in col 12, hit delete or backspace. This should move the > indentation back one level each time, but instead it doesn't move at all, > although you do get a message in the echo. > > Gotta fix that before it's merged to trunk! ;) > > Cheers, > -Barry > From andreas.roehler at online.de Wed Mar 30 16:10:11 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Wed, 30 Mar 2011 16:10:11 +0200 Subject: [Python-mode] python.el cleanup In-Reply-To: <86pqp971rz.fsf@gmail.com> References: <86ipv28xk5.fsf@gmail.com> <86pqp971rz.fsf@gmail.com> Message-ID: <4D9339C3.7070104@online.de> Am 30.03.2011 04:58, schrieb Christoph Scholtes: > Stefan Monnier writes: > >> Could you just clarify why they're considered obsolete (e.g. what would >> the user use instead)? > > `python-shell' is not needed since Dave's mode already had > 'run-python' to invoke the python interpreter. It offers no advantages > over run-python as far as I can tell except being able to toggle > between a Python and a Jython shell (see below for comments on that). > > `python-comint-filter-function' is only called from `python-shell'. > > `python-file-queue' is never populated anywhere, only read from > `python-comint filter-function'. > > `python-default-interpreter' is only used by `python-shell' and not, > as advertised in its documentation, on first visiting a Python mode > buffer. > > `python-python-command-args' and `python-jython-command-args' are only > used in the `python-toggle-shell' function. > > `python-which-shell', `python-which-args' and `python-which-bufname' > are used for toggling between the Python and Jython shell. > > Finally, `python-toggle-shell'. I think, that we should provide a better > solution for this and therefore remove the current implementation. This > code came from python-mode.el, if I traced that back right. Hi Christoph, glad to see Emacs python facilities improve. As you mention python-mode.el, there are some remarks in python.el which I feel are not correct. If some solution predates historically another, there are usually some setbacks from being the first. OTOH from my perspective python-mode.el has still some point in proceding. Hopefully we may discuss the pro and cons to the benefit of users, which flavour they may choose finally. As you might have been remarked, its interwoven to an extend, you can seldom discern it clearly to the one or other origin. BTW I'm not blaming the GNU's side. Just wanted to point at the issue so we might hopefully reduce the obstacles. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ > > Python interpreter selection should be universal and not only support Jython > and CPython, but also IronPyton, PyPy etc. I would like to implement a > better solution for this as soon as Fabian's changes are installed. I am > using IronPython quite a bit and it would be nice to be able to switch > flexibly between different interpreters. > > Christoph > > From barry at python.org Wed Mar 30 20:48:11 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 30 Mar 2011 14:48:11 -0400 Subject: [Python-mode] python.el cleanup In-Reply-To: <4D9339C3.7070104@online.de> References: <86ipv28xk5.fsf@gmail.com> <86pqp971rz.fsf@gmail.com> <4D9339C3.7070104@online.de> Message-ID: <20110330144811.5265e60d@neurotica.wooz.org> Thanks for CC'ing me. I'm now subscribed to emacs-devel via Gmane. On Mar 30, 2011, at 04:10 PM, Andreas R?hler wrote: >glad to see Emacs python facilities improve. As you mention python-mode.el, >there are some remarks in python.el which I feel are not correct. If some >solution predates historically another, there are usually some setbacks from >being the first. OTOH from my perspective python-mode.el has still some >point in proceding. Hopefully we may discuss the pro and cons to the benefit >of users, which flavour they may choose finally. Yes, let's please try to converge Python support in Emacs as much as possible. I've heard there are now 4 Python modes, which if true, is really not helping users. All history aside, I applaud efforts to find ways to consolidate the modes, keeping in mind the features and behavior users find important from each of the flavors. Andreas is doing the majority of the work on python-mode.el these days, and we have a vibrant community on python-mode at python.org and an active project on Launchpad. I personally am much more of a user than developer these days (too busy with other things Pythonic), but by no means the only person using python-mode.el. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Thu Mar 31 11:56:01 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Thu, 31 Mar 2011 11:56:01 +0200 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <20110329143648.7c7b6980@neurotica.wooz.org> References: <4D8E2B9D.4020808@online.de> <20110328105541.1c69a917@neurotica.wooz.org> <4D90DE55.4060009@online.de> <20110329143648.7c7b6980@neurotica.wooz.org> Message-ID: <4D944FB1.3050801@online.de> [ ... ] Hi Barry, added still another python-mode-test.el, running test-cases independently from bugs reported: `py-run-tests' does for now 'py-beginning-of-block-test 'py-end-of-block-test 'py-beginning-of-block-or-clause-test 'py-end-of-block-or-clause-test 'py-beginning-of-def-test 'py-end-of-def-test 'py-beginning-of-def-or-class-test 'py-end-of-def-or-class-test Please tell, if there are cases you want to see. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Thu Mar 31 14:47:10 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 31 Mar 2011 08:47:10 -0400 Subject: [Python-mode] myrkwid ready to merge? In-Reply-To: <4D944FB1.3050801@online.de> References: <4D8E2B9D.4020808@online.de> <20110328105541.1c69a917@neurotica.wooz.org> <4D90DE55.4060009@online.de> <20110329143648.7c7b6980@neurotica.wooz.org> <4D944FB1.3050801@online.de> Message-ID: <20110331084710.3134a03f@neurotica.wooz.org> On Mar 31, 2011, at 11:56 AM, Andreas R?hler wrote: >added still another python-mode-test.el, running >test-cases independently from bugs reported: > >`py-run-tests' does for now > > 'py-beginning-of-block-test > 'py-end-of-block-test > 'py-beginning-of-block-or-clause-test > 'py-end-of-block-or-clause-test > 'py-beginning-of-def-test > 'py-end-of-def-test > 'py-beginning-of-def-or-class-test > 'py-end-of-def-or-class-test > >Please tell, if there are cases you want to see. Cool, thanks. I've updated this and re-enabled it locally, so I'll play with it for the next few days. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Thu Mar 31 17:36:07 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 31 Mar 2011 11:36:07 -0400 Subject: [Python-mode] myrkwid bug with backspace/delete Message-ID: <20110331113607.2c978d84@neurotica.wooz.org> Hi Andreas, myrkwid branch still has a minor problem. -----snip snip----- class Foo: def foo(self): pass -----snip snip----- Put point at the end of the 'pass' line. Hit return. Indentation is correct. However backspace/delete never moves. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andreas.roehler at online.de Thu Mar 31 21:36:48 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Thu, 31 Mar 2011 21:36:48 +0200 Subject: [Python-mode] myrkwid bug with backspace/delete In-Reply-To: <20110331113607.2c978d84@neurotica.wooz.org> References: <20110331113607.2c978d84@neurotica.wooz.org> Message-ID: <4D94D7D0.5010609@online.de> Am 31.03.2011 17:36, schrieb Barry Warsaw: > Hi Andreas, > > myrkwid branch still has a minor problem. > > -----snip snip----- > class Foo: > def foo(self): > pass > -----snip snip----- > > Put point at the end of the 'pass' line. > > Hit return. Indentation is correct. However backspace/delete never moves. > > Cheers, > -Barry > Thanks, erorr is in py-electric-backspace. Will re-write and simplify it to "Delete preceding character or level of indentation. With arg do it arg times." Unless you object.. :) Cheers Andreas