Re: [Python-mode] [PATCH] Fix ob-python.el initiate session error with py-shell

[Andreas Röhler]

,

On 20.02.20 06:45, stardiviner wrote:

Hi,
python-mode.el developer here.

Since python.el is built-in to Emacs, I think that things should
continue to work for python-mode.el users, even if we entirely switch
over to only using python.el.


Thanks supporting python-mode.el. Both python-modes should not conflict 
- except for the key-setting, which is taken by the last one loaded:


py-mode-map didn't work for some reasons, so both provide now 
python-mode-map.




The only thing I'm not sure about, is whether the equivalent of
"python-shell-send-region" in python-mode.el will work with shells
started by python.el. If not, this could probably be addressed with a
patch to python-mode.el.


It should work. Will check it. Please feel free to send a bug-report 
resp. feature request to


https://gitlab.com/python-mode-devs/python-mode/issues

in case of python-mode.el related stuff.



You could test this by explicitly setting `org-babel-python-mode' to
`python' (it is probably set to `python-mode' on your system, which is
the default when python-mode.el is detected).

I'll add a TODO for myself to explicitly mark python-mode-related
variables as deprecated. I'm also planning a major update to the Worg
documentation of ob-python when 9.4 comes out, and will mention the
deprecation there as well.

Thanks for your work! Jack

- -- 
[ stardiviner ]


BTW there are some reasons, why python-mode.el still exists: no known 
indentation bugs, finer navigation commands etc. Maybe have a look at 
open python.el bugs and check them against python-mode.el


Best,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight in different colors for variables inside `fstring`

[Andreas Röhler]

https://gitlab.com/python-mode-devs/python-mode/issues/76

On 30.01.20 19:33, Barry Warsaw wrote:

It would be pretty neat!

-Barry


On Jan 30, 2020, at 00:36, Andreas Röhler  wrote:

Hi Barry, hi all,

there was a question at

https://emacs.stackexchange.com/questions/55184/how-to-highlight-in-different-colors-for-variables-inside-fstring-on-python-mo

Worth a feature-request?


Cheers,

Andreas



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] highlight in different colors for variables inside `fstring`

[Andreas Röhler]

Hi Barry, hi all,

there was a question at

https://emacs.stackexchange.com/questions/55184/how-to-highlight-in-different-colors-for-variables-inside-fstring-on-python-mo

Worth a feature-request?


Cheers,

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el: sources of named shells restored

[Andreas Röhler]

Hi Barry, hi all,

creating commands on the fly turned out not being convenient WRT 
debugging - restored the sources.


+ pypy-shell command.

Just FYI.

Cheers,

Andreas



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] py-show, py-show-all

[Andreas Röhler]

Hi Barry, hi all,

in order to hide forms at point, python-mode.el comes with a couple of
commands ‘py-hide-def’, ‘py-hide-block’ etc.

Their counterparts ‘py-show-block’ etc. however turned out rather
complicated to use: had to remember which form was hidden.

Replaced py-show-FORM commands by single ‘py-show’, which shows
whatever is hidden at point. There is also a new ‘py-show-all’
un-hiding all hidden stuff in buffer.

Should someone need the dropped specific commands, please tell.

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Fwd: Simplifying python-mode.el

[Andreas Röhler]

Hi Barry,

didn't see your post earlier, sorry for the delay.

No, stuff you mentioned will remain. It's only about the 
switch/no-switch split/no-split fine-grained commands.


IMO splitting and switching are ruled better by setting these two 
options instead of breeding out a myriad of commands.


Cheers,

Andreas



On 16.07.19 00:23, Barry Warsaw wrote:

I personally only tend to use py-execute-region (C-c |) and py-execute-buffer 
(C-c C-c).  Are you proposing to change or remove those?

-Barry


On Jul 13, 2019, at 23:16, Andreas Röhler  wrote:

 Forwarded Message 
Subject:Simplifying python-mode.el
Date:   Sat, 13 Jul 2019 09:56:32 +0200
From:   Andreas Röhler 
To: Barry Warsaw 


Hi Barry, hi all,

consider to reduce the amount of commands starting with `py-execute-...`

Such things like py-execute-block-ipython-dedicated-switch.

It would remain

py-execute-block-ipython

running in dedicated buffer when called with C-u

For switch and split options there are already

py-switch-buffers-on-execute-p and

py-split-window-on-execute

Just FYI.

Any objections?

Cheers,


Andreas




___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python-mode.el partial rewrite

[Andreas Röhler]

Thanks Barry,

next question:

we have a lot of commands which are convenient occasionally, however 
most of them will never be used but take a lot of space. To make the 
core of python-mode.el readable again think to construct it on the fly 
according to something like


(defcustom py-known-shells
  (list "ipython"
    "ipython2.7"
    "ipython3"
    "jython"
    "python"
    "python2"
    "python3"
    "pypy"
    )
  "A list of available shells instrumented for commands.
 Expects its executables installed"))...

This list might be shrink or extended at will.

Two backsides: a slightly larger loading time and source of callers like 
‘py-execute-section-ipython3’ will not be visible for users.


WDYT? Any objections?

Cheers,

Andreas




On 11.07.19 23:22, Barry Warsaw wrote:

Great, thanks for all your great work on the module.  I’ve updated to 639532b 
and will play with this for a while.

-Barry


On Jul 10, 2019, at 01:14, Andreas Röhler  wrote:

Hi Barry, hi all,

should have fixed  IPython completion and fontification, also #31,

which caused some changes. Maybe check it out.

Cheers,

Andreas



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el partial rewrite

[Andreas Röhler]

Hi Barry, hi all,

should have fixed  IPython completion and fontification, also #31,

which caused some changes. Maybe check it out.

Cheers,

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] py-shell interactively switch

[Andreas Röhler]

Hi Barry,

Current behavior is ruled by ‘py-switch-buffers-on-execute-p’, which
defaults to nil - display the result but don't move cursor thereto.

Assume yours is customized to ‘t’, so new setting proposed here would
make no difference.


On 11.06.19 23:40, Barry Warsaw wrote:

Sorry, I’m unsure how what you propose differs from the current behavior.

Cheers,
-Barry


On Jun 11, 2019, at 05:01, Andreas Röhler  wrote:

Hi all,

when starting a Py-shell interactively like M-x python RET,
suggest to switch into newly opened shell by default.

Agreed?

Cheers,

Andreas




___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] py-shell interactively switch

[Andreas Röhler]

Hi all,

when starting a Py-shell interactively like M-x python RET,
suggest to switch into newly opened shell by default.

Agreed?

Cheers,

Andreas



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Dropping position functions

[Andreas Röhler]

Hi all,

