From andreas.roehler at online.de Wed Sep 4 08:14:10 2013 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Wed, 04 Sep 2013 08:14:10 +0200 Subject: [Python-mode] python-mode.el 6.1.2 released Message-ID: <5226CFB2.5070604@online.de> Hi all, finally it's out here: https://launchpad.net/python-mode/trunk/6.1.2/+download/python-mode.el-6.1.2.tar.gz Error messages now point to source even if just a statement in some buffer was executed. Menu is simplified again. - `py-execute-...'-commands return result as string Controlled by boolean `py-store-result-p', Default is nil When non-nil, put resulting string of `py-execute-...' into kill-ring, so it might be yanked. - `py-set-pager-cat-p', default is nil If non-nil, $PAGER is set to 'cat' Makes a nicer output, avoids "Terminal not fully functional" errors. - commands deleting all commented lines: `py-delete-comments-in-def-or-class' `py-delete-comments-in-class' `py-delete-comments-in-block' `py-delete-comments-in-region' - boolean `py-indent-paren-spanned-multilines-p, default is nil If non-nil, indents elements of list a value of `py-indent-offset' to first element: def foo(): if (foo && baz): bar() Default lines up with first element: def foo(): if (foo && baz): bar() - `py-output-buffer' made customizable See boolean `py-enforce-output-buffer-p' - command `py-empty-out-list-backward' Deletes all elements from list before point With when cursor after mystring[0:1] -------------^ ==> mystring[] ---------^ In result cursor is insided emptied delimited form." - `py-minor-expression' reconsidered, numeric args dropped grasps keyword-arguments - boolean `py-electric-kill-backward-p', default is nil. If behind a delimited form of braces, brackets or parentheses, `py-electric-backspace' runs `py-empty-out-list-backward' - py-flakes8-run, flakes8 API - customizable `py-backslashed-lines-indent-offset' - boolean `py-pylint-offer-current-p' If current buffers file should be offered for check. Otherwise `py-pylint-run' looks up filename from history - boolean `py-prompt-on-changed-p' When called interactively, ask for save before a changed buffer is sent to interpreter. - customizable `py-closing-list-space' Number of chars, closing parenthesis outdent from opening - customizable `py-uncomment-indents-p' When non-nil, after uncomment indent lines. - boolean `py-load-skeletons-p' If skeleton definitions should be loaded - boolean `py-if-name-main-permission-p' Allows execution of code inside blocks started by if __name__== '__main__' - boolean `py-highlight-error-source-p', default is nil When py-execute-... commands raise an error, respective code in source-buffer will be highlighted. - `py-remove-overlays-at-point', command Remove overlays as set when `py-highlight-error-source-p' is non-nil. - `py-which-def-or-class', command, now used `which-function-mode' - unused variable `py-backspace-function' removed - Bundled third-party-stuff removed as reported conflicting at emacs-mirror, lp:1153998 affects autopair.el, smart-operator.el Kept menu switches resp. commands will issue a warning - dropped `py-paragraph-fill-docstring-p'; just `fill-paragraph' should DTRT Enjoy! Andreas From andreas.roehler at online.de Mon Sep 23 21:57:30 2013 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Mon, 23 Sep 2013 21:57:30 +0200 Subject: [Python-mode] edit-style considering empty line Message-ID: <52409D2A.8090408@online.de> Hi Barry, hi all, there was an expample at http://stackoverflow.com/questions/18940719/python-indentation-with-emacs/18940836#18940836 if 1 < 2: print("this line is part of the if statement") print("this is NOT part of the if statement") The OP wanted the Editor intends the second "print" to column 0. IMO it's possibly establishing an edit rule saying: if an empty line follows a block, consider this block closed. Now seeing the example below at http://pyvideo.org/video/1708/distributed-coordination-with-python def find(seq, target): for i, value in enumerate(seq): if value == tgt: break else: return -1 return i If an empty line after "break" is inserted: def find(seq, target): for i, value in enumerate(seq): if value == tgt: break else: return -1 return i That would allow to calulate the "else:" to column 4 right away. Also for me it's slightly better readable. Question: Would you welcome such an edit-style or rather discourage? Thanks, Andreas From deets at web.de Tue Sep 24 08:45:23 2013 From: deets at web.de (Diez B. Roggisch) Date: Tue, 24 Sep 2013 08:45:23 +0200 Subject: [Python-mode] edit-style considering empty line In-Reply-To: <52409D2A.8090408@online.de> References: <52409D2A.8090408@online.de> Message-ID: <0F68651A-3AE2-4FF0-B925-84F7CD7B9641@web.de> On Sep 23, 2013, at 9:57 PM, Andreas R?hler wrote: > Hi Barry, hi all, > > there was an expample at > > http://stackoverflow.com/questions/18940719/python-indentation-with-emacs/18940836#18940836 > > if 1 < 2: > print("this line is part of the if statement") > > print("this is NOT part of the if statement") > > > The OP wanted the Editor intends the second "print" to column 0. > IMO it's possibly establishing an edit rule saying: if an empty line follows a block, consider this block closed. > > Now seeing the example below at > > http://pyvideo.org/video/1708/distributed-coordination-with-python > > def find(seq, target): > for i, value in enumerate(seq): > if value == tgt: > break > else: > return -1 > return i > > If an empty line after "break" is inserted: > > def find(seq, target): > for i, value in enumerate(seq): > if value == tgt: > break > > else: > return -1 > return i > > That would allow to calulate the "else:" to column 4 right away. > Also for me it's slightly better readable. > > Question: Would you welcome such an edit-style or rather discourage? If it's optional, and initially off, I wouldn't mind. But vertical spaces are used to structure code for readability, and because of that shouldn't be automatically assumed having semantics. Diez From andreas.roehler at online.de Tue Sep 24 10:04:53 2013 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 24 Sep 2013 10:04:53 +0200 Subject: [Python-mode] edit-style considering empty line In-Reply-To: <0F68651A-3AE2-4FF0-B925-84F7CD7B9641@web.de> References: <52409D2A.8090408@online.de> <0F68651A-3AE2-4FF0-B925-84F7CD7B9641@web.de> Message-ID: <524147A5.808@online.de> Am 24.09.2013 08:45, schrieb Diez B. Roggisch: > > On Sep 23, 2013, at 9:57 PM, Andreas R?hler wrote: > >> Hi Barry, hi all, >> >> there was an expample at >> >> http://stackoverflow.com/questions/18940719/python-indentation-with-emacs/18940836#18940836 >> >> if 1 < 2: >> print("this line is part of the if statement") >> >> print("this is NOT part of the if statement") >> >> >> The OP wanted the Editor intends the second "print" to column 0. >> IMO it's possibly establishing an edit rule saying: if an empty line follows a block, consider this block closed. >> >> Now seeing the example below at >> >> http://pyvideo.org/video/1708/distributed-coordination-with-python >> >> def find(seq, target): >> for i, value in enumerate(seq): >> if value == tgt: >> break >> else: >> return -1 >> return i >> >> If an empty line after "break" is inserted: >> >> def find(seq, target): >> for i, value in enumerate(seq): >> if value == tgt: >> break >> >> else: >> return -1 >> return i >> >> That would allow to calulate the "else:" to column 4 right away. >> Also for me it's slightly better readable. >> >> Question: Would you welcome such an edit-style or rather discourage? > > If it's optional, and initially off, I wouldn't mind. Would be off by default. BTW if enabled, C-j than would keep indent at first step. A second C-j would leave that empty line empty but re-calculate if it should dedent now after that new rule. From barry at python.org Tue Sep 24 15:45:14 2013 From: barry at python.org (Barry Warsaw) Date: Tue, 24 Sep 2013 09:45:14 -0400 Subject: [Python-mode] edit-style considering empty line In-Reply-To: <52409D2A.8090408@online.de> References: <52409D2A.8090408@online.de> Message-ID: <20130924094514.2779e0b9@anarchist> On Sep 23, 2013, at 09:57 PM, Andreas R?hler wrote: >The OP wanted the Editor intends the second "print" to column 0. IMO it's >possibly establishing an edit rule saying: if an empty line follows a block, >consider this block closed. As Diez mentioned, an option defaulting to off would be interesting to play with. I generally discourage using vertical whitespace inside methods, and mostly use it for structural separation, so I think this might be reasonable. It could only apply to actual blank lines, i.e. comments wouldn't trigger it. >def find(seq, target): > for i, value in enumerate(seq): > if value == tgt: > break > else: > return -1 > return i Actually, that else gets lined up under 'if' right now. >If an empty line after "break" is inserted: > >def find(seq, target): > for i, value in enumerate(seq): > if value == tgt: > break > > else: > return -1 > return i So I guess you're saying the blank line would add an extra dedent level? I hate to have people start to rely on this behavior to add non-structural vertical whitespace. If this feature is more helpful for top-level structures, then it might be useful, otherwise I'm skeptical. But as I say, it might be interesting to play with. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From georg at python.org Wed Sep 25 08:10:35 2013 From: georg at python.org (Georg Brandl) Date: Wed, 25 Sep 2013 08:10:35 +0200 Subject: [Python-mode] edit-style considering empty line In-Reply-To: <20130924094514.2779e0b9@anarchist> References: <52409D2A.8090408@online.de> <20130924094514.2779e0b9@anarchist> Message-ID: <52427E5B.6090207@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.09.2013 15:45, schrieb Barry Warsaw: > On Sep 23, 2013, at 09:57 PM, Andreas R?hler wrote: > >> The OP wanted the Editor intends the second "print" to column 0. IMO >> it's possibly establishing an edit rule saying: if an empty line follows >> a block, consider this block closed. > > As Diez mentioned, an option defaulting to off would be interesting to > play with. I generally discourage using vertical whitespace inside > methods, and mostly use it for structural separation, so I think this might > be reasonable. It could only apply to actual blank lines, i.e. comments > wouldn't trigger it. +1. >> def find(seq, target): for i, value in enumerate(seq): if value == tgt: >> break else: return -1 return i > > Actually, that else gets lined up under 'if' right now. > >> If an empty line after "break" is inserted: >> >> def find(seq, target): for i, value in enumerate(seq): if value == tgt: >> break >> >> else: return -1 return i > > So I guess you're saying the blank line would add an extra dedent level? > I hate to have people start to rely on this behavior to add non-structural > vertical whitespace. If this feature is more helpful for top-level > structures, then it might be useful, otherwise I'm skeptical. But as I > say, it might be interesting to play with. Yep. I'd never write the above; in this specific instance for-else is uncommon enough that you don't want to separate them even more :) But also for more common multi-clause constructs like if-else or try-except I would not normally combine dedent with an empty line; the dedent itself has enough effect on the visual structuring IMO. cheers, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlJCflsACgkQN9GcIYhpnLDc9ACfUst8SFgoZx81gLpBl3fyOVzC CfIAn21Z3wDymkL623m8mBMLIwb8Uvas =n8yp -----END PGP SIGNATURE-----