while in another re-write WRT speed and maintenance --see my previous 
post-- stumble over  a couple of functions reporting position like 
`py--beginning-of-if-block-position' - which doesn't look useful. 
Consider to drop them. Any objections?


Happy new year,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] lean navigation

[Andreas Röhler]

Hi all,

when a class has a large amount of defs inside, jumping to the end of
class might take some noticeable time. (Albeit don't see a bug report so
far.)

For now, navigating Python source internally is done by
‘py-forward-statement’ resp. ‘py-backward-statement’ - where
‘statement’ means just ‘section of code starting at its own indent’.
While this seems complete and reliable, it does several checks we
might get rid off in certain circumstances when speed matters.

For example when jumping to the end from a known block-start, may
reason from the current indentation: any further start lesser/equal
indented can't be part of.

This makes some assumptions WRT formatting and might fail in case of
uncommon or mixed formats using semicolons for example. As it's about
an editor here and not about a lexer/parser IMO the change might be
worth it. OTOH: how often exist these large classes?

Maybe have a customizable boolean py-use-speed-navigation-p?
Just a RFC,

Cheers,
Andreas





___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Python docstring folding

[Andreas Röhler]

On 22.11.18 00:30, Barry Warsaw wrote:

On Nov 21, 2018, at 02:21, Andreas Röhler  wrote:


is this worth a feature request?


It’s not something I personally use, but I know other people like it.

-Barry



Okay, done.

https://gitlab.com/python-mode-devs/python-mode/issues/60

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Fwd: Re: Python docstring folding

[Andreas Röhler]

Hi all,

is this worth a feature request?

Cheers,
Andreas


 Forwarded Message 
Subject: Re: Python docstring folding
Date: Tue, 20 Nov 2018 19:16:58 +
From: Rock Storm 
To: Drew Adams 
CC: help-gnu-em...@gnu.org

On Tue, Nov 20, 2018 at 10:12:03AM -0800, Drew Adams wrote:

> I'm struggling with code folding. I installed
> 'outline-magic'. Which works great but it doesn't
> fold docstrings... Is there an easy way to achieve
> docstring folding?

What do you mean by folding doc strings?  What do you
want that it doesn't do?


The behaviour I was expecting would be something similar to what this
plugin does [1].
 [1]: https://github.com/alecthomas/SublimeFoldPythonDocstrings


If you just want to toggle whether doc strings (only)
are hidden, see this:

http://lists.gnu.org/archive/html/help-gnu-emacs/2018-11/msg00115.html


Thanks a lot for the hint. I'll try that. However, isn't there a less
complicated way of doing it? Is it so uncommon? How did Python
developers live before you provided them with this? :P

Thanks again,
--
Rock Storm
GPG KeyID: 4096R/C96832FD
GPG Fingerprint:
 C304 34B3 632C 464C 2FAF  C741 0439 CF52 C968 32FD

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] py-up-list - behavior and keys

[Andreas Röhler]

Hi all,

IMO ‘py-up-list’ should behave as Elisp's ‘backward-up-list’ does.
When starting from last line "except True:" it should travel current 
indents and reach beginning of next block above: "if True:"


def foo():
if True:
def bar():
pass
elif False:
def baz():
pass
else:
try:
1 == 1
except True:


Maybe also add a mode-specific key-binding

, C-M-u, ESC 

?

Cheers,
Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Simplifying - drop decorator special forms

[Andreas Röhler]

On 12.11.2018 22:58, Barry Warsaw wrote:

On Nov 12, 2018, at 03:15, Andreas Röhler  wrote:


as decorators are part of function definitions, consider to drop all special 
handling. Beginning of def-or-class would reach the decorator - same with mark, 
copying and send.


Is it possible to use C-u to choose whether to go to the first decorator or the 
function definition?


Sure. Probably a defcustom py-include-decorators-p might be useful too.


  Remember, you can have a bunch of function decorators, not just one. 
So going to the first decorator could put you way off from where you expect.


E.g. if you use click, from Mailman 3:

@click.command(
 cls=I18nCommand,
 context_settings=dict(help_option_names=['-h', '--help']),
 help=_("""\
 Master subprocess watcher.

 Start and watch the configured runners, ensuring that they stay alive and
 kicking.  Each runner is forked and exec'd in turn, with the master waiting
 on their process ids.  When it detects a child runner has exited, it may
 restart it.

 The runners respond to SIGINT, SIGTERM, SIGUSR1 and SIGHUP.  SIGINT,
 SIGTERM and SIGUSR1 all cause a runner to exit cleanly.  The master will
 restart runners that have exited due to a SIGUSR1 or some kind of other
 exit condition (say because of an uncaught exception).  SIGHUP causes the
 master and the runners to close their log files, and reopen then upon the
 next printed message.

 The master also responds to SIGINT, SIGTERM, SIGUSR1 and SIGHUP, which it
 simply passes on to the runners.  Note that the master will close and
 reopen its own log files on receipt of a SIGHUP.  The master also leaves
 its own process id in the file specified in the configuration file but you
 normally don't need to use this PID directly."""))
@click.option(
 '-C', '--config', 'config_file',
 envvar='MAILMAN_CONFIG_FILE',
 type=click.Path(exists=True, dir_okay=False, resolve_path=True),
 help=_("""\
 Configuration file to use.  If not given, the environment variable
 MAILMAN_CONFIG_FILE is consulted and used if set.  If neither are given, a
 default configuration file is loaded."""))
@click.option(
 '--no-restart', '-n', 'restartable',
 is_flag=True, default=True,
 help=_("""\
 Don't restart the runners when they exit because of an error or a SIGUSR1.
 Use this only for debugging."""))
@click.option(
 '--force', '-f',
 is_flag=True, default=False,
 help=_("""\
 If the master watcher finds an existing master lock, it will normally exit
 with an error message.  With this option,the master will perform an extra
 level of checking.  If a process matching the host/pid described in the
 lock file is running, the master will still exit, requiring you to manually
 clean up the lock.  But if no matching process is found, the master will
 remove the apparently stale lock and make another attempt to claim the
 master lock."""))
@click.option(
 '--runners', '-r',
 metavar='runner[:slice:range]',
 callback=validate_runner_spec, default=None,
 multiple=True,
 help=_("""\
 Override the default set of runners that the master will invoke, which is
 typically defined in the configuration file.  Multiple -r options may be
 given.  The values for -r are passed straight through to bin/runner."""))
@click.option(
 '-v', '--verbose',
 is_flag=True, default=False,
 help=_('Display more debugging information to the log file.'))
@click.version_option(MAILMAN_VERSION_FULL)
@public
def main(config_file, restartable, force, runners, verbose):
 # ….

Cheers,
=Barry



Thanks for the example,

Cheers,
Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Simplifying - drop decorator special forms

[Andreas Röhler]

Hi,

as decorators are part of function definitions, consider to drop all 
special handling. Beginning of def-or-class would reach the decorator - 
same with mark, copying and send.


Just FYI,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Refined formatting in docstring

[Andreas Röhler]

Hi  Barry, hi all,

there was a question WRT formatting of docstring,

http://emacs.stackexchange.com/questions/19422/emacs-lisp-for-automatically-inserting-python-docstring-in-google-style

which points to this

https://www.chromium.org/chromium-os/python-style-guidelines#TOC-Describing-arguments-in-docstrings

Just FYI, cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Fwd: bug#21778: 24.5; python mode: fill-paragraph with raw docstring ignores python-fill-docstring-style

[Andreas Röhler]

 Hi Barry,

assume this affects python-mode.el also (?)

Cheers,

Andreas

 Original Message 
Subject: 	bug#21778: 24.5; python mode: fill-paragraph with raw 
docstring ignores python-fill-docstring-style

Resent-Date:Wed, 28 Oct 2015 19:44:01 +
Resent-From:John Palmieri 
Resent-CC:  bug-gnu-em...@gnu.org
Date:   Wed, 28 Oct 2015 12:16:20 -0700
From:   John Palmieri 
To: 21...@debbugs.gnu.org



To recreate the bug, in Python mode, type

def f():
r"""
This is the docstring for my function.

It's a raw docstring because I want to type \t here, and maybe \n,
for example in LaTeX code like \tau or \nu.

More docstring here.
"""
pass

Now with the cursor in the first sentence of the docstring, running 
fill-paragraph ignores the setting of python-fill-docstring-style, I 
think because Emacs doesn't detect that r""" is the start of the  
docstring. Similarly, running fill-paragraph in the last sentence 
behaves badly. Also similarly, I think that it should be valid to begin 
a docstring with b""" or u""" (and possibly some combination of b, r, u, 
before """, although I'm not sure), and these also don't behave correctly.




In GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
 of 2015-04-10 on builder10-9.porkrind.org 


Windowing system distributor `Apple', version 10.3.1348
Configured using:
 `configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp''

Important settings:
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: Outline

Minor modes in effect:
  goto-address-mode: t
  TeX-PDF-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t
  view-mode: t

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el 6.2.1 released

[Andreas Röhler]

Hi guys,

gladly announcing release 6.2.1

Something new comes with it:

- Handles PEP 492 async coroutines

- Logic of py-indent-region WRT lp:1426903
  In case first line accepts an indent,
  keep the remaining lines' relative.
  Otherwise lines in region get outmost indent,
  same with optional argument

- Commands
  - py-match-paren
If at a beginning, jump to end and vice versa.
Matches lists, block, statement, string and comment

  - ipython2.7
  - ipython3

  - py-beginning-of-for-block
  - py-beginning-of-for-block-bol
  - py-end-of-statement-bol
  - py-end-of-top-level-bol

  - py-flycheck-mode - toggle `flycheck-mode' from menu "Checks"

  - py-execute-section - execute arbitrary chunks of code
  - py-execute-section-python
  - py-execute-section-python2
  - py-execute-section-python3
  - py-execute-section-ipython
  - py-execute-section-ipython2.7
  - py-execute-section-ipython3
  - py-execute-section-jython

  - py-sectionize-region
  - py-backward-section
  - py-forward-section

  - py-narrow-to-block
  - py-narrow-to-block-or-clause
  - py-narrow-to-class
  - py-narrow-to-clause
  - py-narrow-to-def
  - py-narrow-to-def-or-class
  - py-narrow-to-statement

- New helper functions, like
  - py--end-of-block-bol-p
  - py--end-of-clause-bol-p
  etc.

  Functions in a boolean sense just stating if being at an end or
  start no longer a command. Renamed as interanal
  functions with prefix `py--' now.

- TAB-indent from column zero: go to outmost first, lp:1375122
- (I)Python-shell setup made more reliable

New customizables:

- py-imenu-max-items, default is 99
  Sets `imenu-max-items'

- py-python-edit-version, default is ""
  When not empty, fontify according to Python version specified.

- py-pdb-executable, default is nil
  Indicate PATH/TO/pdb.

- py-update-gud-pdb-history-p, default is t
  If pdb should provide suggestions WRT file and pdb-path.

- py-split-window-on-execute-threshold, default is 3
  Don't split when max number of displayed windows is reached.

Renamed:
- py-beginning-of-commented-section --> py-beginning-of-comments
- py-narrow-to-defun --> py-narrow-to-def


;;;

Enjoy,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] before 6.2.1

[Andreas Röhler]

Am 31.07.2015 um 22:50 schrieb Barry Warsaw:

On Jul 21, 2015, at 01:16 PM, Andreas Röhler wrote:


in current trunk `interactive-p' is replaced by `called-interactively-p',
just to reduce compiler warnings.  `called-interactively-p' seems introduced
only with 22.1, older Emacsen will be broken.  Is this a concern?

Not for me :).

Cheers,
-Barry


Okay, in case some complain arrives: it's just a M-x replace-string RET 
to restore.

May extend the README then.

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] before 6.2.1

[Andreas Röhler]

Hi Barry, hi all,

in current trunk `interactive-p' is  replaced by 
`called-interactively-p', just to reduce compiler warnings.


`called-interactively-p' seems introduced only with 22.1, older Emacsen 
will be broken.


Is this a concern?

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] C-M-f, C-M-b

[Andreas Röhler]

Am 26.06.2015 um 20:24 schrieb Barry Warsaw:

On Jun 25, 2015, at 06:44 PM, Andreas Röhler wrote:


the equivalent of what forward-sexp in Emacs Lisp is --or should be-- is
py-forward-expression.

What about setting C-M-f to it? Resp. C-M-b

Seems reasonable I think.

-Barry


Done.

Keys will be set if py-sexp-use-expression-p is non-nil, default is nil.

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] C-M-f, C-M-b

[Andreas Röhler]

Hi Barry, hi all,

the equivalent of what forward-sexp in Emacs Lisp is --or should be-- is 
py-forward-expression.


What about setting C-M-f to it? Resp. C-M-b

If inside an expression C-M-f should to to its end.
From end to next end same level if existing - or level up, or next 
top-level-form, or nil at EOB


Any opinion?

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Fwd: Re: Evaluating python code blocks in python-mode

[Andreas Röhler]

 Weitergeleitete Nachricht 
Betreff:Re: Evaluating python code blocks in python-mode
Datum:  Sun, 21 Jun 2015 08:20:46 +0200
Von:Andreas Röhler andreas.roeh...@easy-emacs.de
An: help-gnu-em...@gnu.org



Am 20.06.2015 um 21:09 schrieb Andreas Röhler:


Am 20.06.2015 um 12:50 schrieb Yuri D'Elia:

Hi everyone,

I'd like some advice about using python-mode with a python subprocess.
I always preferred to use emacs+file+external process as opposed to use
an ipython's notebook-like interface: it's just more convenient,
especially when debugging existing code.

I often use the same setup when doing some analysis, and this is when an
inotebook-like interface is more convenient for evaluation: I'd like to
evaluate code not line-by-line, or by defun, but by my custom-defined
blocks. I realized I was continuously selecting a region, and using
py-send-region over and over.

Right now I narrow to the region I'm editing, and use py-send-buffer
instead. It's ok-eish, but narrow/widen narrow/widen, while less common,
is still inconvenient.

I've seen people using org-mode for this kind of setup instead. Which
might be ok, but I'd like to know what other choices I could have as
well.

I was thinking of defining a custom region using comments, and defining
my own py-send-custom-block using comment markers as boundaries. Surely,
something like this must already exists.





IIUC in question are arbitrary chunks of code.
What about something like that:



(defvar py-section-start # {{)
(defvar py-section-end # }})

(defun py-send-section ()
  (interactive)
  (save-excursion
(unless (looking-at py-section-start)
  (search-backward py-section-start)
  (set-mark (point))
  (if (and (looking-at py-section-start)(search-forward
py-section-end))
  (py-execute-region (region-beginning) (region-end))
(error Can't see boundaries of py-section)



BTW didn't call it block, as this is already used by forms heading
others.





As python-mode sends a plain string to interpreter anyway, must not
touch mark in buffer:

(defun py-send-section ()
  (interactive)
  (save-excursion
(let ((start (progn (unless (looking-at py-section-start)
 (search-backward py-section-start)
 (point)
  (if (and (looking-at py-section-start)(search-forward
py-section-end))
  (py-execute-region start (point))
(error Can't see boundaries of py-section)



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Displaying symbols in customization buffer

[Andreas Röhler]

On 14.03.2015 16:14, Barry Warsaw wrote:
[ ...]

 It probably does make sense to audit the knobs and see which ones are really

useful for customizing.



Done.

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Displaying symbols in customization buffer

[Andreas Röhler]

On 13.03.2015 22:36, Barry Warsaw wrote:

On Mar 13, 2015, at 10:37 PM, Andreas Röhler wrote:


writing something like

:tag my-correct-py-symbol-name

in defcustom


I kind of wish Emacs did this by default, but that's a different discussion
for a different forum.  ;)

Is it more helpful to python-mode users to add the tag or more confusing to
Emacs users to see different behavior?  It's up to you for Python mode!



Hmm, you seem not that much convinced.
Well, for me it's slightly confusing to see this capitalized split, which I 
must reconstruct into the original name in order to understand which one is at 
stake.

Anyway, there is no hurry for this.

BTW consider to reduce the number of customizations, replace some by defvar.
Notably for handing-over string-codes, setup-codes, like py-eldoc-string-code 
does.
Users being confident to change this will know about setq.

Cheers,

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Displaying symbols in customization buffer

[Andreas Röhler]

On 14.03.2015 16:14, Barry Warsaw wrote:

On Mar 14, 2015, at 10:38 AM, Andreas Röhler wrote:


Hmm, you seem not that much convinced.  Well, for me it's slightly confusing
to see this capitalized split, which I must reconstruct into the original
name in order to understand which one is at stake.


It's not so much unconvinced as it is whether it's worth it to fix it in
python-mode, when it's an Emacs feature.  I really don't like it in *any*
customize buffers, but I think it might be too weird to see it displayed nicer
only in python-mode.  Better I think to push a fix (or option?) upstream.



I'm afraid there are more serious issues worth raising upstream.

Beside the matter doesn't show up that much in core, as splitting the prefix 
doesn't happen there.
Also when choosing long self-explaining names, it turns bad.

Will change it for convenience.
Just wanted to ask first - as people tend to feel unhappy should something look 
different :)

Best,

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Displaying symbols in customization buffer

[Andreas Röhler]

On 13.03.2015 22:16, Barry Warsaw wrote:

On Mar 13, 2015, at 07:54 PM, Andreas Röhler wrote:


Currently it looks strange - see attachment.


Agreed, but what can python-mode do about that?


writing something like

:tag my-correct-py-symbol-name

in defcustom

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Displaying symbols in customization buffer

[Andreas Röhler]

Hi Barry, hi all,

currently most of symbols in customization buffer get splitted, resulting parts 
are capitalized.

Would prefer to display it with real name, which permits searching it.

Any opinion about that?

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Python help buffer

[Andreas Röhler]

On 09.03.2015 18:26, andrea crotti wrote:

Hi again Andreas and all.
I'm still having this issue with the documentation buffer popping up
all the time..
I'm using now python-mode version:
python-mode-20150221.1223/
from Melpa.

So doing the dirty trick (defun py-help-at-point nil) kind of works
but now causes other issues, so I'd rather just fix it once for all.

I've been trying to understand how that function is triggered in the
first place but can't find it, and it must be something different
between Emacs 24 and Emacs 25 because it doesn't happen on the 24..


Hi Andrea,

this rather indicates a bug in Emacs25. Any reason to use the bleeding edge?
BTW latest pretest 24.4.91.1 runs nicely here.


Cheers
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Python help buffer

[Andreas Röhler]

Hi Andrea,

On 07.01.2015 11:46, andrea crotti wrote:

Hi guys,

I have a problem with Emacs 25 that does not happen with Emacs 24.4.
More specifically with:
- GNU Emacs 25.0.50.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21
Version 10.9.5 (Build 13F34)) of 2014-11-15 on
builder10-9.porkrind.org
- Python mode: 6.1.3

So in short with Emacs 25 the *Python Help* buffer keeps coming up,
whenever the cursor stays for more than a second on something.

I digged a bit and it seems to come from the py-help-at-point
function, can't understand why it does not happen with Emacs 24.4.

I thought it was related to Eldoc but that's also disabled so it's not
the case, and I can't find any variable to customize to disable that
once for all..
I guess it's just something changed in Emacs 25 but can't find out what :/
Any idea?

Doing a (defun py-help-at-point nil) works of course but it's not the
desired solution since it's still useful sometimes.

Thanks a lot


From Emacs -Q, loading python-mode.el by hand, does it still happen?

Andreas





___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Python help buffer

[Andreas Röhler]

On 07.01.2015 18:50, andrea crotti wrote:

2015-01-07 12:33 GMT+00:00 Andreas Röhler andreas.roeh...@online.de:

Hi Andrea,

 From Emacs -Q, loading python-mode.el by hand, does it still happen?

Andreas



I realised to my surprise that I was not actually using the version
from ELPA but a version in my disk.
Anyway I now downloaded from ELPA (marmalade) 6.13 started Emacs 25
with -Q and evaluated manually the python-mode.el buffer.

It still happens, so I bet the problem is something with Emacs 25 that
auto call something that didn't use to call before?



It would really make sense to check with emacs -Q, load python-mode.el, open 
some .py file.

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el-6.2.0 released

[Andreas Röhler]

Hi Barry, hi all,

so it's out there finally.

For new features see

https://launchpad.net/python-mode/+announcement/13077

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] rename py-split-windows-on-execute-p

[Andreas Röhler]

Hi Barry, hi all,

variable in subject seems somehow misnamed: when value is queried, it's just 
one window to be splitted, not a multitude.

Consider to rename it into `py-split-window-on-execute-p', removing the s.

As renaming might mean some inconvenience at users side and no-one complained 
so far - announcing this.

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [Bug 1375122] Re: py-indent-line behavior from 6.1.1

[Andreas Röhler]

On 29.09.2014 23:02, Jonathan C. Dodd wrote:

Unfortunately, C-j is only possible from the previous line, and I tend
to jump around the code quite a bit.  When I come back wanting to e. g.
insert a new line into a matrix, I have to either go to the line before
the one I have inserted and press C-j from there, or press TAB
repeatedly and align the remainder with spaces.  This is completely
unintuitive and inconsistent relative to other modes (c++-mode, js-mode,
emacs-lisp-mode etc etc, which all move cursor to rightmost sane
indentation when pressing TAB).


Seeing you point. However, the way it behaves now is the default for years.

May change the behaviour so jumps to outmost with first TAB, stepping
backwards afterwards.

Or have another boolean and customization?
Barry, WDYT?

Will cc it to python-mode mailing-list.


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Completion of symbols defined in current buffer

[Andreas Röhler]

Just a remark: `py-load-pymacs-p' addresses Pymacs-files inlined by 
python-mode, not a Pymacs installed by running `make'.



To be precise: an inlined Pymacs is shipped with

 lp:python-mode/components-python-mode

but was removed from trunk.

While contributed files providing completion as mentioned here are provided by 
trunk also.


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Completion of symbols defined in current buffer

[Andreas Röhler]

Hi Barry,

being inclined to drop that feature

https://bugs.launchpad.net/python-mode/+bug/1001328

Emacs provides dabbrev-expand, which is Python-agnostic but fairly effectiv.
Otherwise the buffers content needs to be evaluated - with means, it must be 
correct already.

WDYT?

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Completion of symbols defined in current buffer

[Andreas Röhler]

On 01.09.2014 21:24, Urs Fleisch wrote:

Hi Andreas, Barry,
Hi Emacs-Pythonistas,


being inclined to drop that feature

https://bugs.launchpad.net/python-mode/+bug/1001328

Emacs provides dabbrev-expand, which is Python-agnostic but fairly
effectiv. Otherwise the buffers content needs to be evaluated - with
means, it must be correct already.


I'm probably not qualified to say whether the feature should be kept
or not, since I use dabbrev exclusively.


Since I have contributed quite some code for Python code completion in
Emacs, I feel a bit concerned by this question, so let me say a few
things about the current state of completion.

It's been two years ago when I contributed my completion code, but
still, it is quite hard to get a working Emacs-Python-Environment
having code completion. I think that a novice (or non-expert) user will
have problems getting it working. Theoretically it could be quite easy,
just create a ~/.emacs.d/init.el file with the following contents:

(require 'pymacs)
(setq py-load-pymacs-p t)
(require 'auto-complete-config)
(ac-config-default)

This is for code completing with an auto-complete pop-up-menu. If you
prefer a less obtrusive completion using only the TAB key (as I do),
then use these lines:

(require 'pymacs)
(setq py-load-pymacs-p t)
(setq py-complete-function 'py-complete-completion-at-point)
(setq py-complete-set-keymap-p t)

So far so good. However, the problem is, that you must have at least
pymacs 0.25, which is unfortunately not part of Ubuntu 14.04 (to name a
popular distribution). In this case, you'll have to get pymacs 0.25 (and
emacsen-common) from the upcoming Ubuntu 14.10. So with a standard
Ubuntu 14.04 LTS installation, it will not work. Let's hope that things
improve with Ubuntu 14.10, then users will at least have all
preconditions for a working code completion.

However, I think that it will be still too hard for the normal user to
make it work. Why not have a simple configuration option, which will
allow users to enable code completion by a simple mouse click? Such a
function should set up all variables and check if the required packages
are available and warn the user if not. I must admit that I do not use
the Emacs package management (ELPA), I would rather rely on the
packages of my Linux distribution, but maybe ELPA could be helpful to
get all those prerequisites.

Regards,
Urs



Hi Urs,

yes, works great for me.

Just a remark: `py-load-pymacs-p' addresses Pymacs-files inlined by 
python-mode, not a Pymacs installed by running `make'.

Loading both, might result in an version-conflict. So in case of running an 
make'd Pymacs, `py-load-pymacs-p' should be nil, the default.

Instead user must follow the install hints delivered with Pymacs-package.

Best,

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] TAB in script buffer

[Andreas Röhler]

Hi,

lately TAB in Python shell was bound to `py-shell-complete-or-indent'.

What about doing likewise in script buffers - where TAB is currently 
`py-indent-line'?

Unfortunatly the default completion-key M-TAB is used by most X-windows 
systems, so users must re-configure first.

Binding it to TAB would solve that.

BTW in this case completion should only be called at end of line and with word 
before. Otherwise TAB would `py-indent-line' - as a second TAB would do also.

Comments?

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] TAB in script buffer

[Andreas Röhler]

On 25.06.2014 16:28, Barry Warsaw wrote:

On Jun 25, 2014, at 04:04 PM, Andreas Röhler wrote:


lately TAB in Python shell was bound to `py-shell-complete-or-indent'.

What about doing likewise in script buffers - where TAB is currently
`py-indent-line'?

Unfortunatly the default completion-key M-TAB is used by most X-windows
systems, so users must re-configure first.

Binding it to TAB would solve that.

BTW in this case completion should only be called at end of line and with
word before. Otherwise TAB would `py-indent-line' - as a second TAB would do
also.

Comments?


Hmm, maybe.  I'd have to try it for a while to make sure it doesn't interfere
with normal code editing.


It should not. Beside reverting will not be an issue - just didn't want to 
create a surprise.

  FWIW, I'm a big fan of dabbrev-complete.

Me too - as the good quite often is nearby :)

#


-Barry



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Reduce complexity

[Andreas Röhler]

Hi Barry, hi all,

WRT

https://bugs.launchpad.net/python-mode/+bug/1330045

consider to drop two variables, which introduce complexity while not being that 
useful as expected.

It's

`py-indent-no-completion-p'

which would insert a TAB if no completion is found.

The other:

`py-no-completion-calls-dabbrev-expand-p'

`dabbrev-expand' is a well known feature at its own keys,
IMO doesn't pay to instrument it here.

Just FYI.

Should anybody want to keep the variables mentioned, please tell.

Cheers,

Andreas



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Big-Data mit Grenzen

[Andreas Röhler]

Seid gegrüßt,

komme eben auf einen eher kritisch gehaltenen Aufsatz

http://www.theeuropean.de/gunnar-sohn/8165-die-grenzen-von-big-data

der Python auf zweierlei Weise berührt:

- die Sprache dürfte derzeit zu einer der am meisten eingesetzten im Kontext 
gehören
- sie bietet m.E. bereits einen Lösungsansatz.

Eine Antwort auf die vorgetragene Kritik bestünde in der Verpflichtung der 
beteiligten Unternehmen, für den Fall, daß personenbezogene Daten verarbeitet 
werden,
Informationsfreiheit zu gewährleisten, z. B. den Quellcode der eingesetzten 
Programme einsehbar zu machen.

Gibt es da eventuell bereits Initiativen seitens des Python Verbandes?

Grüße,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Big-Data mit Grenzen

[Andreas Röhler]

On 28.05.2014 13:48, Andreas Röhler wrote:
[  ... ]

http://www.theeuropean.de/gunnar-sohn/8165-die-grenzen-von-big-data



[ ... ]

Ah, sorry, that should go to a german list.

As it might of interest for readers here also, a short description:

The author in link is questioning some marketing practices by companies using 
at big-data procedures.
Notably he asks if some underlying algorithms indeed permit the reasoning into the socio-sphere as pretended, allowing judgments on human behavior, being worthy to receive 
a bank account etc.


He reports some experiences with firms, which retired their proposal when asked 
for the background procedures.

IMHO that's a matter which deserves some attention also from people at the 
engineers side.

Now Python might be part of the problem as of the solution here.

What the pubblic might deserve is transparency: institutions processing 
personal data should be obliged to publish their sources.
A thing, Python should not have difficulties with...

Cheers,

Andreas









___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Dropping -switch/-noswitch, split/nosplit commands ?

[Andreas Röhler]

Hi Barry, hi all,

when py-exexute-... commands are run, window-mangagement is
controlled by values of customizable booleans

`py-switch-buffers-on-execute-p'

`py-split-windows-on-execute-p'

Considered calls to customize being laborious, commands have been installed
specifying that options like `py-execute-statement-python-switch'

However, that caused a large menu and brought some critics.
OTOH meanwhile lightweight switches are provided with

menu Python/Customize/Switches/Display

which set these vars for current session.

After all dropping these commands seems a gain, as code-base might shrink 
considerably.

WDYT?

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Reducing number of forms

[Andreas Röhler]

On 14.05.2014 22:44, Barry Warsaw wrote:

On May 14, 2014, at 05:36 PM, Andreas Röhler wrote:


in order to shrink the python-mode.el codebase a little bit,

consider to support the following py-shell commands:

python, ipython, python2, python3, jython, bpython

Will drop

python3.3. python2.7 etc.

Calling other versions than default should be easy by mapping python3 onto
PATH/TO/python3.4


That's probably fine.  Maybe C-u should prompt for the name/path to the Python
executable instead of the buffer?

-Barry



Done
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Reducing number of forms

[Andreas Röhler]

Hi Barry, hi all,

in order to shrink the python-mode.el codebase a little bit,

consider to support the following py-shell commands:

python, ipython, python2, python3, jython, bpython

Will drop

python3.3. python2.7 etc.

Calling other versions than default should be easy by mapping python3 onto 
PATH/TO/python3.4

for example.

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] shipping cython-mode.el?

[Andreas Röhler]

Hi Georg, hi all,

when looking for bug lp:1314921, there was a talk a time ago WRT shipping your 
version of cython-mode.el

IMO it would be convenient if users must not load it separately.

As it isn't that much code, could inline it into python-mode.el.

Also would like to make faces customizable, so Cython specific keywords might 
look different from others.
Default would remain as is.

Opinions?

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] face of print

[Andreas Röhler]

Am 24.03.2014 16:11, schrieb Barry Warsaw:
.  Maybe print should be

in its own face, defaulting to whatever makes sense for the Python 2 or 3
version being edited?

-Barry



Done
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] face of print

[Andreas Röhler]

Am 24.03.2014 16:11, schrieb Barry Warsaw:

On Mar 21, 2014, at 06:11 PM, Andreas Röhler wrote:


Function print currently gets font-lock-keyword-face, which doesn't seem
correct.  IMO it should get py-builtins-face, right?


I guess this is dependent on whether you're editing Python 2 or Python 3
code.  I always bring up python-mode in Python 3 by default (most visibly by
defaulting pyflakes to Python 3) so I do see some discrepancies when editing
Python 2 code.

Not sure how to handle this.  I'd prefer Python 3 mode to be the default,
and thus it probably makes more sense for print to be py-builtins-face.  OTOH,
it's a little jarring to me to see print in that face, but I guess no more
jarring than training myself to wrap its arguments in parens.

I really hate to add another config variable for this.  Maybe print should be
in its own face, defaulting to whatever makes sense for the Python 2 or 3
version being edited?

-Barry



Seems worth a ticket:
https://bugs.launchpad.net/python-mode/+bug/1298328

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] face of print

[Andreas Röhler]

Function print currently gets font-lock-keyword-face, which doesn't seem 
correct.
IMO it should get py-builtins-face, right?

Just FYI,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] execute dedicated - multiple buffers?

[Andreas Röhler]

Hi Barry, hi all,

currently, when dedicated is on, a new buffer is created with some 
autogenerated name.

Repeated dedicated calls will leave a row of badly readable buffer-names.

An alternative would be to kill the default shell before and run just a new 
shell.

No idea WRT to pros and cons.

Also introducing a new switch here would be possible.

Any importance at all? Any suggestions?

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] execute dedicated - multiple buffers?

[Andreas Röhler]

Am 13.03.2014 12:18, schrieb Andreas Röhler:

Hi Barry, hi all,

currently, when dedicated is on, a new buffer is created with some 
autogenerated name.

Repeated dedicated calls will leave a row of badly readable buffer-names.

An alternative would be to kill the default shell before and run just a new 
shell.

No idea WRT to pros and cons.

Also introducing a new switch here would be possible.

Any importance at all? Any suggestions?

Cheers,

Andreas


Quickly answering myself:

session mode - where state and output-buffer are kept/continued
dedicated - address/create an output buffer different from default

in combination:

not session, not dedicated - uses old/default cleaned-up output-buffer with new 
process
session, not dedicated - re-uses old buffer, reads state (DEFAULT)

session, dedicated -  continue last dedicated buffer
not session, dedicated - new process in new auto-generated output-buffer




___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] execute dedicated - multiple buffers?

[Andreas Röhler]

Am 13.03.2014 14:57, schrieb Barry Warsaw:

On Mar 13, 2014, at 12:18 PM, Andreas Röhler wrote:


currently, when dedicated is on, a new buffer is created with some
autogenerated name.


I don't really use this feature, so I don't have an opinion.

Cheers,
-Barry



Being after lp:1253907, Slow with large output

It requires a different way of processing, thus coming upon that part.
Think got it here,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] formatting triple-quoted-strings

[Andreas Röhler]

Hi Barry, hi all,

currently formatting tqs with py-docstring-style is called, if tqs is below a 
class or def.

OTOH tqs are also used at beginning of file or other place in sense of a 
info/docstring.

What about to apply docstring-styles every times a tqs is formatted?

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Emacs python-mode.el bug #1207470

[Andreas Röhler]

Am 15.02.2014 22:18, schrieb Frank Stutzman:

This has been resolved and I want to publically thank Andreas for finding
and fixing this bug so quick.  I'm fairly new to open source development and
the rapidity that this was fix was gratifying.




You are welcome!
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el 6.1.3 released

[Andreas Röhler]

Hi all,

version 6.1.3 delivers some bug-fixes and should come with improvements too:

https://launchpad.net/python-mode/trunk/6.1.3/+download/python-mode.el-6.1.3.tar.gz

- PEP8 indent-alternatives when closing a list implemented

Boolean `py-close-at-start-column-p', default is nil

my_list = [
1, 2, 3,
4, 5, 6,
]
result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)

When non-nil, it will be lined up under the first character of the line that 
starts the multi-line construct, as in:

my_list = [
1, 2, 3,
4, 5, 6,
]

result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)

- Keys C-M-a, C-M-e usable for all top-level form, lp:1191078

  Boolean `py-defun-use-top-level-p'
  If non-nil, beginning- end-of-defun forms will use
  `py-beginning-of-top-level', `py-end-of-top-level',
  mark-defun marks top-level form at point etc.

Keys C-M-a, C-M-e usable for all top-level form, lp:1191078

- New commands:
  py-beginning-of-block-current-column
  Reach the beginning of block which starts at current column 

  py-beginning-of-top-level
  py-beginning-of-top-level
  py-end-of-top-level
  py-mark-top-level
  py-copy-top-level
  py-delete-top-level
  py-kill-top-level
  py-execute-top-level
  py-top-level-form-p
  py-comment-top-level
  py-beginning-of-top-level-p

- `minor-block' commands added
  A minor block is started by a `for', `if', `try' or `with',
  while block covers also `def' or `class'

- variable `py-keep-windows-configuration', default is nil
  Setting `py-keep-windows-configuration' to `t' will
  restore windows-configuration regardless of
  `py-switch-buffers-on-execute-p' and
  `py-split-windows-on-execute-p' settings. However, if
  an error occurs, it's displayed.

  To suppres window-changes due to error-signaling
  also, set `py-keep-windows-configuration' onto 'force

- boolean empty-line-closes-p, default is nil
  When non-nil, dedent after empty line following block
  If non-nil, a C-j from empty line would dedent.

  if True:
  print(Part of the if-statement)

  print(Not part of the if-statement)

- boolean py-debug-p, default is nil
  When non-nil, keep resp. store information useful for
  debugging. Temporary files are not deleted. Other
  functions might implement some logging etc.

- heuristic exit
  new var `py-max-specpdl-size', default is `max-specpdl-size'
  py-end-of-statement will error if number of
  `py-max-specpdl-size' loops is completed, thus avoiding
  a hang from a possibly eternal loop.

- `py-statement' no longer refferred to `py-copy-statement'
  Same with block, def, expression etc. `py-statement' made
  own command, which returns statement, a string.

- boolean `py-max-help-buffer-p', default is nil
  If *Python-Help*-buffer be the only visible.

Enjoy,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] TAB-completion, lp:1252029

[Andreas Röhler]

Am 20.11.2013 15:25, schrieb Barry Warsaw:

On Nov 20, 2013, at 03:20 PM, Andreas Röhler wrote:


TAB seems expected frequently as bound to completion, while it indents in
python-mode.

IMO it's possible to combine both: a first TAB at most outdented position now
does nothing - which would be the occasion for complete.  Second TAB than
should close the completion buffer and jump back to col 0.


I never use TAB completion in python-mode,


that's no surprise, as there is no such thing and wasn't. :)


but I do use dabbrev-expand.


one of the greatest Emacs features IMO


Perhaps make this configurable - yeah, yet another variable :/


BTW there is no need to learn all these variables - as we might safely ignore 
most of the others at Emacs.
The goal is a reasonable default - and the possibility to meet requests the 
moment they show up.
Than it's time to lookup still.

Finally not sure if the possible confusion from TAB-completion might outweight 
the gain.
TAB-completion would only work at the outmost indent, but can't be provided at 
the other, which seems
not straight.

Still reflecting...


Cheers,

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] different set of colors for pairs

[Andreas Röhler]

Am 18.10.2013 18:55, schrieb Barry Warsaw:

On Oct 18, 2013, at 06:38 PM, Andreas Röhler wrote:


Agreed. Obviously we can't have everything. This is a lot the Emacs way.
Must confess had in mind to change the path towards an (rather complete) IDE.


This kind of a path may be useful for people, and interesting to work on.  One
way to think about structuring that though is to keep python-mode narrowly
focused on providing excellent editing of Python code, with the more
sophisticated bells and whistles for optional add-ons and companion modules.

Cheers,
-Barry



Code base might be shrink considerably if some versioned shell-commands are 
thrown out: for example all with python3.3 python3.4 in their name.

Maybe keep python2.7?

Cheers
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] different set of colors for pairs

[Andreas Röhler]

Hi Georg, hi Barry,

Am 17.10.2013 22:44, schrieb Georg Brandl:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 17.10.2013 21:13, schrieb Andreas Röhler:

Hi Barry, hi all,

the OP says:

I want a different set of colors for the following pairs:

import and from def and class try and if. 

http://stackoverflow.com/questions/19374294/how-to-differentiate-between-colors-for-the-keywords-import-def-and-try-in/19374605#19374605

  which would should be possible to implement as an option.

In case, this should be the new default --or any other comments--, please
tell.


Just one comment: Why?

Not every wish on stackoverflow needs to be implemented.


Agreed.



Python has few enough keywords; if people really want Tokyo-style highlighting
they can add things to font-lock-keywords themselves.



IMO python-mode may provide what experienced developers need and beginners 
expect likewise - given the feature wanted will not go into the way of the real 
thing.

In this case it wouldn't, as the default would inherit the key-word face.

If we want to have more users and maybe developers, we must meet the wishes of 
beginners too - even if experience tells these wishes are not that justified to 
the extend.

BTW there are also experienced programmers preferring what you called 
Tokyo-style - while I'm with you in the precise question.

Adding things to font-lock-keywords themselves, that possibility is certainly 
at the core of Emacs.
Demonstrating the relative easiness of extending at SO should encourage further 
action by the OP.

Okay, thanks responding,

Hmm, Barry, did you veto it?

If you want to veto, please signal again,

otherwise just begging your pardon,

Cheers,

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] different set of colors for pairs

[Andreas Röhler]

Hi Barry, hi all,

the OP says:

I want a different set of colors for the following pairs:

import and from
def and class
try and if.


http://stackoverflow.com/questions/19374294/how-to-differentiate-between-colors-for-the-keywords-import-def-and-try-in/19374605#19374605

which would should be possible to implement as an option.

In case, this should be the new default --or any other comments--, please tell.

Andreas


___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] heuristic exit

[Andreas Röhler]

Hi Barry, hi all,

 lp:1235375 revealed a thing, which might happen in other circumstances also.

Bug occurred when which-func-mode was on and a string-delimiter missing.
In this case also indexing would fail.

There might be more circumstances like that, it's not just about a missing 
string-fence,
python-mode specific movements expect correct syntax.

In order to avoid movement-related routines go crazy, introduced a
  `py-max-specpdl-size', default is `max-specpdl-size',


  py-end-of-statement will error if number of
  `py-max-specpdl-size' loops is completed, thus avoiding
  a hang from a possibly eternal loop.

FYI,

Andreas
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] edit-style considering empty line

[Andreas Röhler]

Am 24.09.2013 08:45, schrieb Diez B. Roggisch:


On Sep 23, 2013, at 9:57 PM, Andreas Röhler andreas.roeh...@online.de 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.



___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

[Python-mode] edit-style considering empty line

[Andreas Röhler]

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
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Bug?

[Andreas Röhler]

Am 14.06.2013 23:20, schrieb Barry Warsaw:

On Jun 14, 2013, at 05:04 PM, Felipe Reyes wrote:

[ ... ]

I've been dealing with it and manually
adding another indentation level to not leave 'baz' aligned with 'baz()'

def foo():
if (foo 
baz):
bar()

Can this be considered a bug?


I think python-mode should be able to handle it, but it needs to be
configurable.

-Barry



It's here now:

https://bugs.launchpad.net/python-mode/+bug/1191225

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Menu simplified

[Andreas Röhler]

Hi all,

with r1224 a simplified menu is  provided. Maybe have a look.
It adapts version 5.2.0 style, a More button gives access to new and advanced 
features.

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Comparison of Python modes at SO

[Andreas Röhler]

Hi all,

whilst Stack Overflow usually cancels that kind of questions, this time they 
seem to take interest.

See

http://stackoverflow.com/questions/15670505/comparison-of-python-modes-for-emacs/15672445#15672445

Maybe an occassion to discuss directions of development?

Certainly, there is more than just one way to go,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python-mode menu

[Andreas Röhler]

Am 11.04.2013 22:25, schrieb Georg Brandl:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FWIW, I agree with the comments about the menu.

We even have electric commands in the menu -- WTF?
And I found a few duplicates, such as the Shift ... left/right entries.

Also, the shell selections has WAY too many choices.  Do we *really*
need an interactive command for every combination of run def/class/statement
for every of 8 (or so) interpreters?


Probably not the way it's done now. Will change that.



I appreciate that you want to accomodate every feature request, but
this seems to go too far.

On a related note, why do we have interactive functions for toggling lots
and lots of custom variables?


Will re-work the menu, so they are not visible unless searched for.

Thanks,

Andreas



cheers,
Georg

Am 02.04.2013 12:11, schrieb Andreas Röhler:

Hi all,

having look at the critics from link below, python-mode menu could get some
simplification indeed. Think will have some ideas what to do.

In case you have some requests too, it's welcome.

Andreas



 Original-Nachricht  Betreff: [Bug 1162893] [NEW] The
automatic indentation works against me. Datum: Mon, 01 Apr 2013 16:52:16
- Von: Jesse fibonacci...@gmail.com

If you take a look at this angry man's blog:
http://danielnouri.org/notes/2012/11/16/python-mode-gone-wrong/ you can see
an example of what I'm trying to describe.

[ ... ] ___ Python-mode mailing
list Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlFnHB4ACgkQN9GcIYhpnLCszACgi3dHX4/JNAQSTaPKPXdh9l+I
+pYAoJjdzgf2EyZt4DMNOWwzhG5hM0i2
=ZEnI
-END PGP SIGNATURE-



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] removing py-smart-operator-mode

[Andreas Röhler]

Hi Barry, hi all,

as smart-operator-mode is distributed via ELPA for some time now,
IMO it doesn't make sense to keep an python-mode version of it.

Unless some stuff has been built upon it.
So, if no objections arrive, consider to remove it.

Cheers,

Andreas



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el 6.1.1 released

[Andreas Röhler]

Hi folks,

python-mode.el-6.1.1 is available at

https://launchpad.net/python-mode/trunk/6.1.1/+download/python-mode.el-6.1.1.tar.gz

New in version 6.1.1
-

- comment-related commands:
  py-uncomment
  py-comment-block, py-comment-clause,
  py-comment-block-or-clause, py-comment-def,
  py-comment-class, py-comment-def-or-class,
  py-comment-statement

- boolean `py-set-fill-column-p'
  If `t', enables use Python specific `fill-column' according to
  `py-docstring-fill-column', default is 72
  and `py-comment-fill-column, default is 79

- boolean `py-tab-shifts-region-p'
  when `t', TAB will indent/cycle the region, not just the current line.

- boolean `py-tab-indents-region-p'
  when `t', when first TAB doesn't shift, `indent-region' is called

- command from RET customizable via `py-return-key':
  `py-newline-and-indent', `newline' or `py-newline-and-dedent'

- boolean `py-use-font-lock-doc-face-p', default is nil
  If non-nil, documention strings get `font-lock-doc-face'

- boolean `py-newline-delete-trailing-whitespace-p'
  Delete trailing whitespace maybe left by `py-newline-and-indent'

- `py-electric-comment-p' new default nil

- py-up minor API change
  If inside a delimited form --string or list-- go to it's beginning
  If not at beginning of a statement or block, go to it's beginning
  If at beginning of a statement or block, go to beginning one level above of c

- py-down minor API change:
  Go to beginning of one level below of compound statement or definition at 
point.
  If no statement or block below, but a delimited form --string or list-- go to 
it's beginning.
  Repeated call from there will behave like down-list.

- commands make underscore syntax changes easier:
  toggle-py-underscore-word-syntax-p
  py-underscore-word-syntax-p-on
  py-underscore-word-syntax-p-off

- py-update-imports removed
  Do not maintain a static variable containing needed imports
  Determine imports on the fly rather, as it might change
  the very moment

- variable `py-fill-docstring-style' renamed `py-docstring-style'

Enjoy,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [Bug 1102226] Re: py-shell-complete or ipython-complete doesn't work with emacs 24.1 and Windows

[Andreas Röhler]

Am 08.02.2013 05:27, schrieb Bruce Tulloch:

I can confirm this bug (or one very similar) exists on Emacs 24.2.1 on
Debian Wheezy with ipython 0.13.1. It looks like it's probably related
to bug 1027265 (Filename completion fails in ipython buffer) for which I
see a fix is reported committed. Any chance of this one being fixed and
released sooner than 6.2?



IMO it displays the limitations of the way Emacs stuff is developed, i.e. by 
exchanging code people
use itself basically.

Being well aware of that limitation, looking for people who are interested to 
change that.
Maybe you are?
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Python launcher (PEP 397) and emacs python-mode.el

[Andreas Röhler]

Am 31.01.2013 10:03, schrieb Thomas Heller:

Has someone managed to patch python-mode.el to use
the PEP 397 python launcher when you hit C-c C-c?

It seems that emacs should parse the shebang line in the edited
python script and pass the corresponding arguments to py.exe.



Yes, that's the way python-mode.el acts by default.

AFAIU that launcher is implemented in Python3.3 and should not need any patch 
at all.
Should it not work, please file a bug-report at

https://bugs.launchpad.net/python-mode

Andreas


Thomas





___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el-6.1.0 released

[Andreas Röhler]

python-mode.el-6.1.0 is available at

https://launchpad.net/python-mode/trunk/6.1.0/+download/python-mode.el-6.1.0.tar.gz

New in version 6.1.0
-

- py-up
  Go to beginning one level above of compound statement or definition at point.
- py-down
  Go to beginning one level below of compound statement or definition at point.

- Customizable output directory
  After checking for a remote shell, the following variables are consulted:

  py-use-current-dir-when-execute-p, default t
  When `t', current directory is used by Python-shell for output of 
`py-execute-buffer' and related commands

  py-fileless-buffer-use-default-directory-p, default t
  When `py-use-current-dir-when-execute-p' is non-nil and no buffer-file exists, 
value of `default-directory' sets current working directory of Python output 
shell

  py-keep-shell-dir-when-execute-p, default nil
  Don't change Python shell's current working directory when sending code.

  `py-execute-directory', default nil

  If nothing was set so far, $VIRTUAL_ENV and $HOME are queried.

- Set of commands calling Python3.3

- fill docstrings according to style, commands
  py-fill-string-django
  py-fill-string-onetwo
  py-fill-string-pep-257
  py-fill-string-pep-257-nn
  py-fill-string-symmetric

  Customizable variable `py-fill-docstring-style' provides default value
  used by `py-fill-string', `py-fill-paragraph'

  DJANGO:

  \\\
  Process foo, return bar.
  \\\

  \\\
  Process foo, return bar.

  If processing fails throw ProcessingError.
  \\\

  ONETWO:

  \\\Process foo, return bar.\\\

  \\\
  Process foo, return bar.

  If processing fails throw ProcessingError.

  \\\

  PEP-257:

  \\\Process foo, return bar.\\\

  \\\Process foo, return bar.

  If processing fails throw ProcessingError.

  \\\

  PEP-257-NN:

  \\\Process foo, return bar.\\\

  \\\Process foo, return bar.

  If processing fails throw ProcessingError.
  \\\

  SYMMETRIC:

  \\\Process foo, return bar.\\\

  \\\
  Process foo, return bar.

  If processing fails throw ProcessingError.
  \\\

  Built upon code seen at python.el, thanks Fabian

- `py-down-statement', `py-up-statement'

- toggle-py-split-windows-on-execute-p
- py-split-windows-on-execute-p-off
- py-split-windows-on-execute-p-on

- toggle-py-switch-buffers-on-execute-p
- py-switch-buffers-on-execute-p-on
- py-switch-buffers-on-execute-p-off

- `py-shell-switch-buffers-on-execute-p' renamed 
`py-switch-buffers-on-execute-p'



When encountering a bug or having a feature request, please file them at

https://bugs.launchpad.net/python-mode

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] buffer-named-shells?

[Andreas Röhler]

Hi Barry, hi all,

reflecting the question, how to proceed when executing a buffer which might 
result in a time-consuming run.

For now starting it in a dedicated process resp. shell is the solution.
These dedicated shell names however are machine-generated and hard to read 
resp. to remember.

Possible solutions:

- running a shell which is named after the buffer.
- combine the buffer-name with the dedicated name.

Opinions?

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] common mistakes

[Andreas Röhler]

Hi all,

coming across a site which complains the way and state of Emacs python-mode 
developing

http://synker.wordpress.com/2011/04/06/emacs-as-a-python-ide/

let me take the occassion to address some issues of
maybe general interest.

Certainly python-mode at it's present state has
it's limits and can be done much better. OTOH if you
consider other editors, they have shortcomings too,
albeit in maybe different areas.

So while it can be done better, the result seems is not
so bad at all in comparison.

Complaining the multitute of offerings, which requires
some choice, is a common mistake. Freedom means choice
and provokes it.

With resp. to the mentioned so called apparent
bitterness and it's outcoming, please compare the
capabilities of python-modes with others, with Bash or
Perl for example.

Without question we can be more polite and nice with
each other. But don't let you make that fear a strive
or even criminalise disput. We know that creativity
often is linked to a kind of unhappy behavior. We
should simply accept that and go on, enjoing the fruit
even from adorned crowns :)

BTW writing a python-mode IMHO meets some extra
difficulties due to Pythons use of indent as delimiter
- what's nice to look and use introduces some
complexity OTOH.

So after all, consider python-modes rather a story
of success than a failure.

IMHO we should go on, maybe still more outspokenly
welcome diversity than it's common now.

For me it's a pleasure to look into alternative
proceedings delivered by others. It's a source of
inspiration, of joy.

Andreas






___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el-6.0.12 released

[Andreas Röhler]

Hi Barry, hi all,

fastening Python edits while lowering the learning curve for beginners by 
PyEdit menu is the focus of this release.


New in version 6.0.12
-

- py-sexp-function,
  When set, it's value is called instead of `forward-sexp', `backward-sexp
  Choices are py-partial-expression, py-expression, default nil

- `py-partial-expression' reconsidered.
   Beside common moves like `defun', `statement' specific Python-mode edits are 
delivered:

  `py-expression' and `py-partial-expression'.

  Statement below is considered composed of two `py-expression'

  a = ['spam', 'eggs', 100, 1234]
  |_| |_|

  Assigment operator and all inside comments is ignored.

  `py-partial-expression' would match six sections

   a = ['spam', 'eggs', 100, 1234]
  |_|   |_|  || |__| |__|
   |_|

  When traversing code, `py-partial-expression' climbs down and up
  all levels encountered, i.e. at opening `[' `py-expression' would return 
['spam', 'eggs', 100, 1234], while one char behind at `''
  it yields `'spam','

- `py-find-definition' also detects non-imported definition in current buffer

- Choice between `py-imenu-create-index-new' and series 5.
  py-imenu-create-index-function made easier.
  Customizable variable `py-imenu-create-index-function' provided, see also
  command in PyTools

- New commands addressing BOL as start/end:
  py-beginning-of-block-bol
  py-end-of-block-bol
  py-mark-block-bol
  py-copy-block-bol
  py-kill-block-bol
  py-delete-block-bol
  py-end-of-clause-bol
  etc.

- While commands py-beginning... resp. py-end... compute the context,
  selecting the corresponding beginning or end,
  new py-up..., py-down... jump regexp-based to the
  next element in buffer.
  See also menu PyEdit


Thanks to all contributors,
Thanks Urs, making Pymacs-based py-complete more smart py-complete again,

enjoy,

Andreas



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] coverage and tests

[Andreas Röhler]

Am 21.08.2012 23:20, schrieb Andrea Crotti:

So one thing which would be awesome to have is the ability to see which lines 
are not tested while I'm writing
my code...

There is already an extension here but I could not get it working
https://github.com/mattharrison/pycoverage.el

At the moment what I do is simply to to set in .dir-locals.el the 
compile-command that I want to run,
but then I always have to check the html page to see the report..

  (python-mode
   (compile-command . nosetests -sv --with-cov --cov-report=html))

Anyone else interested? Maybe we can get the pycoverage working and integrate 
it?


thanks

https://blueprints.launchpad.net/python-mode/+spec/coverage-and-tests
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] NEWS file

[Andreas Röhler]

Hi,

when introducing extensions, please consider updating NEWS file also.

It serves as a kind of changelog, base of announcements.

thanks all,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [Branch ~ufleisch/python-mode/improve-completion] Rev 1542: Support completion of list, dict and str literals.

[Andreas Röhler]

Am 14.07.2012 12:37, schrieb nore...@launchpad.net:

- (symbol (py-symbol-near-point))
+ (symbol (py-complete-enhanced-symbol-before-point))



Hi Urs,

some reflections on naming - cc to Barry and python-mode list, as is seems of 
general interest and opinions may differ.

- prefix py-complete

Suggest to use complete as part of a name only, if completion is really at 
stake.

- replacing symbols

in case, you drop/replace are function completely as with `py-symbol-near-point'

please take in consideration, it might be used by third party stuff.
Please be as conservative as possible, rather keep the symbol with new body if 
needed.

With great joy seeing python-mode proceeding,

Andreas



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] freezed branches

[Andreas Röhler]

Am 06.07.2012 21:25, schrieb Barry Warsaw:

On Jul 06, 2012, at 08:35 PM, Andreas Röhler wrote:


in case a distro shipping python-mode.el declares a freeze, we may meet that
creating a freezed branch mentioning that distro or release name

Then developing might go on in trunk, whilst the freeze is honoured.


I probably wouldn't tie a branch to any specific distro.  That's setting a bad
precedence that could potentially add lots of extra work if other distros want
the same treatment.

Instead, you could tie branches to python-mode version series.  E.g. You could
branch for 6.0.x and then 6.1.x would be developed on trunk.  Just be cautious
about any bug fixes you backport to the 6.0.x branch and don't backport any
new features.  It would then be up to distro's package maintainer ahem to
cherry pick fixes from the appropriate branch during the lifetime of the
stable distro release.

Cheers,
-Barry



okay, thanks,

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [PATCH] Improved pycomplete

[Andreas Röhler]

Am 01.07.2012 15:04, schrieb Urs Fleisch:

Hi,

Here is a little patch, which fixes the following problems in pycomplete:

py-find-global-imports(): Support dot in from ... import statements,
e.g. from PyQt4.QtGui import QMainWindow.

get_all_completions(): Return an empty list when no symbol is found
(e.g. when trying to complete [].ap).

Then I have integrated a few changes ported from the current version
in http://www.rwdev.eu/articles/emacspyeng:

py-complete(), get_all_completions(): Additional except statements
when calling eval, exec and __import__, checks if symbol is empty.

pycomplete(): Change to directory where file is, so that relative
imports also work when file is not in the current directory of the
Python interpreter.

Is it OK to send patches like this, or would you prefer an attachment
or a bzr merge request?

Regards,
Urs


Hi,

thanks a lot for the patch.
If you might open a ticket at

https://bugs.launchpad.net/python-mode

 for it, the patch attached, that would help still, as it's easier to refer.

Alternatively a branch and merge request are fine also.

Andreas






=== modified file 'completion/pycomplete.el'
--- completion/pycomplete.el2012-05-10 11:19:31 +
+++ completion/pycomplete.el2012-07-01 11:42:53 +
@@ -49,7 +49,7 @@
(goto-char (point-min))
(setq imports nil)
(while (re-search-forward
- ^\\(import \\|from \\([A-Za-z_][A-Za-z_0-9]*\\) import \\).*
+ ^\\(import \\|from \\([A-Za-z_\\.][A-Za-z_0-9\\.]*\\) import 
\\).*
  nil t)
(setq imports (append imports
  (list (buffer-substring
@@ -62,7 +62,7 @@
(let* ((pymacs-forget-mutability t)
   (symbol (py-symbol-near-point))
   (completions
-  (pycomplete-pycomplete symbol
+  (pycomplete-pycomplete symbol (buffer-file-name)
   (py-find-global-imports
  (cond ((null completions) ; no matching symbol
 (message Can't find completion for \%s\ symbol)

=== modified file 'completion/pycomplete.py'
--- completion/pycomplete.py2012-05-10 11:19:31 +
+++ completion/pycomplete.py2012-07-01 12:12:23 +
@@ -59,6 +59,8 @@
  exec stmt in globals(), locald
  except TypeError:
  raise TypeError, invalid type: %s % stmt
+except Exception:
+continue

  dots = s.split(.)
  if not s or len(dots) == 1:
@@ -77,6 +79,8 @@
  sym = None
  for i in range(1, len(dots)):
  s = ..join(dots[:i])
+if not s:
+continue
  try:
  sym = eval(s, globals(), locald)
  except NameError:
@@ -84,11 +88,23 @@
  sym = __import__(s, globals(), locald, [])
  except ImportError:
  return []
+except AttributeError:
+try:
+sym = __import__(s, globals(), locald, [])
+except ImportError:
+pass
  if sym is not None:
  s = dots[-1]
  return [k for k in dir(sym) if k.startswith(s)]
-
-def pycomplete(s, imports=None):
+return []
+
+def pycomplete(s, fname=None, imports=None):
+if not s:
+return ''
+# changes to where the file is
+if fname:
+os.chdir(os.path.dirname(fname))
+
  completions = get_all_completions(s, imports)
  if len(completions) == 0:
  return None
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode




___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [PATCH] Improved pycomplete

[Andreas Röhler]

Am 01.07.2012 16:19, schrieb Urs Fleisch:

Hi,


If you might open a ticket at

https://bugs.launchpad.net/python-mode

   for it, the patch attached, that would help still, as it's easier to refer.


OK, I have opened a bug: https://bugs.launchpad.net/python-mode/+bug/1019791.

I have another little patch, not related to a bug, rather an improvement.
It provides functions py-complete-define-ac-source(), 
py-complete-define-company-completion() to integrate pycomplete into 
auto-complete or company, so that the completions are displayed in a nice popup.

Regards,
Urs




Hi,

thanks a lot, that's quite interesting.
If your time permit, please make a now branch related to company.

Best,

Andreas



As we have several options to realise auto-completion,



=== modified file 'completion/pycomplete.el'
--- completion/pycomplete.el2012-07-01 13:05:48 +
+++ completion/pycomplete.el2012-07-01 13:21:44 +
@@ -78,4 +78,50 @@
   (display-completion-list completions))
 (message Making completion list...%s done)

+(defun py-complete-completions ()
+  get possible completions for current statement
+  (pycomplete-get-all-completions
+   (py-symbol-near-point)
+   (py-find-global-imports)))
+
+(defun py-complete-define-ac-source ()
+  Define ac-source-pycomplete to be used with auto-complete.
+
+The ac-source can be enabled solely using
+(setq ac-sources '(ac-source-pycomplete))
+or before the other sources using
+(add-to-list 'ac-sources 'ac-source-pycomplete).
+  (require 'auto-complete)
+  (ac-define-source pycomplete
+'((candidates . py-complete-completions
+
+(defun py-complete-define-company-completion ()
+  Define company-pycomplete function to be used with company.
+
+The function can be enabled using
+(setq company-backends '((company-pycomplete))).
+  (require 'company)
+  (defun company-pycomplete--grab-symbol ()
+(let ((symbol (company-grab-symbol)))
+  (when symbol
+(cons symbol
+  (save-excursion
+(let ((pos (point)))
+  (goto-char (- (point) (length symbol)))
+  (while (eq (char-before) ?.)
+(goto-char (1- (point)))
+(skip-syntax-backward w_))
+  (- pos (point
+  (defun company-pycomplete (command optional arg rest ignored)
+A `company-mode' completion back-end for pycomplete.
+(interactive (list 'interactive))
+(case command
+  ('interactive (company-begin-backend 'company-pycomplete))
+  ('prefix (and (derived-mode-p 'python-mode)
+buffer-file-name
+(not (company-in-string-or-comment))
+(company-pycomplete--grab-symbol)))
+  ('candidates (py-complete-completions
+  )
+
  (provide 'pycomplete)





___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] modeline Py or Python

[Andreas Röhler]

Hi Barry, hi all,

presently modeline displays Python if Python-mode is on.

As space is precious in modeline, what about offering Py as default instead?

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Emacs Remote Python Interpreters

[Andreas Röhler]

Am 04.06.2012 22:57, schrieb Matt McClure:

I'd like to use Emacs as my IDE for a Python project as follows:

1. Emacs running on a Mac host machine.
2. Python running on a Linux guest VM.
3. A single copy of the code shared between the host and guest
machines via NFS or VirtualBox shared folder.

Emacs on the host machine would use the guest VM's Python interpreter
for all execution, including code completion and debugging. I imagine
using directory-local variables to configure a remote Python
interpreter and a mapping between the respective host and guest
filesystem path prefixes.

What I'm looking for is pretty similar to [PyCharm's remote python
interpreters][1]. Has anyone built something similar for Emacs, for
Python environments or for any other language? I built a little
[prototype][2], but it's just a toy so far.

[1]: 
http://www.jetbrains.com/pycharm/webhelp/configuring-remote-python-interpreters.html
[2]: https://github.com/matthewlmcclure/emacs-remote-python



noted at

https://blueprints.launchpad.net/python-mode/+spec/remote

thanks,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el 6.0.8 released

[Andreas Röhler]

Hi Python-mode folks,

several code checkers now are accessable from menu PyTools

Special thanks to

Keegan Carruthers-Smith
http://people.cs.uct.ac.za/~ksmith/2011/better-python-flymake-integration-in-emacs.html

and

Reinout van Rees
http://reinout.vanrees.org/weblog/2010/05/11/pep8-pyflakes-emacs.html

Errors are mine.

Should you miss a checker - pyflakes, pylint, or pep8

just run `easy_install THIS-TOOL'


New in version 6.0.8


- `py-pep8-run', new command checking formatting
   `py-pep8-help'

- `py-pyflake-run', new command
   Pyflakes is a simple program which checks Python
   source files for errors. - It is similar to
   PyChecker in scope, but differs in - that it does
   not execute the modules to check them.
   `py-pyflake-help'

- `py-pylint-run', new command calls Pylint,
  a Python source code analyzer which looks for
  programming errors, helps enforcing a coding standard
  and sniffs for some code smells (as defined in Martin
  Fowler's Refactoring book) .

  Pylint checks length of lines of code, if variable
  names are well-formed according to your coding
  standard, if declared interfaces are truly
  implemented, and much more. Additionally, it is
  possible to write plugins.
  `py-pylint-doku', `py-pylint-help'

- py-pyflakespep8-run, combines calls to pyflakes and pep8

- respective flymake-modes,
  `pyflakespep8-flymake-mode', `pylint-flymake-mode'
  etc. See meny PyTools

Enjoy,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python-mode.el 6.0.8 release

[Andreas Röhler]

here still the link

https://launchpad.net/python-mode/trunk/6.0.8/+download/python-mode.el-6.0.8.tar.gz
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] dropping py-temp-directory, py-custom-temp-directory?

[Andreas Röhler]

Hi Barry, hi all,

came upon this question when looking for

https://blueprints.launchpad.net/python-mode/+spec/flymake

As Emacs has already a customizable

temporary-file-directory

this vars look pretty redundant.

Consider dropping them, leaving some defalias for backward compatibility
resp. XEmacs provision

Unless we have some use-case for a Python-mode specific temp-dir...

Cheers,

Andreas




___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Python Components Mode vs Python Mode

[Andreas Röhler]

Am 19.04.2012 16:53, schrieb Jeffrey Spencer:

I've been away for awhile but now confused because updated both branches.
It seems like components mode just splits the python-mode.el file up into
various components (ones listed with python-components). Also includes a
couple other packages in the components mode. All the python components are
just included in the python-mode.el in the other branch with the extra
programs removed.

Is this correct? Sorry for the stupid question but didn't find an
explanation on launchpad.






Hi Jeffrey,

at lp it's told that way:

#
If you can, please check against current trunk or development branch.
Get it via download button from code page or the archive with bazaar command

bzr branch lp:python-mode
or
bzr branch lp:python-mode/components-python-mode
#

will add behind the or some hint of development.

thanks pointing at,

Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el testbot

[Andreas Röhler]

Hi Barry, hi all,

IMO it's time to set up a testbot, which should do the check for all the 
different flavors of Python, completion possibilities etc. out there.

Have some idea how and where to do - nonetheless would like to reflect some 
suggestions/recommendations.

Would be great to have a tool which mails back the results.

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] trying to upgrade

[Andreas Röhler]

Am 08.04.2012 23:09, schrieb Glenn Linderman:

On 4/7/2012 11:41 PM, Andreas Röhler wrote:

Am 08.04.2012 01:54, schrieb Glenn Linderman:

Hi Andreas, et alia,

Slowly the wheels turn, and progress is made. And then there are bumps in the 
road. This is probably a bump.




You might recall that I was stuck on an old version of emacs because of 
incompatibilities newer versions had with AutoHotKey. It was more important for 
me to be compatible,
than to run the latest emacs. Then recently I discovered the beta emacs is now 
compatible with AutoHotKey again, at least, as much as the old version was 
(there are still
some issues, but they are not new).

So references here are to this emacs:

GNU Emacs 24.0.93.1 (i386-mingw-nt6.1.7601)
of 2012-02-15 on MARVIN

So I upgraded to the above new emacs, and now am upgrading to the new 
python-mode.el. I was running python-mode.el 6.0.2 and I see 6.0.5 is now the 
latest version, so I
downloaded it, tweaked my load-path to point to the new one, and opened a quite 
valid, successfully executing Python 3 source file.

The following error appeared in the minibar:

Error in menu-bar-update-hook (imenu-update-menubar): (error Lisp nesting 
exceeds `max-lisp-eval-depth')


Hi Glenn

might be related to some indexing issue.

customize py-imenu-create-index-p to nil should avoid this anyway.

I'm testing with Emacs24 too from time to time and it passed as Emacs23 so far.

Nonetheless Emacs24 got some major changes and has some issues still.
Unless actively developing it, recommend Emacs23 for all productive work.

As for the rest, let's try to solve the knot by doing it one by one.

- disable all optional features as outline-mode - customize 
py-outline-minor-mode-p nil


If you still encounter some issues with latest release, please send an example 
file which triggers it, resp. make a bug report.

Best regards,

Andreas


Your suggestions sound good. Since they didn't look like elisp syntax, I tried 
the menus, Options / Customize Emacs / Programming / Languages / Python ... but 
couldn't
guess where to go next.

So I apologize, I am unable to intuit elisp syntax from the above prose, nor 
guess my way into the customize tree to find them. Can you be more explicit on 
what to do to
turn of the options that might bypass these symptoms? I don't grok much of the 
elisp parenthesis soup, I'm just an emacs user with a bit of .emacsrc 
cut-n-paste ability.



IMO Python-mode should be useable from Menu alone, so far your experience is 
quite precious.
Please make an entry at

https://answers.launchpad.net/python-mode

with something like How to customize `py-imenu-create-index-p' from 
Emacs/Python-mode menu?

the answer should go into some FAQ later





As for emacs 24, I am no emacs developer, but I cannot use emacs 22 or 23 due 
to incompatibilities with AutoHotKey, and 21 works fine for me for normal 
things, but is maybe
too old for the latest python-mode, since you were not able to reproduce 
problems I had in the past. So it is 21 or 24, which, if either, can you 
support with python-mode?
Maybe it is premature to use 24, but I am supposing, unless you declare 
otherwise, that it is much more interesting to add support for 24 into 
python-mode than to support
21...



okay, sounds reasonable then.

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] trying to upgrade

[Andreas Röhler]

Am 08.04.2012 01:54, schrieb Glenn Linderman:

Hi Andreas, et alia,

Slowly the wheels turn, and progress is made. And then there are bumps in the 
road. This is probably a bump.




You might recall that I was stuck on an old version of emacs because of 
incompatibilities newer versions had with AutoHotKey. It was more important for 
me to be compatible,
than to run the latest emacs. Then recently I discovered the beta emacs is now 
compatible with AutoHotKey again, at least, as much as the old version was 
(there are still
some issues, but they are not new).

So references here are to this emacs:

GNU Emacs 24.0.93.1 (i386-mingw-nt6.1.7601)
of 2012-02-15 on MARVIN

So I upgraded to the above new emacs, and now am upgrading to the new 
python-mode.el. I was running python-mode.el 6.0.2 and I see 6.0.5 is now the 
latest version, so I
downloaded it, tweaked my load-path to point to the new one, and opened a quite 
valid, successfully executing Python 3 source file.

The following error appeared in the minibar:

Error in menu-bar-update-hook (imenu-update-menubar): (error Lisp nesting 
exceeds `max-lisp-eval-depth')


Hi Glenn

might be related to some indexing issue.

customize py-imenu-create-index-p to nil should avoid this anyway.

I'm testing with Emacs24 too from time to time and it passed as Emacs23 so far.

Nonetheless Emacs24 got some major changes and has some issues still.
Unless actively developing it, recommend Emacs23 for all productive work.

As for the rest, let's try to solve the knot by doing it one by one.

- disable all optional features as outline-mode - customize 
py-outline-minor-mode-p nil


If you still encounter some issues with latest release, please send an example 
file which triggers it, resp. make a bug report.

Best regards,

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode.el-6.0.5 released

[Andreas Röhler]

Hi all,

release of python-mode.el-6.0.5 is done at

https://launchpad.net/python-mode/trunk/6.0.5/+download/python-mode.el-6.0.5.tar.gz

Please send bug reports resp. request features to

https://bugs.launchpad.net/python-mode

Changes coming with this version:

- Menu is reworked and extended

-  commands combine executing statement/block... with dedicated/switch... etc. 
This may remove some need of customization.

- local environments support started
  If calls to common `py-shell' should use local executable
  instead of default system Python set
  `py-use-local-default' alongside wit
  `py-shell-local-path'

- `py-toggle-shells' alias of more powerful `py-switch-shells'
  Toggles between the interpreter customized in `py-shell-toggle-1' resp. 
`py-shell-toggle-2'.
Was hard-coded CPython and Jython in earlier versions, now starts with Python2 
and Python3 by default.

- `py-shell-name' accepts PATH/TO/EXECUTABLE
  in addition to name of an installed default Python-Shell.
  Permits installing commands like
  (defun python-XYZ-shell (optional argprompt)
Start an Python-XYZ interpreter ... 
(interactive)
(let ((py-shell-name PATH/TO/PYTHON-XYZ))
  (py-shell argprompt)))

-  new commands `indent-tabs-mode', `toggle-indent-tabs-mode',
  `indent-tabs-mode-on', `indent-tabs-mode-off'

  feature after a request at Stack Exchange asked Jul
  13 '11 at 13:23 saying
  `tab-width' now follows `py-indent-offset'

- new command `py-execute-region-default' forces the
  systems default Python interpreter to execute, ignores
  shebang

- new `py-number-face',
  visible only when customized and `py-use-number-face-p' is `t',
  inherits default face
  With large files fontifying numbers may cause a delay
  Credits to github.com/fgallina/python.el/issues42

- new boolean `py-verbose-p'
  if `t', reached indent level etc. is messaged

- `toggle-py-smart-indentation' new command
   also `py-smart-indentation-on', -off

Enjoy,

Andreas

--
http://launchpad.net/python-mode
http://launchpad.net/s-x-emacs-werkstatt/
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] Fwd: [Question #189464]: How to run __main__ programs inside python-mode?

[Andreas Röhler]

New question #189464 on python-mode.el:
https://answers.launchpad.net/python-mode/+question/189464

I'm probably missing something obvious, but what's the best way to use 
python-mode to run/debug python scripts that are designed to be run from 
the command line? In particular, the problem I face is that while 
__main__ is set fine, if my code tries to access sys.argv, it gets 
information that is not very useful, e.g.,


In [5]: sys.argv
Out[5]: ['/Library/Frameworks/EPD64.framework/Versions/7.2/bin/ipython', 
'-i']


I could always write a main() function, set up my own argument list, and 
then call main(myargs), or something similar, but this isn't so 
convenient when all I want to do is run someone else's sample code.


How do others deal with this? Is there a facility in python-mode (or 
should there be) to pass a user-defined sys.argv to scripts run by 
pressing C-c C-c?




___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] win-32

[Andreas Röhler]

Am 01.03.2012 10:54, schrieb Eric S. Johansson:

imenu-add-to-menu-bar: imenu-create-index-function
=py-imenu-create-index-new
File mode specification error: (file-error Searching for program no
such file or directory python)

finally getting back to doing some Python work. I grabbed the latest off
of launchpad and installed in win32 Emacs (23.1). I got the above error
when I loaded the file. From searching the net, it looks like I need to
define a Python interpreter. Is this still correct?


Hi Eric,

would consider that a bug. Python code should be editable also if no 
Python installed - with some restrictions at least.


May I ask you for a complete report starting from emacs -Q?

Thanks for your help,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] huge files

[Andreas Röhler]

[ ... ]

much less intimidating to try to grasp,

[ ... ]



Added a README.DEVEL, indicating some entry point
for people who want to dig into the code.

Cheers,

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] huge files

[Andreas Röhler]

Am 14.02.2012 22:31, schrieb Andrea Crotti:

It looks like it's a common problem in the Elisp world, but I was
wondering is it normal to have huge source files.

python-mode.el is  10k lines now, which for me causes two problems:
- it's hard to even know the various functionalities
- it's hard to manage the file

I see various things that could be very easily splitted
- virtualenv
- ipython
- pdbtrack (maybe)
- defcustom-defvar (or maybe better by topic taking the variables together)

and probably more.
Since it doesn't do any difference in terms of performance and it's
much less intimidating to try to grasp, is there a reason to keep all in
one big file?


think it's basically historical.

People interested in developing/understanding might check out and use 
the components branch


https://code.launchpad.net/~a-roehler/python-mode/components-python-mode

I'm doing all my developing and Python editing there.
It's sometimes ahead several days, if new features are introduced. But 
the same tests are run before commits, so a possible loss in stability 
is mince.


BTW in future we could create a declared stable branch of components and 
make two tarballs for release.


CC to Barry for this question.

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] huge files

[Andreas Röhler]

Am 15.02.2012 13:57, schrieb Barry Warsaw:

On Feb 15, 2012, at 09:34 AM, Andreas Röhler wrote:


think it's basically historical.

People interested in developing/understanding might check out and use the 
components branch

https://code.launchpad.net/~a-roehler/python-mode/components-python-mode

I'm doing all my developing and Python editing there.
It's sometimes ahead several days, if new features are introduced. But the same 
tests are run before commits, so a possible loss in stability is mince.

BTW in future we could create a declared stable branch of components and make 
two tarballs for release.


I've always thought that because python-mode.el is a separate download, it's
better to have one big file.  This makes it easier for users to add it to
their Emacsen, even though it makes it more difficult to maintain, as rightly
observed.

But maybe we're at the tipping point where that trade-off should go the other
way.  Good, discoverable, installation documentation would go a long way
toward alleviating those concerns.  I run python-mode out of the bzr trunk, so
I'm probably not a good use case.

In a very real sense, this is Andreas's decision now.  He who does the work,
decides and Andreas has for quite a while now assumed primary ownership on
the code, by virtue of his great work on the mode.  I have no place to stand
in the way of his decision on this.

Cheers,
-Barry


thanks looking with patience at my endeavors :)

Changed the intro note at lp, which mentions now a developing branch 
beneath the trunk.


Concerning the one-file-solution see the pro at the users side.

BTW as for patches sent, the branch wouldn't be of importance so far. 
The only point is the being against a current revision.



Cheers,

Andreas




___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] menu item names

[Andreas Röhler]

Am 08.02.2012 16:17, schrieb François Pinard:

Jeff Bauerjba...@rubic.com  writes:


On Wed, Feb 08, 2012 at 09:56:23AM +0100, Andreas Röhler wrote:



PyIndex
PyShell
PyTools
PyCommands



  +1


PyCommands is a bit longish visually, and the name does not give a big
clue that it gives a menu for the Python mode proper.  Could it be
something like `Python' or `PyMode' maybe?  I'm not fully satisfied, but
do not have a better idea.

François



what about moving the exec stuff into now PyShell, renaming PyShell PyExec

than PyCommands might be renamed PyEdit

?

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] menu item names

[Andreas Röhler]

Am 08.02.2012 16:07, schrieb Barry Warsaw:

On Feb 08, 2012, at 09:56 AM, Andreas Röhler wrote:


being pointed at some irregularity menu items now display,
what about to rename it that way:

PyIndex
PyShell
PyTools
PyCommands

(?)
BTW PyShell still should take the virtualenv stuff, when ready


What are menus? :)

Seriously, I have little useful feedback, as I disable all Emacs menus.



when ready, it should deliver a nice reference also for the experienced 
user.


but wait... :)


Cheers,
-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] py-ask-about-save

[Andreas Röhler]

Hi,

exists a boolean variable

(defcustom py-ask-about-save t
  If not nil, ask about which buffers to save before executing some code.
Otherwise, all modified buffers are saved without asking.

;;

this rather nags me. Saving all buffer unconditional is probably 
terrible, OTOH always get questioned by `t'


Will change the implementation into

 If not nil, ask about which buffers to save before executing some code.
Otherwise do nothing.

Opinions?

Cheers,

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode