Re: [Python-mode] python-mode.el checkout
Am Mittwoch, 7. Mai 2008 02:19 schrieben Sie: Andreas could someone tell me please, how to check out last Andreas python-mode.el? Something like this: svn co https://python-mode.svn.sourceforge.net/svnroot/python-mode/trunk/python-mode python-mode If you'd like checkin privileges, send me your SF id. I'll look for that for next time. There's also a mailing list: Inscribed. http://mail.python.org/mailman/listinfo/python-mode Skip Herewith the patch Introduced an additional check for being not-in-string: (not (numberp (nth 3 state))) Thanks Andreas Röhler diff -u -b /old/python-mode.el /new/python-mode.el --- /old/python-mode.el 2008-05-07 08:05:55.0 +0200 +++ /new/python-mode.el 2008-05-08 15:28:35.0 +0200 @@ -3522,7 +3522,7 @@ (setq searching nil) ; search is done either way (setq state (parse-partial-sexp start (match-beginning 0))) - (setq answer (not (nth 4 state) + (setq answer (and (not (numberp (nth 3 state)))(not (nth 4 state)) ;; search failed: couldn't find another interesting colon (setq searching nil))) answer))) Diff finished. Thu May 8 15:29:02 2008 ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [CEDET-devel] python
Eric M. Ludlam wrote: Vladimir Kazanov vkaza...@inbox.ru seems to think that: Probably off topic, but just in case you are not aware of, *ropemacs* supports Python very well under Emacs. Cheers, poppyer Well... Could you redirect me to a more suitable mailing list then? I do have and actively use pymacs/ropemacs, but wouldn`t it be better to use a single system for various languages? Consistency is important, after all. [ ... ] Hi, I'm not that familiar with Python or pymacs/ropemacs. If these tools provide some sort of file parsing, tag searching feature, then they could plug into the back-end of the semantic parsing/searching tools. The ideal is that any tool that can supply tagging information would plug into CEDET. Then anyone who has a cool completion UI idea would implement it on top of CEDET. In that way the users would get the best of the tagging and their favorite completion UI styles instead of having something slightly different for every language they use. If someone wants to tackle a project of improving the python support I'd be happy to help. Eric Hi Eric, hi Vladimir, hi all, I'm taking part in developing python-mode.el, which has a mailing-list at its own, (see cc) its run by Barry Warsaw. python-mode.el is designed for all Emacsen. We take interest in any python-related topic with Emacs. So please feel free to cc or adress us with your questions, even if not python-mode.el specific. Thanks Andreas Röhler -- http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files https://code.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: Re: python setup ?]
Hi Barry, as some questions about Emacs and python are raised, I forward that here. Tend to delete all files beside python-mode.el from my branch. Good idea? Agreed? Andreas ---BeginMessage--- Andreas Röhler andreas.roeh...@easy-emacs.de writes: Richard Riley wrote: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Richard Riley wrote: Richard Riley rileyrg...@googlemail.com writes: Xavier Maillard x...@gnu.org writes: Hi, I am starting to do some work with python. I am looking for options/setups to introduce into my .emacs file to have the best experience possible with this scripting language. Where should I start ? Regards Xavier I played with some python options last year and it was, unfortunately, rather messy. There were some conflicts between packages any python versions. For what its worth, the following was working back when with emacs 23: http://www.emacswiki.org/emacs/PythonMode#toc11 http://richardriley.net/projects/emacs/dotprogramming#sec-1.3 It includes autocompletion from autocomplete using pysmell. Another possible integration for eclim and the eclipse engine I would have thought. The iPython bit is commented out - I can't remember why off the top of my head. The pymacs git repository seems dead too unfortunately. The python-mode used is 5.1.0. Just to follow up, I re-enabled the ipython bit and it worked fine. I had ipython 0.9.1 installed. The python config (for Linux) is then done in ~/.ipython/ipy_user_conf.py Hi, I've changed python-mode a little bit. Purpose was to make movements a little bit easier, more predictible. Comments welcome. BTW have a look at pydb from Rocky Bernstein, if not done already. Andreas I see you have a pycomplete. Nicholaj Schum has jus put together a company mode backend for pysmell. How does pycomplete compare to pysmell? Thats part of the package kept by Barry Warsaw. Made a branch from it, but changed only python-mode.el. I'm not sure to keep this files in my branch or not. Nonetheless, thanks for your question. I shall have a look at it and try an answer next days. BTW as more things are at stake as python-mode.el, what would you think about an archiv emacs-python, where all the stuff to edit python-code with emacs is collected? To be honest, my feeling is that the last thing anyone needs is yet another python place. The wiki is already a mess of questions and answers and mode specific difficulties. Tie that in with emacs 23/22 and ipython or not, the numerous ways you can do python completion etc, it needs to be simplified not extended. Thanks for the heads up about pydb btw, nice. For me Launchpad seems perfect for such a thing with its email- and bug-report-integration. There we could discuss the probably best emacs-python configuration - which will change, if someone brings up new things. I think the emacs wiki is best for this stuff purely because its there and there are numerous utilities to integrate emacs with emacs wiki pages. Just keep links to relevant pages. You might be right : point the wiki to launchpad and remove all the out of date stuff. What do others think? Andreas -- http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files https://code.launchpad.net/s-x-emacs-werkstatt/ -- ---End Message--- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Fwd: Re: python setup ?]
Barry Warsaw wrote: On Apr 27, 2009, at 8:41 AM, Andreas Röhler wrote: as some questions about Emacs and python are raised, I forward that here. Tend to delete all files beside python-mode.el from my branch. Good idea? Agreed? I generally leave the other files there, but only use python-mode.el. -Barry The point is, I don't really understand until now, if I should branch these files into my repo or not. Sure, you should keep it. Or better to say: we should keep a general repo for python-tools written so far. OTOH, while developing certain files, we must not clone the whole repo. Or must we because of zar bazaars will? Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] [Fwd: Re: python setup ?]
Hi Thierry, thanks for the help. Forwarded it to python-mode@python.org and will see, if we get it into the archive at launchpad. (BTW seeing no contradiction towards emacs-wiki, just different tools /possibilities. Vive la difference!) Andreas ---BeginMessage--- Hi Richard, Richard Riley rileyrg...@googlemail.com writes: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Richard Riley wrote: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Richard Riley wrote: Richard Riley rileyrg...@googlemail.com writes: Xavier Maillard x...@gnu.org writes: Hi, I am starting to do some work with python. I am looking for options/setups to introduce into my .emacs file to have the best experience possible with this scripting language. Where should I start ? Regards Xavier I played with some python options last year and it was, unfortunately, rather messy. There were some conflicts between packages any python versions. For what its worth, the following was working back when with emacs 23: http://www.emacswiki.org/emacs/PythonMode#toc11 http://richardriley.net/projects/emacs/dotprogramming#sec-1.3 It includes autocompletion from autocomplete using pysmell. Another possible integration for eclim and the eclipse engine I would have thought. The iPython bit is commented out - I can't remember why off the top of my head. The pymacs git repository seems dead too unfortunately. The python-mode used is 5.1.0. Just to follow up, I re-enabled the ipython bit and it worked fine. I had ipython 0.9.1 installed. The python config (for Linux) is then done in ~/.ipython/ipy_user_conf.py Hi, I've changed python-mode a little bit. Purpose was to make movements a little bit easier, more predictible. Comments welcome. BTW have a look at pydb from Rocky Bernstein, if not done already. Andreas I see you have a pycomplete. Nicholaj Schum has jus put together a company mode backend for pysmell. How does pycomplete compare to pysmell? I use this actually: http://article.gmane.org/gmane.emacs.help/50837/match=pycomplete That is the only pycomplete that work fine for me, it's really nice, the author should put it on emacswiki or send it as a patch for python-mode package. The pycomplete that come with python-mode doesn't work for me. I don't know pysmell, and i don't use company, auto-complete etc... Thats part of the package kept by Barry Warsaw. Made a branch from it, but changed only python-mode.el. I'm not sure to keep this files in my branch or not. Nonetheless, thanks for your question. I shall have a look at it and try an answer next days. BTW as more things are at stake as python-mode.el, what would you think about an archiv emacs-python, where all the stuff to edit python-code with emacs is collected? To be honest, my feeling is that the last thing anyone needs is yet another python place. The wiki is already a mess of questions and answers and mode specific difficulties. Tie that in with emacs 23/22 and ipython or not, the numerous ways you can do python completion etc, it needs to be simplified not extended. Thanks for the heads up about pydb btw, nice. For me Launchpad seems perfect for such a thing with its email- and bug-report-integration. There we could discuss the probably best emacs-python configuration - which will change, if someone brings up new things. I think the emacs wiki is best for this stuff purely because its there and there are numerous utilities to integrate emacs with emacs wiki pages. Just keep links to relevant pages. You might be right : point the wiki to launchpad and remove all the out of date stuff. What do others think? Andreas -- http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files https://code.launchpad.net/s-x-emacs-werkstatt/ -- A + Thierry Volpiatto Location: Saint-Cyr-Sur-Mer - France ---End Message--- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Xavier Maillard wrote: Hi, Richard Riley wrote: The python-mode used is 5.1.0. I've changed python-mode a little bit. Purpose was to make movements a little bit easier, more predictible. Easier, how easier ? What is so difficult with the default bindings ? (serious questions). Hi Xavier, well, what means easier? Our personal notion about whats best or fittest not always is acknowledged by others obviously. Tastes differ. From that I mean its better not just to look for the one-and-all solution, but to offer flavors of modes, so people have the choice. Thats already done with perl-mode and cperl-mode for example. Nonetheless, the one-and-all idea seems deep-rooted not just in religion. With python-mode.el, people may have good reasons, to use it as it is - and me to leave it as it is. Thats fine with bazaar and other DVCs, we can do that. My branch doesn't hamper the origin and any further branch will not. Its just freedom to try and see. Branch orginated from some request, to close forms more definitely, more specific. Whilst python looks easy and indeed is, editing it poses some specific difficulties resulting from special meaning of whitespace. Python-mode solved this by offering some repeats: if you are not at the right indentation, just try the next one - outer or inner. Thats OK, thats a possible approach. Here the request came from a user, who must care to save keystrokes. Thus I wrote commands precisely closing function or class, resp. last block. Block conceived as the smollest hierarchical unit - themselves if no hierarchy exists. Too I had some other things in mind: reduction of complexity, generalisation. Something remains to be done. Some reporting facilities have been introduced and shall be still. Here new functions as `bzr log' displays it: `py-next-statement' and `py-previous-statement' set cursor at first char on line instead of beginning of line py-forward-block, py-backward-block py-beginning-of-def-or-class py-class-at-point py-function-at-point py-beginning-of-function py-beginning-of-class py-end-of-function py-end-of-class py-end-of-def-or-class py-line-at-point py-block-at-point py-beginning-of-block py-end-of-block py-whats-at-point py-beginning-of-def-or-class (really or) py-beginning-of-def-or-class-if-arg So far Andreas Röhler -- http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ https://code.launchpad.net/s-x-emacs-werkstatt/ BTW have a look at pydb from Rocky Bernstein, if not done already. What is it useful for ? Xavier ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] [Fwd: Re: python setup ?]
---BeginMessage--- Actually, as an aside, what sort of workflows do people have when using emacs with something like python? Being relatively new to emacs I've been struggling slightly with finding an optimal workflow. For example, in other editors/IDEs my workflow would be something along the lines of: 1. Edit code 2. Run something like pylint or pychecker over the code, run the unit tests, etc 3. Run the app via the debugger 4. Catch any crashes or problems in the debugger, fix them, and start again. In emacs, cycling from editing code to running it under the debugger seems a touch fiddly, largely because it seems to involve more than hitting a single key. I've also tried the 'run/reimport buffer into the interpreter workflow' without much success, in that I usually just want to rerun my app from scratch rather than reload just the file I'm working on. I suspect that I'm so used to the usual IDE workflow that I'm overlooking something fundamental. Any insights would be much appreciated. Thanks! Simon ---End Message--- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Richard Riley wrote: Barry Warsaw ba...@python.org writes: On Apr 30, 2009, at 3:25 AM, Andreas Röhler wrote: With python-mode.el, people may have good reasons, to use it as it is - and me to leave it as it is. Thats fine with bazaar and other DVCs, we can do that. My branch doesn't hamper the origin and any further branch will not. Its just freedom to try and see. This is true, and experimentation a good thing in the short term. In the long term though, a proliferation of branches just confuses people because no one's sure which is the official branch. Our lives are more difficult too because of the python-mode.el/python.el split. So I encourage you to experiment and get user feedback. Old-timers (and remember, python-mode.el's been in widespread use for 15 years) will be wedded to their muscle memory, but if you introduce a user- visible change that people like, they can be made configurable with defaults providing the old behavior. Then it will be possible to merge your changes back into the official branch. If you modularize your changes, then the less controversial ones can get merged in sooner. -Barry IMO any new obviously useful features should be enabled by default. Old Timers should have no problem reverting to older configurations via settings. A point which generates much contention I know. As it is, Python set up is/was a minefield. I have a reasonable set up here fwiw, Yes, you have. Used it month ago, thanks BTW. Beside the question is still, how the user may get everything needed installed with one action. Several possibilities exist: we could make a tarball emacs-python. Too we should let the user decide, what features to use: ipython or not, pdbtrack or pydb, which completion, refactoring, which checks and tests etc. This includes pysmell completions for hippie expand and company-mode. http://richardriley.net/projects/emacs/dotprogramming#sec-1.3 ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Barry Warsaw wrote: On May 4, 2009, at 3:59 PM, Andreas Röhler wrote: IMO any new obviously useful features should be enabled by default. Old Timers should have no problem reverting to older configurations via settings. A point which generates much contention I know. As it is, Python set up is/was a minefield. I have a reasonable set up here fwiw, Yes, you have. Used it month ago, thanks BTW. Beside the question is still, how the user may get everything needed installed with one action. Several possibilities exist: we could make a tarball emacs-python. If you have permission of the authors of the other packages, I have no problem distributing them in our branch, or making a tarball of them available from the Launchpad download page. It's up to them though. Thanks a lot. I'll care for that. It will be great, if emacs-python-folks may use this facility for emacs-python-things independently from existing files, thus python-mode understood in a broader sense, rather python-mode(s). I tend not to use those other packages and just grab python-mode.el from its bzr branch. Too we should let the user decide, what features to use: ipython or not, pdbtrack or pydb, which completion, refactoring, which checks and tests etc. Sure. I would tend to be more conservative in the default settings, so as not to surprise people, but that's just me. :) That's wise. With releases, users shouldn't be bothered with all the developing stuff. Also we could consider bundles for beginners as well as for powered-through master-pythons. :) Andreas -Barryu ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Richard Riley wrote: hi Andreas, but can one list breakpoints in pydb? Cant see how. r. info breakpoints http://bashdb.sourceforge.net/pydb/pydb/lib/subsubsection-info.html Grüße Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode not working in Ubuntu
travis+ml-em...@subspacefield.org wrote: Hello, I am an EMACS user and I know scheme, but I don't know EMACS lisp and I've run into a problem where I could use some help. I installed the following packages on Ubuntu intrepid: bash$ dpkg -l | grep -E 'emacs|python-mode' ii emacs 22.2-0ubuntu2 The GNU Emacs editor (metapackage) ii emacs22-bin-common 22.2-0ubuntu2 The GNU Emacs editor's shared, architecture ii emacs22-common 22.2-0ubuntu2 The GNU Emacs editor's common infrastructure ii emacs22-gtk22.2-0ubuntu2 The GNU Emacs editor (with GTK+ 2.x support) ii emacsen-common 1.4.17 Common facilities for all emacsen ii python-mode1:1.0-3.1ubuntu4 Emacs-lisp python-mode and doctest-mode for When I go to edit a python file with emacs, I get this in my messages buffer: (emacs /tmp/foo.py) Loading 00debian-vars... No /etc/mailname. Reverting to default... Loading 00debian-vars...done Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Loading debian-ispell... Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done Loading debian-ispell...done Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done Loading /etc/emacs/site-start.d/50psvn.el (source)...done Loading /etc/emacs/site-start.d/50pymacs.el (source)...done Loading /etc/emacs/site-start.d/50python-mode.el (source)...done For information about GNU Emacs and the GNU system, type C-h C-a. (New file) File mode specification error: (file-error Cannot open load file python-mode) When I run M-x python-mode, I get this message: call-interactively: Cannot open load file: python-mode And yet, it appears to be there: bash$ locate python-mode /etc/emacs/site-start.d/50python-mode.el /usr/lib/emacsen-common/packages/install/python-mode /usr/lib/emacsen-common/packages/remove/python-mode /usr/share/doc/python-mode /usr/share/doc/pymacs/contrib/Giorgi/python-mode.diffs.gz /usr/share/doc/python-mode/README.Debian /usr/share/doc/python-mode/changelog.Debian.gz /usr/share/doc/python-mode/copyright /usr/share/emacs/site-lisp/python-mode /usr/share/emacs/site-lisp/python-mode/doctest-mode.el /usr/share/emacs/site-lisp/python-mode/pycomplete.el /usr/share/emacs/site-lisp/python-mode/python-mode.el /var/lib/dpkg/info/python-mode.conffiles /var/lib/dpkg/info/python-mode.list /var/lib/dpkg/info/python-mode.md5sums /var/lib/dpkg/info/python-mode.postinst /var/lib/dpkg/info/python-mode.prerm Can anyone please help me figure out how to troubleshoot this? BTW: Thanks for creating such a wonderful editor! It has really helped me as a programmer over the years. Hi, case it shouldn't work using the hints given, (load /usr/share/emacs/site-lisp/python-mode/python-mode.el) into your emacs-init-file, probably ~/.emacs, should do it for the moment in any case. BTW python-mode.el is maintained at https://code.launchpad.net/python-mode I'll cc this mail to python-mode@python.org Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] hide-show support enabled with python-mode.el
Thanks for contribution! Andreas ---BeginMessage--- User: aroehler Date: 09/09/29 12:18:50 Modified:packages/xemacs-packages/python-modes python-mode.el Log: Add support for HideShow Mikhail Novikov freikse...@gmail.com delivered this patch at https://code.launchpad.net/~freiksenet/python-mode/hide-show-support It enables hs-minor-mode within python-mode. Revision ChangesPath 4.56 +21 -0 XEmacs/packages/xemacs-packages/python-modes/python-mode.el Index: python-mode.el === RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/python-modes/python-mode.el,v retrieving revision 4.55 retrieving revision 4.56 diff -u -p -r4.55 -r4.56 --- python-mode.el 2009/09/28 10:44:10 4.55 +++ python-mode.el 2009/09/29 10:18:49 4.56 @@ -366,6 +366,18 @@ to select the appropriate python interpr :type 'boolean :group 'python) +(defcustom py-hide-show-keywords '(class def elif else except + for if while finally try with) + *Keywords used by hide-show +:type '(repeat string) +:group 'python) + +(defcustom py-hide-show-hide-docstrings t + *If doc strings shall be hidden +:type 'boolean +:group 'python) + + ;; ;; NO USER DEFINABLE VARIABLES BEYOND THIS POINT @@ -1216,6 +1228,15 @@ py-beep-if-tab-change\t\tring the bell i (if (fboundp 'imenu-add-to-menubar) (imenu-add-to-menubar (format %s-%s IM mode-name))) ) + + ;; Add support for HideShow + (add-to-list 'hs-special-modes-alist (list + 'python-mode (concat (if py-hide-show-hide-docstrings ^\\s-*\| ) (mapconcat 'identity (mapcar #'(lambda (x) (concat ^\\s-* x \\)) py-hide-show-keywords ) \\|)) nil # + (lambda (arg) + (py-goto-beyond-block) + (skip-chars-backward \t\n)) + nil)) + ;; Run the mode hook. Note that py-mode-hook is deprecated. (if python-mode-hook (run-hooks 'python-mode-hook) ___ XEmacs-CVS mailing list xemacs-...@calypso.tux.org http://calypso.tux.org/mailman/listinfo/xemacs-cvs ---End Message--- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Emacs block indentation
Jaideep Das wrote: I am using emacs 2.2 at work and 2.3 at home for python coding. I want to know how can I indent or outdent a block of code multiple times. What I mean is when I select a code part using C-space and then use C-x tab / C-c- / C-c- to indent or outdent, this only works once and then deselect the block. What if i want to indent multiple times on the same code block do I have to repeated this key sequence from selecting the block to indent. Commit message of latest revision of python-mode.el (note: not python.el) says: When shifting regions right and left, keep the region active in Emacs. This might solve your problem. Get it at https://code.launchpad.net/~python-mode-devs/python-mode/python-mode or with bzr branch lp:python-mode HTH Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] More interactive python
Andrea Crotti wrote: For some reasons I've never been able to write to python-mode (via gmane+gnus) so I'll write it here... Hi Andrea, you should not encounter difficulties posting to this list: Python-mode@python.org You can also join the mailing list at http://mail.python.org/mailman/listinfo/python-mode. I'll forward this message meanwhile. It would be nice to have something like - execute current function (asking for argument if needed) - generate doc string (doesn't make sense to write it manually) and so on. I've found something but I had some problems and it was using pymacs. Pymacs is really nice but apparently in a dead state, so maybe it's better to not count too much on it... Think some people are interested in, me too. Might be helpful, if you make some bug reports. tracker is here: https://bugs.launchpad.net/python-mode It's the right place for feature requests too. Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ Is there something already, or maybe do you have any hints on where to start to do it?? Thanks ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Time for a new release?
Am 05.01.2011 19:45, schrieb Barry Warsaw: Thanks Andreas and Georg for your recent commits to python-mode.el. I wonder if it isn't time to start thinking about an official release, probably of 5.2? Is there anything else anybody would like to get in, say over the next couple of days? If not, I'd be happy to do a release on Friday, but wouldn't mind if someone else wanted to do it instead. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode Hi Barry, I'm glad seeing python-mode proceeding. As for a release, AFAIU we don't have reached Milestone 5.1.1 yet. Bug #473525 isn't dealt with. Wanted to look at next days. Too for my taste there are much more bugs we could adress an current code base still. I'm pretty sure more triple-quote-string bugs exists. Hopefully I'll be at it next month. Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] avoiding edit wars
Hi Barry, with respect to bug-fixing discussions last days it might be useful to reflect some rules in order to avoid edit wars. If several developers join interest in a solution, it's fine. However, different persons tend to harbour different opinions, that's normal. So how to make decisions then? Probably you won't have the time to make all. Also voting might not be realistic for the same reason. So delegation is needed. How to delegate? Understood the instrument of assigning a bug to someone in such, having a person in charge not just for writing fixes but taking care for the process until it's committed. Setting the status flags should be part of the job, as it signals proceeding, might call others for action etc. If people don't agree with decisions of the assignee, they should post to him/her, but not toggle the flags themselves. Finally it's your job IMHO to revoke an assignment, if disputes can't be settled otherwise. These understanding seems not common so far. Happy to see things developing fast last days, what's great. Just makes it worthwhile to address upcoming dangers. Thanks all Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] simplified procedure
Hi Barry, thanks for the merges. With respect to the still considerable amount of reports and a possible speed up of it's treatment, please permit some reflexions, how ease the process: - as for pure typos, whitespace, indent-matters IMHO developers should be permitted to push into the trunk without prior notice. - if funktion is changed, newly introduced, we could agree a simplified procedure, saying a delay of three days, so people may object. - in cases of fundamental change I won't act without your prior consent. So far Andreas PS https://code.launchpad.net/~a-roehler/python-mode/string-to-syntax is still unmerged. It concerns XEmacs only (featurep 'xemacs)..., ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] c/c++ project management and debugging
Am 10.01.2011 17:18, schrieb Richard Riley: Garyhelp-gnu-em...@garydjones.name writes: Le Wang wrote: My opinion of Eclipse aside, generally, when someone arguesnoun is adjective because Google results count is xxx, you should seriously question that side of the argument. I didn't claim it was slow because Google results count is xxx, I claimed that it was slow because that was my experience. Stop trying to put words in my mouth. Eclipse isn't slow when using it. Well, not really any appreciable amount slower than any other dekstop GUI editor. And its certainly a lot more powerful than most if you are a programmer dealing with multiple languages or wanting a common look and feel IDE for all projects. Mixed mode in debian is kind of ok with nxhtml, but Java is nigh on impossible (well, hard work - what is the status with JDEE now?), python is a confusing mess (multiple python modes floating around) Hi Richard, can't contradict basically, but let me say: python-mode.el at https://launchpad.net/python-mode got some momentum. What about joining the team? In case you join, I'll propose a milestone python auto-completion-mode during next weeks. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ : of course the benefits of Eclipse also introduce some overheads but not ones I feel are detrimental to any development process. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] confusion about py-string-to-syntax def
Am 13.01.2011 21:05, schrieb s...@pobox.com: I'm trying to get the latest python-mode.el to compile cleanly. I have this definition: ;; Skip's XE workaround (if (fboundp 'string-to-syntax) (defalias 'py-string-to-syntax string-to-syntax) (defun py-string-to-syntax (s) (cond ((equal s |) '(15)) ((equal s _) '(3)) (t (error Unhandled string: %s s ) Thanks, though my taste is still the other way around: as soon as XEmacs merges up to GNU code, would should drop our stuff, considered a possible a bug-source than. With the use of a aliased function I'm afraid, we have the complexity and bug source just now. I'll be patient and look, should someone want to write that in. Just rather not me :-) Let's go on Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] confusion about py-string-to-syntax def
Am 13.01.2011 22:16, schrieb s...@pobox.com: I'm trying to get the latest python-mode.el to compile cleanly. Neither of you answered this question. :-) How do I get those warnings to go away? Skip Hi Skip, seems you introduced a bug. Why not use the trunk? BTW all the py--prefix and defalias considerations here are missing the point IMHO in such, as if in further futures XEmacs should provide this symbol, the compiler will tell...defined a second time. Until then, please let us stay as much as possible with the existing code, as tqs-syntax-setting is known to work elsewhere. If extra stuff is introduced in this context, debugging syntax will be harder. What about removing remaining compiler warnings, which are not functional AFAIS? For example introducing some defvars to silence the compiler in these cases. Thanks BTW having brought the compiling question to attention here. Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] upcoming release
Am 28.01.2011 23:09, schrieb Barry Warsaw: On Jan 28, 2011, at 10:56 PM, Andreas Röhler wrote: enabling XEmacs' handling of triple-quoted-strings fixing bugs known for now seems an interesting item from my perspective. paragraph-fill-warts branch should enable this. https://code.launchpad.net/~a-roehler/python-mode/paragraph-fill-warts It comes with a lot of utilities though, some required, some just part of the tool-box, where singling-out the required here is possible. I'm hesitating to propose that for general release, as people might be scared by the material, which is just partly python-related. OTOH, what I'm promessing: it pays. These utilities will fasten up editing, python-mode and all other. What about to release a thus experimental brunch for XEmacs users first, while it will work for all? Andreas Andreas, as always, thanks for your hard work on python-mode! It's very much appreciated. I've merged your branch and will play with it over the weekend. Hi Barry, sounds great. I'm going to leave it to Skip to verify the XEmacs compatibility issues (Skip please let us know if you need help getting Andreas's branch). python-mode.el has always been self-contained, meaning people can easily download or copy one file and get great Python support in Emacs. Requiring your utilities changes that, and can make it harder for some folks to adopt python-mode.el. Indeed, that's my concern too. I'm not saying that necessarily means it can't be done, but we do have to think about the ramifications. I'd like to get other folks thoughts on that. OTOH, I encourage you to get your code into upstream Emacs and XEmacs. That would certainly make our lives easy again. :) Do you think it would be possible and easy to pull out just the parts that python-mode.el needs and include those in that file? That can be done. OTOH it's rather hard keeping that stuff parallel. If not, then what about making sure python-mode.el gracefully degrades when those extra files aren't there? Don't see that, comment below. By that I mean, if someone does not have your new utilities, python-mode.el should at least work as well as it does currently. python-mode.el should then take advantage of your utilities if they're available. Thoughts? -Barry As it's XEmacs only, which enforced the re-write, maybe we should wait if it works there. In case it works, could extract the needed stuff to it's required minimum. Nontheless GNU Emacs won't need it, so keeping the syntax-parsing as it is for GNU Emacs users will be an option. Also in case XEmacs merges up to GNU code, the regexp-backed parser will not be needed any more. OTOH there are some gains adressed already in the second-level-command blueprint. For me the best would be maintaining for a certain time basically three branches - the classic, presently de facto GNU only - XEmacs special triple quoted string debugged, but fine for GNU Emacs also - a second-level-command enabled IDE. As this slc's will count in thousands and ten-thousands, using it needs an understandings of it's construction, i.e. of the cross-use of it's underlying lists: `ar-hide-bracketed-in-line-atpt' for example hides everything insides brackets within the given line. Resp. `ar-show-bracketed-in-line-atpt' displays it again, `ar-hide-show-bracketed-in-line-atpt' toggles this state. You have `ar-hide-bracketed-in-parentized-atpt' and so on. See the comment in `thingatpt-utils-base.el' for more. As for the latter, think we still need some time to discuss and check it's usefulness. Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] upcoming release
Am 29.01.2011 17:12, schrieb s...@pobox.com: Andreas Ok, so let's have it. Pushed just now. File mode specification error: (file-error Cannot open load file: %s string-strip) ehm... pushed load-path: `load-path' is a simple built-in variable. Value: (/Users/skip/src/paragraph-fill-warts ... Skip ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Latest error
Am 29.01.2011 18:16, schrieb s...@pobox.com: Looks like thingatpt-utils-base requires thingatpt-highlight which doesn't exist in the checkout. I evaled all the (require) statements from the .el files in a (progn) block: (progn (require 'easymenu) (require 'ansi-color) (require 'ar-comment-lor) (require 'beg-end) (require 'cl) (require 'comint) (require 'compile) (require 'custom) (require 'info-look) (require 'misc-utils) (require 'mmm-auto) (require 'pymacs) (require 'reporter) (require 'sh-beg-end) (require 'sh-script) (require 'string-strip) (require 'thingatpt-utils-base) (require 'overlay) (require 'imenu) (require 'thing-at-point-utils) (require 'thingatpt-highlight) (require 'python-mode) ) thingatpt-highlight was the only one it complained about. Skip Hmm, seems I underestimated the issue. added and pushed. Thanks being that attentive. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Latest error
Am 29.01.2011 18:52, schrieb s...@pobox.com: thingatpt-highlight was the only one it complained about. Andreas Hmm, seems I underestimated the issue. Andreas added and pushed. I'm getting farther. Looks like thingatpt-highlight was missing (when (featurep 'xemacs) (require 'overlay)) so I added that to get the make-overlay function. Then I could visit the Python file without errors. Recall the file looks like this (without the extra indentation): triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. class Foo(object): @staticmethod def bar(aList): for x in aList: for y in x: print y When I try to fill the docstring using fill-paragraph-or-region (M-q) with point ahead of the first 't', it still deletes the space ahead of the first single quotation mark, leaving me with this: triple-quoted string containingquotation marks. which is the charateristic error of failing forward-sexp, As that form doesn't exist in new version, it means, we got the old chunk back See the error was done with revision 391 Will take some minutes to get it back. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. If I place point at the beginning of the last line and fill, I get this: triple-quoted string containingquotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containingquotation marks. Repeat again, and I get: triple-quoted string containingquotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containingquotation marks. triple-quoted string containingquotation marks. I can proceed to do this until I'm left with a single line in the docstring. Skip ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] paragraph-fill-warts branch
Am 29.01.2011 22:34, schrieb g.bra...@gmx.net: Original-Nachricht Datum: Sat, 29 Jan 2011 15:20:56 -0600 Von: s...@pobox.com An: Andreas Röhlerandreas.roeh...@online.de CC: python-mode@python.org Betreff: Re: [Python-mode] paragraph-fill-warts branch Andreas the old bug should be gone now. Andreas As its redone from the bottom, filling isn't correct yet. Andreas However, borders of triple-quoted-string now are recognised, Andreas `ar-bounds-of-triplequoted-atpt' should report it for example, Andreas the remaining should not be a rocky mountain. Looks much better. Goes from this: triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. to this: triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. no matter where I place the cursor. Which is not how this should work. * If there is an initial linebreak it should remain there. * If there is a final linebreak it should remain there. And if there is no initial linebreak, please do not put a space between the quotes and the docstring text. Georg Hi Georg, hi Skip, just checked in a new version of fill-warts branch and also components branch It's definitly upwards the hill, but some issues remain. We have a bug in GNU's fill.el After paragraph-fill-function is called, it should retire from all other work. Unfortunatly later on (fill-region-as-paragraph beg end justify) comes across and messes it up. Altogether looks with GNU still better than with XEmacs, which progresses also. To make some pieces from the remaining: Could you check with `py-fill-paragraph' directly leaving out M-q? That would make it easier coming to some result. When reporting the remaining bugs, please make an entry in the tracker and mention the kind of Emacs/version. Thanks all Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] paragraph-fill-warts branch
Am 30.01.2011 23:16, schrieb s...@pobox.com: Andreas When reporting the remaining bugs, please make an entry in the Andreas tracker and mention the kind of Emacs/version. Done: https://bugs.launchpad.net/python-mode/+bug/710373 Andreas, if you would like a login on my Mac laptop so you can play with my version of XEmacs, let me know. I suspect you will converge on working code more quickly if you don't have to wait for me to complain. Skip Thanks, looks like a nice play. So I must log in via ssh? May you use my public key vom lp? Not sure about the steps for this. Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el
Am 03.02.2011 22:48, schrieb Aaron Culich: On Thu, Feb 3, 2011 at 1:13 PM,s...@pobox.com wrote: Georg - From reading emacs-devel, it seems that the python.el has made Georg changes to the mode and explicitly taken them out of the Georg copyright assignment for the FSF, so Emacs upstream can't include Georg them. Georg So now we are at three different python modes for Emacs... :| I'm not sure I understand. Someone forked python.el but won't allow the changes to go back into the GNU version? Wouldn't that violate the GPL or LGPL. Who did this? Copyright assignment is an issue separate from the license itself. To the extent that Dave's version is derived from the existing python.el then the GNU GPL still applies to his version of python.el if he distributes it to other people. He is the owner of the new code that he has written, so that means if he finds someone that redistributes his code in a manner that is violating the GNU GPL license, then he has the legal standing to pursue that violation in court as the copyright holder. However, no one else has the right to pursue it in court on his behalf; you could bring a case to court, but it would be thrown out in just the same way as if you tried to bring a lawsuit against someone illegally redistributing MS Word; you can't sue someone for that, but Microsoft can if they chose to. The license, whether free or proprietary, can only be enforced in the courts by the copyright holder. The issue of enforcement is one of reasons that the GNU project long ago made a requirement that any code contributions accepted back into the code base and officially branded as GNU software must also have any accompanying copyright assignment. There are other reasons, as well, including protection from patents so that it would prevent someone from contributing source code to the GNU project on one hand, and then on the other hand using patents against the same set of code. You can read that in the language of one of the example copyright assignment forms I've linked to below. -Aaron Here is some further reading: An official statement about why they require copyright assignment: http://www.gnu.org/licenses/why-assign.html An example of the copyright assignment form http://gcc.gnu.org/ml/gcc/2002-09/msg00678.html Excerpt from the above form intended to protect against harm from patents: The Assigner hereby agrees that if it has or acquires hereafter any patent or interface copyright or other intellectual property interest dominating the program enhanced by the Work (or use of that program), such dominating interest will not be used to undermine the effect of this assignment, i.e. the Foundation and the general public will be licensed to use, in that program and its derivative works, without royalty or limitation, the subject matter of the dominating interest. This license provision will be binding on the assignees of, or other successors to, the dominating interest, as well as on the Assigner. Hi Aaron, saw you digged into this only after sending my short statement with other post. Sorry for that, would have been more explicit seeing the interest in the matter. It is wast one beside. FSF thinks by making these assignment provisions, --partly to the extent of the contributors, setting them on risk rather than the FSF itself-- to do something good. Far from that: by raising the level of specification already it provides uncertainty rather than certainty. Let me point at the risks already introduced by GPL in this globalised world. Any conflict around would endanger contributors, as being summoned before a Bostonian court many of them will not be able to pay the costs. From this perspective GPL already bears a --rather unspecified-- but potential menace and danger for all using it. Decided taking that risk, as you see. But I'm not willing to take more. As for copy-rights I'm protected by our domestic laws, which promess even gratis assistance in certain cases of conflicts. Why should I give up that protection by signing up to US-courts? Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el
[ ... ] He must have a big bee in his bonnet. Always being patient with the genial. Which permits being patient with the common one, including myself. :-) Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el
Am 04.02.2011 16:30, schrieb Barry Warsaw: On Feb 04, 2011, at 09:16 AM, Andreas Röhler wrote: However, let me clarify: Emacs _can_ include, as long it is GPL and it is. But they won't. And so we can. Yes, we're not bound by the same copyright assignment policy. It's just to give up the insane copyright-policy, where I see no legitime reason for, which denigrates the GPL as such. The FSF has their reasons, Hi Barry, I'm consenting to that. There is some rationale. which I think are legitimate for them. As much as I wish we could merge all the different versions and get python-mode.el into GNU Emacs, it may simply be impossible - or not worth the effort. Policies tend to change. BTW assigned the disclaimer of FSF and there are some lines by me already in GNU Emacs. So assignment is not an absolute barrier even now. :-) Andreas Apologies for fanning those old flames again. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] py-match-paren
Hi Barry,
herewith a function I'm used to when editing and didn't want miss it in
python-mode.
Maybe have a look, if it seems useful for others too.
Needs
(require 'beg-end)
(require 'thing-at-point-utils)
(require 'thingatpt-utils-base)
from https://code.launchpad.net/s-x-emacs-werkstatt/
which are present already in branches:
lp:~a-roehler/python-mode/paragraph-fill-warts
lp:~a-roehler/python-mode/python-mode-components
;
;; (define-key py-mode-map [(%)] 'py-match-paren)
(defun py-match-paren (arg)
Go to the matching brace, bracket or parenthesis if on its counterpart.
Otherwise insert the character, the key is assigned to, here `%'.
With universal arg \C-u insert a `%'.
(interactive P)
(if arg
(self-insert-command (if (numberp arg) arg 1))
(cond
((looking-at ()
(goto-char (ar-parentized-end-position-atpt))
(backward-char 1))
((looking-at ))
(goto-char (ar-parentized-beginning-position-atpt)))
((looking-at \\\[)
(goto-char (ar-bracketed-end-position-atpt))
(backward-char 1))
((looking-at ])
(goto-char (ar-bracketed-beginning-position-atpt)))
((looking-at {)
(goto-char (ar-braced-end-position-atpt))
(backward-char 1))
((looking-at })
(goto-char (ar-braced-beginning-position-atpt)))
(t (self-insert-command 1))
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Latest paragraph-fill-warts branch
Am 13.02.2011 22:50, schrieb s...@pobox.com: I don't know where we left things w.r.t. the Andreas's paragraph-fill-warts branch, but I just updated and fired up a new copy of XEmacs. Then edited my current small test file. After filling the doc string I see the same issue reported before by (I think) Georg. When filling this: triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. I wind up with this: triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. That is, the newline after the first tqs and before the last tqs are not preserved. This would have been ideal: triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. triple-quoted string containing quotation marks. Also, take a look at the attached png file. Is it possible to color quotation green? Skip Hi Skip, the basic reason is XEmacs' syntax bug. Going to do regexp-based string parsing instead. However, detected several bugs in the new parser and just this morning a fundamental one, so I'm re-writing major parts. I'll send a message if ready for testing. As for your last question resp. string colors, this would need a change in fontifying afterwards. As XEmacs already is slow here, I'm not a XEmacs hacker, I'm afraid this will persist - unless someone fixes it. Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] release?
Am 15.02.2011 20:54, schrieb Barry Warsaw: On Feb 15, 2011, at 08:52 PM, Andreas Röhler wrote: from my perspective a release is feasible, after triple quoted string bugs should be gone. Sorry, I don't quite understand. Do you mean that we should release r396 or that you have a few more patches to go in to fix the triple quoted string bugs? Hmm, the bugs exists only for XEmacs now AFAIS. But fixing it there will open more bugs then closing that way probably. Which doesn't mean it's a bad thing, because it should open some route to much more gains. However, it's not a simple bug-fix. Therefor would close the tqs-reports setting it to released. Not sure, if previous release already took the syntax patch. If yes, could toggle the reports now. Andreas Is the NEWS file up to date? Also, would this be a 5.3.0 or 5.2.1? After release, I'll toggle the bug flags, so it will no longer list as open. Also would do a release of python-components-mode afterwards, which should fix the paragraph-fill bugs too. Let me know when you're ready and I push the release button. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] release?
Am 17.02.2011 22:44, schrieb Barry Warsaw: On Feb 17, 2011, at 04:39 PM, Andreas Röhler wrote: Hmm, the bugs exists only for XEmacs now AFAIS. But fixing it there will open more bugs then closing that way probably. Which doesn't mean it's a bad thing, because it should open some route to much more gains. However, it's not a simple bug-fix. Therefor would close the tqs-reports setting it to released. Not sure, if previous release already took the syntax patch. If yes, could toggle the reports now. Andreas, I actually realize that you are a member of ~python-mode-devs so you should be able to do a release on your own. Why don't you give it a try and let me/us know if you have any problems. You could even send the announcement to python-annou...@python.org. You're doing most of the work these days, so you should get the credit. :) -Barry Thanks a lot, Barry, as for the tqs I remember you just answered these days it works for you. I'll close these reports then. Remain several other indent-bugs - beside stuff not touched yet. Hopefully next week we can have a bugfix release of the trunk. Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight bug?
Am 25.02.2011 13:32, schrieb andrea crotti: Ok first I need to be sure I'm up to date. I'm at revision 396, and also here https://code.launchpad.net/~python-mode-devs/+ownedbranches I see the same as last commit done... Are there any more advanced branches? usually I start here: https://code.launchpad.net/python-mode BTW my components branch is still heavily changed, major changes underway... Have a look at the thing-at-point utils stuff nonetheless, for me it's a rocket~~~:=== For python-mode/python.el good to know, as long as it's sharing and helping and not fighting is not a problem... ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight bug?
Am 25.02.2011 16:30, schrieb andrea crotti: 2011/2/25 Andreas Röhlerandreas.roeh...@online.de: usually I start here: https://code.launchpad.net/python-mode BTW my components branch is still heavily changed, major changes underway... Have a look at the thing-at-point utils stuff nonetheless, for me it's a rocket~~~:=== For python-mode/python.el good to know, as long as it's sharing and helping and not fighting is not a problem... Oh God I found the problem, I think probably after the last update of cedet I have this not so funny behaviour When emacs starts I get this: python-mode is an interactive compiled Lisp function in `python-mode.el'. After I open the first python file it becomes: python-mode is an interactive compiled Lisp function in `python.el'. (python-mode) So I'm just using the wrong thing but I didn't notice because locate-library also gave me the right file. Any way to solve this conflict once for all? Using some function to toggle several branches/modes like this (set-buffer (get-buffer-create test.py)) (erase-buffer) (when (featurep 'python-mode)(unload-feature 'python-mode t)) (fundamental-mode) (setq py-python-command-args '(-colors Linux)) (add-to-list 'load-path NEW-PATH... then load some python-stuff into, call python-mode again. HTH Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight-indentation
Am 11.03.2011 13:47, schrieb Barry Warsaw: On Mar 09, 2011, at 10:24 PM, Andreas Röhler wrote: just seeing highlight-indentation by Anton Johansson - thanks a lot to him BTW - which I suggest to include into next release. It delivers graphical bars indicating the indent-level, makes em more impressive. Might be useful in certain circumstances. Hi Andreas, Anton, Hi Barry, Indeed, I agree that this could be very useful in some situations. good news :-) It can be a little distracting, so it probably should not be turned on by default, as it's just a function, user may call them or not. It doesn't interfere. BTW exists still another nice tool of the same author at: http://stackoverflow.com/questions/1587972/how-to-display-indentation-guides-in-emacs (defun aj-toggle-fold () Toggle fold all lines larger than indentation on current line (interactive) (let ((col 1)) (save-excursion (back-to-indentation) (setq col (+ 1 (current-column))) (set-selective-display (if selective-display nil (or col 1)) (global-set-key [(M C i)] 'aj-toggle-fold) Maybe have look. but for those cases where the indentation is really hard to follow, I think this could be a very nice addition. Is this file going to be added to Emacs? It seems more general than just for Python (e.g. turn it on in python-mode.el). One minor nit: I wonder if it makes sense to highlight columns that are not in the leading whitespace. For example, turn it on and look at the define-key lines starting at about line 845 in python-mode.el. There are some highlighted indentation extents after the \C-c: string. Those don't seem useful. Yes, seeing that too. AFAIU it will be hard to cure, as the function sets consecutive whitespaces as keywords. Trailing whitespaces are marked that way too. Also it only occurs if large whitespaces are somewhere between. For the purpose of quickly indicating multiple indents it's fine. So don't see a need to ask for a change at this state. Andreas Thanks for pointing it out, and thanks to Anton for writing it. Cheers, -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight-indentation
Am 12.03.2011 04:28, schrieb Barry Warsaw: Hi Andreas, I noticed that you committed this file to our bzr tree. Hi Barry, took preceding exchange for an approval. Will be more carful next time. I'm concerned about doing this without Anton's approval (and maybe even with it). Anton probably has his own source code repository, so at the very least it would be more effort for us to keep our copy up-to-date with his. python-mode.el doesn't depend on his code, so it's really not necessary for us to have a copy in our tree. As cool as Anton's module is, and it definitely could help Python programmers, it's probably a better idea to add a reference to his work (and his download site or source repository) in our README file or in the comments at the top of python-mode.el. If Anton really wants us to keep the canonical version of his mode in our bzr tree, we could discuss that. Anton, what do you think? Cheers, -Barry As for the approval: thought that's precisely what the GPL is for. So if an author publishs it's code under GPL, that's for the very reason others may take it, isn't it? Beside I gave credits with commit message, inside the header and also dropped a notice to the author. Which doesn't mean your concerns are invalid, posed them for me also and answered them as given above. Likewise as for the technical aspects of repository: Having useful Emacs code all around the net, it's just the situation we are in. It's not all bad with that, makes some pleasure to look around, trying this and that. As for my concern here I'm heading for an IDE, where people open Emacs and find ererything ready for Python edits as far as the state of art delivers it. That means the question you raised concerning whitespaces for examples must be discussed before and at place. You can't know what our creative folks will be have in mind next, if it will be suitable, more or less, buggy more or less and so on. It's not done with links delivered. If we will provide an Python-IDE we must be able to tell: here is it's specification, it will work for these conditions, makings that requirements. Therefor we must collect the code for the specified purpose, IMHO :-) Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Error during indentation
Am 13.03.2011 12:49, schrieb Andrea Crotti: I get a strange error when I have a situation like this: --8---cut here---start-8--- 1 class Foo(object): 2 3 Some doc 4 5 --8---cut here---end---8--- if I go to line 5 and press tab I get the error as below, using: GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-03-04 and python-mode from bzr (can I get automatically the revision from emacs?) you may subscribe for mail at https://code.launchpad.net/~python-mode-devs/python-mode/python-mode then you will get a mail always the branch is updated Afterwards do bzr branch lp:python-mode BTW : can't reproduce the bug. Andreas --8---cut here---start-8--- Debugger entered--Lisp error: (wrong-type-argument integerp t) make-string(1 t) py-goto-beginning-of-tqs(t) py-compute-indentation(t) py-indent-line() indent-for-tab-command(nil) call-interactively(indent-for-tab-command) (progn (setq this-command command) (call-interactively command)) (if (and (commandp command) (not (string-match yas/expand (symbol-name command (progn (setq this-command command) (call-interactively command))) (when (and (commandp command) (not (string-match yas/expand (symbol-name command (setq this-command command) (call-interactively command)) (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 (this-command-keys-vector)) (keys-2 (and yas/trigger-key from-trigger-key-p (stringp yas/trigger-key) (read-kbd-macro yas/trigger-key))) (command-1 (and keys-1 (key-binding keys-1))) (command-2 (and keys-2 (key-binding keys-2))) (command (or (and (symbolp command-1) (not (string-match yas/expand (symbol-name command-1))) command-1) (and (symbolp command-2) command-2 (when (and (commandp command) (not (string-match yas/expand (symbol-name command (setq this-command command) (call-interactively command))) (cond ((eq yas/fallback-behavior (quote return-nil)) nil) ((eq yas/fallback-behavior (quote call-other-command)) (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 (this-command-keys-vector)) (keys-2 (and yas/trigger-key from-trigger-key-p (stringp yas/trigger-key) (read-kbd-macro yas/trigger-key))) (command-1 (and keys-1 (key-binding keys-1))) (command-2 (and keys-2 (key-binding keys-2))) (command (or (and (symbolp command-1) (not ...) command-1) (and (symbolp command-2) command-2 (when (and (commandp command) (not (string-match yas/expand (symbol-name command (setq this-command command) (call-interactively command ((and (listp yas/fallback-behavior) (cdr yas/fallback-behavior) (eq (quote apply) (car yas/fallback-behavior))) (if (cddr yas/fallback-behavior) (apply (cadr yas/fallback-behavior) (cddr yas/fallback-behavior)) (when (commandp (cadr yas/fallback-behavior)) (setq this-command (cadr yas/fallback-behavior)) (call-interactively (cadr yas/f all back-behavior) (t nil)) yas/fallback(trigger-key) (if (and templates-and-pos (first templates-and-pos)) (yas/expand-or-prompt-for-template (first templates-and-pos) (second templates-and-pos) (third templates-and-pos)) (yas/fallback (quote trigger-key))) (let (templates-and-pos) (unless (and yas/expand-only-for-last-commands (not (member last-command yas/expand-only-for-last-commands))) (setq templates-and-pos (if field (save-restriction (narrow-to-region (yas/field-start field) (yas/field-end field)) (yas/current-key)) (yas/current-key (if (and templates-and-pos (first templates-and-pos)) (yas/expand-or-prompt-for-template (first templates-and-pos) (second templates-and-pos) (third templates-and-pos)) (yas/fallback (quote trigger-key yas/expand() call-interactively(yas/expand nil nil) --8---cut here---end---8--- ___ Python-mode mailing list Python-mode@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] Error during indentation
Am 13.03.2011 21:09, schrieb Andrea Crotti: Barry Warsawba...@python.org writes: On Mar 13, 2011, at 12:49 PM, Andrea Crotti wrote: I get a strange error when I have a situation like this: --8---cut here---start-8--- 1 class Foo(object): 2 3 Some doc 4 5=09 --8---cut here---end---8--- if I go to line 5 and press tab I get the error as below, using: GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-03-04 and python-mode from bzr (can I get automatically the revision from emacs= ?) I cannot reproduce this with Emacs 23.2.1 on Ubuntu Natty and python-mode= .el r400. -Barry I thought it was something else interfering, but I've: - update to rev400 - byte-compiled python-mode - started a new emacs24 -Q in the scratch buffer wrote as above, and still the same error... --8---cut here---start-8--- Debugger entered--Lisp error: (wrong-type-argument integerp t) make-string(1 t) (and delim (make-string 1 delim)) (let ((skip (and delim (make-string 1 delim))) (continue t)) (when skip (= save-excursion (while continue (py-safe (search-backward skip)) (setq conti= nue (and (not (bobp)) (=3D (char-before) 92 (if (and (=3D (char-before)= delim) (=3D (char-before (1- ...)) delim)) (setq skip (make-string 3 delim= (py-safe (search-backward skip py-goto-beginning-of-tqs(t) Hi Andrea, thanks. Have some idea meanwhile wherefrom these bug. It's in the line above, resp. it's receiving function. Ironically you get this bug, because syntax setting is OK now with Emacs 24. AFAIS bug results, because the delimiting char of a triple-quoted-string is no longer of 7, string quote, but of 15, generic string. syntax-ppss and friends than don't send the delimiting char as integer, but `t'. The receiving functions refuses correctly to make a string from: wrong-type-argument integerp t) With some luck I'll send a fix next days... Andreas (cond ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipp= s))) (save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-ba= ckward ^[ ]*\\([^ \n#]\\|#[ \n]\\) nil (quote move)) (back-to-indentat= ion) (current-column ((py-continuation-line-p) (let ((startpos (point))= (open-bracket-pos (py-nesting-level)) endpos searching found state cind cl= ine) (if open-bracket-pos (progn (setq endpos (py-point (quote bol))) (py-g= oto-initial-line) (setq cind (current-indentation)) (setq cline cind) (doli= st (bp (nth 9 ...) cind) (if (search-forward \n bp t) (setq cline cind)) = (goto-char (1+ bp)) (skip-chars-forward ) (setq cind (if ... ... ...)))= ) (forward-line -1) (if (py-continuation-line-p) (current-indentation) (end= -of-line) (setq endpos (point) searching t) (back-to-indentation) (setq sta= rtpos (point)) (while searching (skip-chars-forward ^=3D endpos) (if (=3D= ... endpos) (setq searching nil) (forward-char 1) (setq state ...) (if ...= ...))) (if (or (not found) (looking-at [ ]*)) (progn (goto-char sta= rtpos) (skip-chars-forward ^ \n))) (+ (current-column) (if (py-statement= -opens-block-p) py-continuation-offset 0) 1) ((bobp) (current-indentati= on)) ((and (looking-at [ ]*#[^ \n]) (fboundp (quote forward-comment)) (= =3D (current-indentation) (save-excursion (forward-comment (- (point-max))= ) (current-indentation (current-indentation)) (t (if (and (eq py-honor-= comment-indentation nil) (fboundp (quote forward-comment))) (forward-commen= t (- (point-max))) (let ((prefix-re (concat py-block-comment-prefix [ ]*= )) done) (while (not done) (re-search-backward ^[ ]*\\([^ \n#]\\|#\\) n= il (quote move)) (setq done (or (bobp) (and ... ...) (and ... ...)) (py= -goto-beginning-of-tqs (nth 3 (parse-partial-sexp bod (point (setq plac= eholder (point)) (py-goto-initial-line) (py-goto-beginning-of-tqs (save-exc= ursion (nth 3 (parse-partial-sexp placeholder (point) (+ (current-inden= tation) (if (py-statement-opens-block-p) py-indent-offset (if (and honor-bl= ock-close-p (py-statement-closes-block-p)) (- py-indent-offset) 0) (let* ((bod (py-point (quote bod))) (pps (parse-partial-sexp bod (point))= ) (boipps (parse-partial-sexp bod (py-point (quote boi placeholder) (co= nd ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipps))) = (save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-backwar= d ^[ ]*\\([^ \n#]\\|#[ \n]\\) nil (quote move)) (back-to-indentation) = (current-column ((py-continuation-line-p) (let ((startpos (point)) (ope= n-bracket-pos (py-nesting-level)) endpos searching found state cind cline) = (if open-bracket-pos (progn (setq endpos (py-point ...)) (py-goto-initial-l= ine) (setq cind (current-indentation)) (setq cline cind) (dolist (bp ... ci= nd) (if ... ...) (goto-char ...)
Re: [Python-mode] Fw: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added
Am 15.03.2011 17:23, schrieb Barry Warsaw: Hi Andreas. Did you really mean to commit a directory listing as a .el file? ;) -Barry OMG, seems something swapped over... Sorry and thanks. It's okay at my home board BTW, no magic. Just got the wrong buffer when saving. Andreas Begin forwarded message: Date: Tue, 15 Mar 2011 11:11:16 - From: nore...@launchpad.net To: Barry Warsawba...@canonical.com Subject: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added revno: 402 committer: Andreas Roehlerandreas.roeh...@online.de branch nick: python-mode timestamp: Tue 2011-03-15 11:08:05 +0100 message: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added added: py-bug-numbered-tests.el -- lp:python-mode https://code.launchpad.net/~python-mode-devs/python-mode/python-mode Your team python-mode.el developers is subscribed to branch lp:python-mode. To unsubscribe from this branch go to https://code.launchpad.net/~python-mode-devs/python-mode/python-mode/+edit-subscription ___ Python-mode mailing list Python-mode@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
[Python-mode] apropos py-bug-numbered-tests
Hi Barry, test concerning last bug report `goto-beginning-of-tqs-lp:735328-test' should go through with python-mode.el, some others too, but not all. To tackle remaining bugs, would change some lisp of python-mode.el towards more common forms. For example `py-save' now is as macro `ignore-errors' available. Also `py-point' forms IMHO rather obfuscate the code. Did see the explanation for it, but don't think it pays. Do I have green light for such a clean up? Would commit every logical step, so it should be easy to revert, should some mistake occur. Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] r401 is broken
Am 15.03.2011 22:21, schrieb Barry Warsaw: Hi Andreas, r401 broke TAB indentation in Emacs 23. In the attached file, set the cursor at the end of line 48, then hit return and tab. Point does not indent. Cheers, -Barry there was a typo, done now. Will see again tomorrow. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight-indentation
Am 14.03.2011 10:04, schrieb Anton Johansson:
Hi, if you can forward bug tracking automatically, please do,
Hi,
launchpad sends notifications once a bug is tracked there. Must be
registered, which goes smoothly, no special requirings.
With an lp account I may subscribe to related bugs. Also you may
subscribe yourself to what matter whatever and do some other funny things.
Beside bug-tracking feature-request may be tracked. Blue-prints are for
that AFAIU.
Than it has Milestones where ToDo's might be listed and Releases prepared.
highlight-indentation integration could be part of a milestone for example.
So far
best regards,
Andreas
otherwise it's ok don't overwork it :) Also the full functionality of
highlight-indentation is basically:
(setq highlight-indent-offset 4) ;; Spaces indent level
(font-lock-add-keywords nil `((,(format \\( \\) \\{%s\\} (-
highlight-indent-offset 1)) (1 'highlight-indent-face
so if you find a better place to extract that to syntax highlighting code it
might be better...
Cheers
-- Anton
On Mar 13, 2011, at 09:15 , Andreas Röhler wrote:
Hi Anton,
thanks a lot BTW.
Added a link onto your repo into the header.
In order to get a wider audience with resp. to other modes an entry
at
http://www.emacswiki.org/emacs-en
might be useful.
As for bug-tracking think we should forward any report to you, if it concerns
your file(s). OTOH would not charge the users which such specific requests.
Agreed?
Thanks again.
Andreas
--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/
Am 12.03.2011 11:38, schrieb Anton Johansson:
Hello,
I'm absolutely cool with you guys using the code in any way you find
suitable, nice to see some people finding it useful!
Like you have discussed before, there are some issues with
highlight-indentation.el that could be handled better, for example
highlighting spaces that are not in the leading whitespace. If you can
find a good way to link to my repo so that people can submit possible
fixes that would be good since the code is also usable in other modes.
Cheers
-Anton
On Sat, Mar 12, 2011 at 4:28 AM, Barry Warsawba...@python.org wrote:
Hi Andreas,
I noticed that you committed this file to our bzr tree. I'm concerned about
doing this without Anton's approval (and maybe even with it). Anton probably
has his own source code repository, so at the very least it would be more
effort for us to keep our copy up-to-date with his. python-mode.el doesn't
depend on his code, so it's really not necessary for us to have a copy in our
tree.
As cool as Anton's module is, and it definitely could help Python programmers,
it's probably a better idea to add a reference to his work (and his download
site or source repository) in our README file or in the comments at the top of
python-mode.el.
If Anton really wants us to keep the canonical version of his mode in our bzr
tree, we could discuss that. Anton, what do you think?
Cheers,
-Barry
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight-indentation
Am 25.03.2011 16:08, schrieb Barry Warsaw: Hi Andreas, I don't disagree with anything you wrote, and of course we're allowed to use anything GPL'd. I don't think even politeness mandates pre-approval in order to *use* GPL code. The let's be nice comment wasn't directed at you personally, or really anybody here - I think we're all being nice, helpful, and polite, which to me is one of the most important principles of FLOSS. :) It also wasn't a comment on our use of GPL code. It was related to our bringing in a copy of someone else's file, which is already under their own VCS, into our VCS. Doing so could give the impression that we're the authoritative copy of the file. I wouldn't want to usurp someone else's authority on that without their approval. I hope that makes sense. Me too :-) Somehow the VCS seems at stake now. Okay, let's go on. Thanks and sorry should I have provoked too much writing. Let's go into another turn. Andreas Cheers, -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements
Am 25.03.2011 16:54, schrieb Barry Warsaw: On Mar 25, 2011, at 09:51 AM, Andreas Röhler wrote: while considering the request valid, even if the current non-indent is an option, what's the recommendable indent? Would not choose the block-indent step, rather signal it's something different at stake. What about indenting it to the end of first element of previous line? ;;; (longer, sequence, of_items, that, needs, to_be, wrapped) = input_list packed_entry = (long, sequence, of_items, that, needs, to_be, wrapped) ;; I must be missing something because these two snippets get indented like this for me, running r405: -snip snip- (longer, sequence, of_items, that, needs, to_be, wrapped) = input_list packed_entry = (long, sequence, of_items, that, needs, to_be, wrapped) -snip snip- which seems exactly right to me! Noticed. As different styles are possible, think we can deliver what has been requested for. If you do introduce a variable to control this, please do retain the current behavior as default. Okay. Would help having an appropriate name for these indents. What about calling the first an `left-inbound indent' --default will be 1--, the second `right-inbound-indent' --default will be (1+ column of opening parentesis)-- Cheers, -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements
Am 25.03.2011 19:32, schrieb s...@pobox.com: I find this indentation truly grating: self.last_abc_attr = self.last_xyz_attr = \ self.last_abc_other = \ self.last_xyz_other = None Now, I can move self.last_xyz_attr to a continuation line, but though the result is slightly different, it is, in my opinion, just as bad: self.last_abc_attr = \ self.last_xyz_attr = \ self.last_abc_other = \ self.last_xyz_other = None What I would like to see is this (given a four-space block indent): self.last_abc_attr = \ self.last_xyz_attr = \ self.last_abc_other = \ self.last_xyz_other = None or, if the second expression remained on the first line: self.last_abc_attr = self.last_xyz_attr = \ self.last_abc_other = \ self.last_xyz_other = None I don't care if this behavior is the default. I just want to be able to control it. Currently, I have to manually format lines like this, and if I'm not careful and reindent an entire function or file, then python-mode undoes my work. Skip Hi Skip, think that may be done. As it's a different thing though than indenting inside tuples, lists etc., would you mind making a bug entry giving your last examples? Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] myrkwid ready to merge?
Hi Barry, AFAIS all indent-bugs reported are done with Myrkwid branch. Provided tests from inside Emacs for it: py-bug-numbered-tests.el Also tests may be run in batch-mode: python-mode-tests.sh Please have a look if it's ready: https://code.launchpad.net/~a-roehler/python-mode/myrkwid The core is re-written, so would not merge without your consent. API however should be unchanged, beside some extra delivered. Functions moving point are designed around `py-beginning-of-statement', `py-end-of-statement' with `py-travel-current-indent' stepping downwards. Also `py-compute-indentation' redone. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid ready to merge?
Am 28.03.2011 16:55, schrieb Barry Warsaw: On Mar 26, 2011, at 07:08 PM, Andreas Röhler wrote: AFAIS all indent-bugs reported are done with Myrkwid branch. Provided tests from inside Emacs for it: py-bug-numbered-tests.el Also tests may be run in batch-mode: python-mode-tests.sh Please have a look if it's ready: https://code.launchpad.net/~a-roehler/python-mode/myrkwid The diff is pretty big, but I'll try to find some time to review the python-mode.el parts. its just the move-, mark parts which have changed. The diff is confusing. In the meantime, I'll grab your branch and use it for a few days. Before it gets merged, I think Skip should definitely do the same to test for XEmacs compatibility. If XEmacs tqs-syntax is still broken, he will not have more fun than with the trunk. XEmacs users for now should be best off with components branch. Might remain some dependencies still to solve, but the basics for non-pps parsing are available. Should Skip report XEmacs related bugs of components branch, I'm ready to implement the missing parts - cc to him. Cheers Cheers, -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el cleanup
Am 30.03.2011 04:58, schrieb Christoph Scholtes: Stefan Monniermonn...@iro.umontreal.ca writes: Could you just clarify why they're considered obsolete (e.g. what would the user use instead)? `python-shell' is not needed since Dave's mode already had 'run-python' to invoke the python interpreter. It offers no advantages over run-python as far as I can tell except being able to toggle between a Python and a Jython shell (see below for comments on that). `python-comint-filter-function' is only called from `python-shell'. `python-file-queue' is never populated anywhere, only read from `python-comint filter-function'. `python-default-interpreter' is only used by `python-shell' and not, as advertised in its documentation, on first visiting a Python mode buffer. `python-python-command-args' and `python-jython-command-args' are only used in the `python-toggle-shell' function. `python-which-shell', `python-which-args' and `python-which-bufname' are used for toggling between the Python and Jython shell. Finally, `python-toggle-shell'. I think, that we should provide a better solution for this and therefore remove the current implementation. This code came from python-mode.el, if I traced that back right. Hi Christoph, glad to see Emacs python facilities improve. As you mention python-mode.el, there are some remarks in python.el which I feel are not correct. If some solution predates historically another, there are usually some setbacks from being the first. OTOH from my perspective python-mode.el has still some point in proceding. Hopefully we may discuss the pro and cons to the benefit of users, which flavour they may choose finally. As you might have been remarked, its interwoven to an extend, you can seldom discern it clearly to the one or other origin. BTW I'm not blaming the GNU's side. Just wanted to point at the issue so we might hopefully reduce the obstacles. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ Python interpreter selection should be universal and not only support Jython and CPython, but also IronPyton, PyPy etc. I would like to implement a better solution for this as soon as Fabian's changes are installed. I am using IronPython quite a bit and it would be nice to be able to switch flexibly between different interpreters. Christoph ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid bug with backspace/delete
Am 31.03.2011 17:36, schrieb Barry Warsaw: Hi Andreas, myrkwid branch still has a minor problem. -snip snip- class Foo: def foo(self): pass -snip snip- Put point at the end of the 'pass' line. Hit return. Indentation is correct. However backspace/delete never moves. Cheers, -Barry Hi Barry, checked in fixes. Also cured a mistake of 745208'-fix, where python- and emacs-lisp logic has been came across... Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid bug with backspace/delete
Am 01.04.2011 21:58, schrieb Barry Warsaw: On Apr 01, 2011, at 12:31 PM, Andreas Röhler wrote: checked in fixes. Also cured a mistake of 745208'-fix, where python- and emacs-lisp logic has been came across... Thanks Andreas! Things are looking better, but still not quite perfect. ;) -snip snip- def foo(): a = bar(one=1, two=2, three=3) -snip snip- Put point at the closing parenthesis and hit return. You get lined up under the 't' in 'three' whereas you should be lined up under the 'a'. Hi Berry, it's lined below `t' indicating the multiline character. I'm afraid we are here in a sphere, were people will ask for different styles. Unless I miss something. What about storing that as a bug report and coming back at a later time? BTW after merge would adress the execute/shell/unicode errors. OTOH if you think it must be now it will be now... :-) Cheers Andreas Cheers, -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid branch indentation bug
Am 06.04.2011 00:51, schrieb Barry Warsaw: Here's another myrkwid branch bug. I've updated to r474 of the branch. Great, thanks. BTW I'm not sure how to proceed here. Shall I push further into myrkwid, or rather freeze it, opening a new branch for any progress? -snip snip- def foo(): The foo thing. -snip snip- Put point on the last line just after the period and hit return. You end up in column zero of the new line, but you should end up under the first double quote. Cheers, -Barry Thanks, see it. Reported as 752252 indent-triplequoted-to-itself Cheers Andreas ___ 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] myrkwid branch indentation bug
Am 06.04.2011 16:14, schrieb Barry Warsaw: On Apr 06, 2011, at 08:18 AM, Andreas Röhler wrote: BTW I'm not sure how to proceed here. Shall I push further into myrkwid, or rather freeze it, opening a new branch for any progress? I think myrkwid is coming along, and I'm happy to keep running it to test it out. My preference would be to keep myrkwid open, and improving, for a little while longer. Let's close it when it's ready to be merged to trunk. I don't think it's quite there yet, but it's not far. Is anybody else testing the myrkwid branch on a daily basis? Hi Barry, don't know. Completely agree having all bugs and basics done first before proceeding. Checked in the fix of bug reported yesterday. Cheers Andreas -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] beginning-of-defun-function
Hi Barry, facing several difficulties with beginning-of-defun-function, like to normalize `py-beginning-of-def-or-class' taking just one argument C-u. That would help in many respects. I'm aware it entangles precious heritages :-) Default would be def-or-class, while C-u would mean `class-only'. Unless you are vetoing... Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] beginning-of-defun-function
Am 07.04.2011 20:40, schrieb Barry Warsaw: On Apr 07, 2011, at 01:26 PM, Andreas Röhler wrote: facing several difficulties with beginning-of-defun-function, like to normalize `py-beginning-of-def-or-class' taking just one argument C-u. That would help in many respects. I'm aware it entangles precious heritages :-) Default would be def-or-class, while C-u would mean `class-only'. Unless you are vetoing... There are a couple of things to consider. First, the function is used both interactively and programmatically. It would probably be better in the long run to split that into two different functions, Hi, that should be done already. We should have three different functions now: beginning-of-def, -of-class, -of-def-or-class and if possible, retain the second argument for the interactive use. It doesn't seem like `count` is used programmatically in python-mode.el. AFAIK it's never been used, nor was it received by a form inside. Second, TBH, I've never actually used the second argument myself. Yes, I use the `class` argument all the time. So I *personally* don't mind if the second argument goes away, but it might indeed be important to other users (who may not be on this mailing list). My concern was the `either', as beginning-of-defun expects a numeric argument. Now the `t' in the cond delivers the same regexp as `either', ie the default when called without arg has changed. That way its usable as beginning-of-defun-function - DTRT without argument. Would assume, no one will notice the change, wanted to mention it nonetheless. Cheers, Andreas Cheers, -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] [Bug 328786] Re: python-mode kills arrow in gdb (gud.el)
Hi, these bug seems not to exist any more with GNU Emacs 23. Here at the breakpoint a red point is left, while a yellow arrow walks down at the fringe. Does anybody notice this bug still? If yes, please send a complete bug report again. Thanks Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode for cython/pyrex?
Am 11.04.2011 10:22, schrieb Georg Brandl: On 08.04.2011 17:21, Mihai Badoiu wrote: is there a python equivalent emacs mode for cython/pyrex? thanks, --mihai I've hacked together something once: https://bitbucket.org/birkenfeld/dotemacs/src/9cea541dda89/cython-mode.el Georg ___ Hi Georg, Hi Barry, would assume it useful delivering a copy alongside with other stuff from python-mode.el. Agreed? Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] revno and releases
Hi Barry, when closing [Bug 531034] Re: Add py-class-name-face? the question arised, if flag should be set to fixed or released. Assume the latter. Is there a way to determine at which revno/branch the last release is done? Thanks Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
Am 15.04.2011 13:49, schrieb Barry Warsaw: Hi Andreas, On Apr 15, 2011, at 08:59 AM, Andreas Röhler wrote: def foo(): x = dict( a=1, b=2, c=3, ) which looks okay for me. Except it's a regression from the trunk. Hi Barry, that might be. Admittingly worked the opposite direction. When the open paren ends a line, subsequent lines should get indented only one level, not to the space after an open paren. My understanding here was: when a listing --list, tupel, dict-- starts, line-breaks doesn't matter semantically, so attention should be laid onto the colum of list-starter. If you indent just the offset of former line, the column than indicates nothing specific, it's a purely graphical indent. So far at least my conclusion from bug #328842 - more flexible indentation of continued lists/tuples/dicts Seems headed into something wrong :( At least, that's the way it should work by default. If 4 spaces after assignement start shall be the rule, we get next bug report, should someone leave out the spaces, which would produce a nasty def foo(): x=dict( a=1, b=2, c=3, ) Note that it doesn't have anything to do with the assignment, or the dict. It's the open paren ending a line that's the critical thing here. Here's another example. This is what myrkwid gives you: -snip snip- def foo(): do_something_first( a=1, b=2, c=3, ) -snip snip- But this is what trunk gives you: -snip snip- def foo(): do_something_first( a=1, b=2, c=3, ) -snip snip- Well, if we have just these both cases, we can use a boolean. A further problem with myrkwid is that if I'm typing the first few lines: -snip snip- def foo(): do_something_first( a=1, -snip snip- and now I realize that 'a=1' is indented too far to the right, so I manually correct it to start under the 'o' in 'something'. Then I go to the end of the line and hit return. I end up with this, which is definitely not correct: -snip snip- def foo(): do_something_first( a=1, b=2, -snip snip- 'b' should line up under 'a'. See what I mean? Yeah, second indent is right, first wrong :) OK, going to re-install the trunks behavior at least as an option/default. What about `py-indent-honor-listing' - which would be `nil' meeting your preferences? Cheers Andreas Would make that customizable with a var align-to-dict or so, which would be true here, nil the default. (?) BTW: indent should go along with meaning, if possible. Well, you being the authority :) Or just the most adventurous and vocal, anyway :). Indentation controlling variables should be well-named and discoverable, but you just have to be careful to capture the right semantics. In this case, the indentation has nothing to do with assignments or dicts, but everything to do with lines that end in open parens. Hope that helps! PS Applied patch from 691542 this morning. Will push it into myrkwid also. Awesome, thanks! -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
Am 15.04.2011 22:24, schrieb Barry Warsaw: On Apr 15, 2011, at 10:28 PM, Andreas Röhler wrote: Am 15.04.2011 22:09, schrieb Barry Warsaw: On Apr 15, 2011, at 10:01 PM, Andreas Röhler wrote: checked in the fix meanwhile. Behavior of trunk now default again. I just grabbed the update and it looks good. Thanks, I'll use this version over the weekend. As for the new variable, would prefer a pure boolean for simplicity. Maybe `py-indent-honor-listing' docstring already tells what's in question? So would t or nil give the default behavior? Nil - it's negligent now, doesn't care for listing... How about then, calling it py-indent-honor-open-paren? Also good. But let's reflect maybe a little further: point for me is not just the open paren, but the multiline-form it introduces. Open paren followed by a closing same line are not of interest here. Therefore the `listing', which doesn't express that sufficiently either. Cheers Andreas nil would still mean default behavior. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Control-L's break myrkwid
Am 15.04.2011 23:20, schrieb Barry Warsaw: Oh you're going to love this one Andreas. ;) -snip snip- class Foo: def baz(self): ^L -snip snip- I'm not sure this will come through on the email, but there is a control-L in column zero of the last line. Now put point the line after `def baz` and hit TAB. You'll get a max-lisp-eval-depth error. Remove the ^L and it works fine. Note that Python treats ^L's as whitespace. Cheers, -Barry Hi, there is a phenomena I already experienced occassionaly, but couldn't track the cause: max-lisp-eval-depth error is caused by py-compute-indentation AFAIS. Now, when run it under edebug all goes through. Result is 8, correct. Afterwards also with normal exec error is gone. Will look into tomorrow further. Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
Am 16.04.2011 13:01, schrieb Georg Brandl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.04.2011 23:41, schrieb Andreas Röhler: Am 15.04.2011 22:24, schrieb Barry Warsaw: On Apr 15, 2011, at 10:28 PM, Andreas Röhler wrote: Am 15.04.2011 22:09, schrieb Barry Warsaw: On Apr 15, 2011, at 10:01 PM, Andreas Röhler wrote: checked in the fix meanwhile. Behavior of trunk now default again. I just grabbed the update and it looks good. Thanks, I'll use this version over the weekend. As for the new variable, would prefer a pure boolean for simplicity. Maybe `py-indent-honor-listing' docstring already tells what's in question? So would t or nil give the default behavior? Nil - it's negligent now, doesn't care for listing... How about then, calling it py-indent-honor-open-paren? Also good. But let's reflect maybe a little further: point for me is not just the open paren, but the multiline-form it introduces. Open paren followed by a closing same line are not of interest here. Therefore the `listing', which doesn't express that sufficiently either. FWIW, I would have no idea at all what py-indent-honor-listing does if I just saw the name. Georg what about `py-indent-honor-multiline-listing' ? Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] xemacs or Python mode
Am 16.04.2011 18:11, schrieb Eric S. Johansson: (I originally sent this to the xemacs list and forgot to send it here) Only Your friendly list mates can tell for sure In some buffers of Python code and not others when I press the backspace key, it tells me: symbols function definition is void: looking-back. I'm testing out on the latest branches of Python-mode and I'm trying to figure out if this is something I'm doing wrong with xemacs or it is a bug. What do I need to do to debug this? --- eric ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode XEmacs should implement it. Here it is for the moment: (when (featurep 'xemacs) (unless (functionp 'looking-back) ;; from GNU Emacs subr.el (defun looking-back (regexp optional limit greedy) Return non-nil if text before point matches regular expression REGEXP. Like `looking-at' except matches before point, and is slower. LIMIT if non-nil speeds up the search by specifying a minimum starting position, to avoid checking matches that would start before LIMIT. If GREEDY is non-nil, extend the match backwards as far as possible, stopping when a single additional previous character cannot be part of a match for REGEXP. (let ((start (point)) (pos (save-excursion (and (re-search-backward (concat \\(?: regexp \\)\\=) limit t) (point) (if (and greedy pos) (save-restriction (narrow-to-region (point-min) start) (while (and ( pos (point-min)) (save-excursion (goto-char pos) (backward-char 1) (looking-at (concat \\(?: regexp \\)\\' (setq pos (1- pos))) (save-excursion (goto-char pos) (looking-at (concat \\(?: regexp \\)\\') (not (null pos)) ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] xemacs or Python mode
Am 16.04.2011 21:44, schrieb Eric S. Johansson: On 4/16/2011 1:31 PM, Andreas Röhler wrote: Am 16.04.2011 18:11, schrieb Eric S. Johansson: XEmacs should implement it. it should but I'm getting the exception. Here it is for the moment: hmm could not find this code in the myrkid branch. Do another `bzr pull' to get it. Just pushed it up. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] dropping py-emacs-features
Am 18.04.2011 11:32, schrieb Andreas Röhler: Hi, while hunting bug #691542 --SyntaxError on py-execute-region-- consider to drop const `py-execute-region'. Typo: py-emacs-features is at stake Assume, if used at all, things should rather be fixed at the source than dealt with here. Should somebody use it, please send a note. Thanks Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ ___ 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] I think myrkwid branch is ready to go
Am 20.04.2011 12:47, schrieb Barry Warsaw: Hi Andreas, After a few days of using the latest rev, myrkwid seems pretty good to me. I think it's time to merge it into trunk and address any remaining issues there. I'd like to update the trunk to bzr format 2a after myrkwid is merged. Feel free to go ahead and do the merge (I'll do the update), or reply if you want me to merge it into trunk. Great work! -Barry Hi Barry, merged myrkwid -r495. Commit message isn't perfect, however might be sufficient as intended something like a lot of bugs fixed. Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] code/macros to reformat code
Am 11.05.2011 18:24, schrieb m h: On Wed, May 11, 2011 at 12:20 AM, Andreas Röhler andreas.roeh...@online.de wrote: Am 11.05.2011 00:44, schrieb m h: Folks- I was wondering if anyone has some code floating around to reformat code after the code passes a certain column (say 79 or 80). What I'm looking for is reformatting long lines. I'd like to convert something like (assume the k of junk is around 78): my_string = foo bar baz ... junk stuff etc to: my_string = foo bar baz ... junk stuff etc Hi, assume your result must read: my_string = foo bar baz ... junk stuff etc The only way I see is transferring quotes into triple-quotes, in case py-fill-string takes action. Nope, my example meant what I wrote. I don't want the newlines that triple quoted strings would bring with it. I want to split up a longer than 80 (or what have you) string into multiple lines. cheers, -matt Hmm, if you change my_string = foo bar baz ... junk stuff etc into: my_string = foo bar baz ... junk stuff etc then stuff etc will not be assigned to my_string any more. Are you prepared to give it up? If not, please deliver an example with a working final state... Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] What is the current status of python-mode?
Am 25.05.2011 16:51, schrieb Donald Ephraim Curtis: when I try to insert an if statement emacs throws an exception that python-skeleton-if cannot be found. is the repo in a bad state and something people can contribute to? reviewing the mailing list didn't indicate anything out of the ordinary. am I doing something wrong? ___ Hi, could you tell which python-mode version and which Emacs version you are using? An entry in the bug tracker might assist fixing: https://bugs.launchpad.net/python-mode For the moment: disabling abbrev-mode in that buffer should help. Regards, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] What is the current status of python-mode?
Am 25.05.2011 16:51, schrieb Donald Ephraim Curtis: when I try to insert an if statement emacs throws an exception that python-skeleton-if cannot be found. is the repo in a bad state and something people can contribute to? reviewing the mailing list didn't indicate anything out of the ordinary. am I doing something wrong? ___ Hi, checked in a fix, which should keep the python.el abbrevs/templates away. Could you try the current trunk? Thanks, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] py-master-file behavior doesn't work
Am 08.06.2011 16:16, schrieb Roman Dzvinkovsky: Hi, even when I set py-master-file variable locally in python buffer, py-execute-buffer and others still use temporary file, so I can't see context in IPython. Is it broken or I do something wrong? Thanks in advance, Roman. Thanks for the report. Made an entry in the bug-tracker at https://bugs.launchpad.net/python-mode/+bug/794850 Please consider subscribing there in order to get upcoming discussions. Could you try the patch against py-execute-region? (IMO exists a respective bug still at py-execute-import-or-reload.) ;;; === modified file 'python-mode.el' --- python-mode.el 2011-05-27 06:58:43 + +++ python-mode.el 2011-06-09 05:38:38 + @@ -1889,9 +1889,11 @@ (let* ((filename (expand-file-name py-master-file)) (buffer (or (get-file-buffer filename) (find-file-noselect filename - (set-buffer buffer))) -(py-execute-region (point-min) (point-max) async) - (pop-to-buffer old-buffer))) + (set-buffer buffer) + (py-execute-region (point-min) (point-max) async) + (pop-to-buffer old-buffer)) + (py-execute-region (point-min) (point-max) async) + (pop-to-buffer old-buffer (defun py-execute-import-or-reload (optional async) Import the current buffer's file in a Python interpreter. ;;; ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] Fwd: Re: adding a standard font-lock-number-face
Hi, would make a bug report/feature request for that. Opinions? Cheers, Andreas Am 17.06.2011 05:54, schrieb Fabian Ezequiel Gallina: 2011/6/17 Stefan Monniermonn...@iro.umontreal.ca: So long story short: isn't a good idea to add a standard font-lock-number-face in order to have fine grained control on font-lock and give the users the chance to customize numbers decoration out of the box? I don't think highlighting tokens that are only lexically relevant but not syntactically relevant is a good idea. E.g. it's good to highlight keywords because they determine structure. It's good to highlight strings and comments because keywords within them *don't* determine structure. It's good to highlight identifier definitions because these are semantically important and they tend to be a bit like section titles, so syntactically meaningful. But it's not useful to highlight all identifiers, or all numbers, or all separators, or all infix operators, ... because that doesn't help the user navigate his code. Thanks for the clarification Stefan, I was pretty sure there was a good reason why it wasn't there already. An argument I can think of for inclusion is that it seems highlighting those kind of stuff (event operators) is really common on other editors, so it is acceptable that people coming from other places would expect this kind of stuff highlighted out-of-the-box. I know the people coming from other editors argument is kinda weak, but I don't see why not giving them the chance to enable that easily in a vanilla Emacs. Please note that I'm no expert at font-locking but I think it might be good (and possible) to let modes to specify a higher or special level of font-locking so this kind of things can be highlighted. Let the default be the standard Emacs way, but giving the users the chance to enable that special level easily. This way standard font-lock performance shouldn't be hit. What do you think? Regards, Hi Fabian, don't know if my opinion here values a cent at all, :) but let me tell that IMO you are right. As long as the default set not differs ie inherits from default face, the user normally will not notice that customizable. OTOH user looking for will find it. Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] adding a standard font-lock-number-face
Am 17.06.2011 14:17, schrieb Barry Warsaw: On Jun 17, 2011, at 08:34 AM, Andreas Röhler wrote: would make a bug report/feature request for that. Opinions? Personally, I think it's overkill. Agreed, will not use that. However, as the OP pointed at, users switching from other editors asked for. IMHO a similar thing as with intellisense, which isn't that useful as it looks nice. In some time we should have that too for the reasons above. I agree that making the default indistinguishable would lessen the fruit salad look, but I wonder if it's really all that useful. I guess I would compromise by not adding any py-* faces to handle these. If there are already existing font-lock-* faces for these types of things, adding some regexps to recognize them in Python code would be okay, as long as performance doesn't suffer. Just my opinion though. -Barry OK, that should be a path, Andreas Am 17.06.2011 05:54, schrieb Fabian Ezequiel Gallina: 2011/6/17 Stefan Monniermonn...@iro.umontreal.ca: So long story short: isn't a good idea to add a standard font-lock-number-face in order to have fine grained control on font-lock and give the users the chance to customize numbers decoration out of the box? I don't think highlighting tokens that are only lexically relevant but not syntactically relevant is a good idea. E.g. it's good to highlight keywords because they determine structure. It's good to highlight strings and comments because keywords within them *don't* determine structure. It's good to highlight identifier definitions because these are semantically important and they tend to be a bit like section titles, so syntactically meaningful. But it's not useful to highlight all identifiers, or all numbers, or all separators, or all infix operators, ... because that doesn't help the user navigate his code. Thanks for the clarification Stefan, I was pretty sure there was a good reason why it wasn't there already. An argument I can think of for inclusion is that it seems highlighting those kind of stuff (event operators) is really common on other editors, so it is acceptable that people coming from other places would expect this kind of stuff highlighted out-of-the-box. I know the people coming from other editors argument is kinda weak, but I don't see why not giving them the chance to enable that easily in a vanilla Emacs. Please note that I'm no expert at font-locking but I think it might be good (and possible) to let modes to specify a higher or special level of font-locking so this kind of things can be highlighted. Let the default be the standard Emacs way, but giving the users the chance to enable that special level easily. This way standard font-lock performance shouldn't be hit. What do you think? Regards, Hi Fabian, don't know if my opinion here values a cent at all, :) but let me tell that IMO you are right. As long as the default set not differs ie inherits from default face, the user normally will not notice that customizable. OTOH user looking for will find it. Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] more speech driven how twos
Am 17.06.2011 16:02, schrieb Eric S. Johansson: making more progress on some of the tools I need for speech or programming. [ ... ] Hi Eric, thanks reminding at that. Seeing you introduced a blueprint. Your previous text went into the `second-level-commands'. As said, would like to do that. As soon as we solved issues around python v2-v3 file exec, I'll hopefully address the matter. Meanwhile you could instruct us still a little bit about the specific environment in use. Could you send a kind of technical description of your system? Which programs do the speech recording etc. Do you use emacsspeak? Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] more speech driven how twos
Am 18.06.2011 15:00, schrieb Eric S. Johansson: BTW what are suitable returns from Emacs report functions for you. As choices coming into my mind for the moment are: - simple get it returned yes as in position = Emacs_fetch (current character position, buffer = focus) buffer_list = Emacs_fetch (buffer list) that looks like a list of values as parse-partial-sexp returns for example, right? [ ... ] I didn't get here overnight. It took me 18 years to become injured and 10 years to become frustrated with speech recognition and then another five years to figure out how to not become frustrated only become frustrated because I couldn't pay people to write the code for me. joys of being a serial entrepreneur self-employed type person. If you think this is interesting, you should see what I'm doing for diabetes self-management tools. I really need to get that done so I can pass the demo to potential funders which is part of the reason why I need these Emacs extensions. Everybody has an ulterior motive. :-) Even if neither Emacs nor Python related, I'll take occasion to mention Chaumont Devin, a poet from Hawai, who wrote some interesting computer linguistics and told a similar story beside. Here the adress of his language works: http://panlingua.net/ Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] more speech driven how twos
Am 19.06.2011 19:28, schrieb Eric S. Johansson: On 6/18/2011 3:41 PM, Andreas Röhler wrote: Am 18.06.2011 15:00, schrieb Eric S. Johansson: BTW what are suitable returns from Emacs report functions for you. As choices coming into my mind for the moment are: - simple get it returned yes as in position = Emacs_fetch (current character position, buffer = focus) buffer_list = Emacs_fetch (buffer list) that looks like a list of values as parse-partial-sexp returns for example, right? I'll need a bit more of an explanation please. I looked up the definition of cars-partial-Saxby[1] and it was not clear to me. I need more context. Inside the python-mode archiv exists a pars-part-output.el it provides a function called parse-partial-sexp-iac which displays the output of parse-partial-sexp together with its explanation Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] more speech driven how twos
Am 19.06.2011 20:21, schrieb Eric S. Johansson: On 6/19/2011 2:00 PM, Andreas Röhler wrote: Inside the python-mode archiv exists a pars-part-output.el it provides a function called parse-partial-sexp-iac which displays the output of parse-partial-sexp together with its explanation er. I need a bit more of an example than that :-) I tried running it. that documentation made some sense but I really need to see an example of what it does. it reports the syntactic state of the code position. Returns a list. Below an explanation of it's elements and what they contain. car of this list is a number indicating the nesting, and so on: 0. depth in parens. 1. character address of start of innermost containing list; nil if none. 2. character address of start of last complete sexp terminated. 3. non-nil if inside a string. (it is the character that will terminate the string, or t if the string should be terminated by a generic string delimiter.) 4. nil if outside a comment, t if inside a non-nestable comment, else an integer (the current comment nesting). 5. t if following a quote character. 6. the minimum paren-depth encountered during this scan. 7. style of comment, if any. 8. character address of start of comment or string; nil if not in one. BTW XEmacs implementation is slightly different. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] execfile
[ ... ] Just a thought in context: as people my run parallel different versions of python --locally or send something to remote machines-- there should be a way to specify the version to run. This would override the default version-check. That would certainly be useful for *me* :). It's pretty typical that I want to run both Python 2 and 3 in different windows at the same time, but I could even imagine some folks might want to run Jython and Python 2, or even Python 2.6 and 2.7 and IronPython at the same time. If it's possible, there should be one default, with a fairly easy way to override on a case-by-case basis. Hi Barry, as it's progressing some specification in order to avoid re-writes: - buffer will be in a writing mode of python2 or python3 flavour. Should the mode-line indicates than python2 or python3 instead python? -- IMHO yes but tell... :) Nonewithstanding in which versions-mode the buffer is, user may select installed python versions to execute. Per default the python-version selected in buffer mode will be used. So far Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Bug 310354] Re: 3.0 execute into python session
Am 13.06.2011 23:02, schrieb Barry Warsaw: There are a couple of issues here. I'd like to see python-mode eventually grow better support for Python 3 and Python 2 at the same time. Probably Python 3 support should be a derived major-mode so things that are unique to it can be handled separately from Python 2 support. It would then be nice if python-mode could auto-detect which to use when possible (this will sometimes be difficult), or provide an easy way for the user to specify or switch to python3-mode (e.g. via an auto-mode-alist or some such). Definitely python-mode.el should at least keep a local variable that tells you whether the current buffer is Python 2 or Python 3. * Now, when you have such a variable, functions like py-execute-file can switch on that to decide what Python code to exec. For Python 3, I'd actually run something like this snippet: with open(r'%s') as python_mode_exec_hack: exec(python_mode_exec_hack.read()) Hi Barry, while it seems pretty close at finish, just to communicate some changes: If that local variable mentioned --lets call it py-which-shell-- doesn't exist, shebang, import will be queried, finally recurring to installed default Python. Ie in that (new) order: (setq active-shell (or py-which-shell (py-choose-shell-by-shebang) (py-choose-shell-by-import) installed-system-default-python M-x py-toggle-shell without arg will switch between Cpython und Jython - similar as now, but no numeric args required any more, while with C-u prompts for specific Python version - any reachable might be given, python2.7, python3.1 or whatever. Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] edit or navigate code by feature
Hi Eric, what about implementing a simplified navigation mode like such: just call an object: for example method, string, list etc. Emacs will look if inside such a thing. If yes, it marks it as region. If not, go forward to the next in buffer. Should take the common numeric arguments moving forward or backward. Once the region is marked, a couple of functions already are provided to work at it: see 'ar-bracket-region-atpt' 'ar-brace-region-atpt' and the like provided by thing-at-point-utils.el. which are delivered with https://code.launchpad.net/~a-roehler/python-mode/components-python-mode More stuff of that kind at: https://code.launchpad.net/s-x-emacs-werkstatt/ Might deliver shorthands within the new mode, so just saying brack instead of 'ar-bracket-region-atpt' should be enough than. Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] dropping electric-colon
Hi Barry, stumbling over a bug from `py-electric-colon' it looks there is nothing left to do for the command. Every C-j does py-newline-and-indent. Also if a deliberated indent is set, nothing left for electrics. Setting a colon is no magic moment so far. As it's a well known ancient thing - any opinions? Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] diff displays identical lines
Hi Barry, hi all, encountering a nuisance with diffs, getting displayed several identical lines while for example the only lines changed in recent commit r449 are: 2731 (setq erg (py-go-to-keyword py-block-or-clause-re -1))) 2731 (save-excursion (progn (setq erg (py-go-to-keyword py-block-or-clause-re -1))) 2732 (ignore-errors ( orig (py-end-of-block-or-clause) ; Can't see any tab-whitespace relation. Any ideas? `rcsdiff' here does the same BTW, so it's not a lp issue. 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 released
Hi all, proudly announcing the release of python-mode.el 6.0 at http://launchpad.net/python-mode/trunk/6.0/+download/python-mode-6.0.tgz It comes with some new commands, as shown below for `mark': py-mark-statement py-mark-block py-mark-block-or-clause py-mark-def py-mark-def-or-class py-mark-class py-mark-clause Resp. delete, copy, jump to beginning and end of python-programming-expressions. Also a couple of bugfixes are done based on a new core. Thanks to Barry and all assisting. Please file bug-reports at https://bugs.launchpad.net/python-mode Maybe have a look at next Milestone 6.0.1 https://launchpad.net/python-mode/+milestone/6.0.1 outlining intended developing. Cheers, Andreas -- https://launchpad.net/python-mode https://launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode.el 6.0 released
Am 23.07.2011 20:30, schrieb Glenn Linderman: On 7/23/2011 9:48 AM, Andreas Röhler wrote: Hi all, proudly announcing the release of python-mode.el 6.0 at http://launchpad.net/python-mode/trunk/6.0/+download/python-mode-6.0.tgz Installation instructions? nothing changed in this respect. python-mode.el should work stand-alone as the previous one. Seems like the prior python-mode was just a single file, so pretty straightforward, unpack to d:\somewhere, and then in the emacs rc: (add-to-list 'load-path d:/somewhere) (autoload 'python-mode python-mode Python Mode. t) make sure python-mode.el is earlier in path than python.el there are some known hassles, because both modes calling them python-mode The new one has lots of files, not sure what to do with them... have a look into the README anyway, did the same as above, and get the following error: Error in menu-bar-update-hook: (void-function region-active-p) thanks, will fix this for the moment please use: (unless (featurep 'xemacs) (defun region-active-p () and mark-active transient-mark-mode (not (eq (region-beginning) (region-end) (and mark-active transient-mark-mode (not (eq (condition-case nil (region-beginning)(error nil)) Gnu Emacs 22.1.1 here. I'd upgrade to a newer Emacs, but last time I tried, the better Unicode support was actually worse. (Trying to open files with Unicode names, and trying to paste in Unicode text from AutoHotKey.) Doesn't meet my experience. We are on Emacs23.3 which is the best Emacs ever IMHO. Andreas ___ 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] python-mode.el 6.0 released
Seems like the prior python-mode was just a single file, so pretty straightforward, unpack to d:\somewhere, and then in the emacs rc: (add-to-list 'load-path d:/somewhere) (autoload 'python-mode python-mode Python Mode. t) make sure python-mode.el is earlier in path than python.el Does add-to-list do that? Good question. M-x describe-variable RET load-path should tell you. As for the issues with python.el think the simplest solution in question is to load it directly. (load MYPATH/python-mode.el) Or do I need something else? python-mode.el should not need anything else. [ ... ] Doesn't meet my experience. We are on Emacs23.3 which is the best Emacs ever IMHO. Glad it is working for you, but it isn't for me. I offer the following description of the problem, but of course it is not a problem with python-mode. But it will serve to explain why my attempts to use 23.1 some time back and 23.3 today, have failed. None of Emacs 22.1.1 through 23.3 will open files on Windows containing certain characters in their names, partly because the name can't be typed properly, but it doesn't even work to drag files with those names into emacs. Probably an issue that is specific to Windows. Those same characters produce some weird error packet is undefined when certain characters are pasted into Emacs by Autohotkey, using at least 23.1-23.3. 22.1.1 doesn't produce the packet error, so is friendlier to those characters. Probably another issue that is unique to Windows and/or AutoHotKey interaction. I've tried reporting the packet error, and eventually someone responded to the email, but I never figured out a way to check on the status of a ticket, or figure out when or if it will be included in a production version of emacs. As I use AutoHotKey macros to generate non-ASCII symbols using an English keyboard, it is critical to my ability to use Unicode characters, and not being able to enter them using emacs makes such versions of emacs useless to me. I have never learned Emacs lisp, which is usually not a major problem in simply using Emacs, and I can copy/paste helpful tricks from various web sites for customization. But this is beyond my capabilities to analyze, so I may be stuck on emacs 22.1.1 until someone can fix the problem or until I have to give up emacs because 22.1.1 no longer works on some future version of Windows. Please write a bug report. Also posting on the emacs-help might be useful. 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 released
Please write a bug report. Also posting on the emacs-help might be useful. Thanks for your suggestions here, I know it is out of scope for python-mode. But reporting the bug in emacs 3 years ago, and the deficiencies of that process from a user perspective, do not encourage following the process again... Please take in consideration the tremendous work the Emacs core-developers are delivering. Have a look at what you get from it and ask where it's coming from. From my perspective these people deserve our assistance and patience likewise. I was hoping there might be some other interface to the process that I overlooked, or which augments the process whose documentation I was able to find, and, with great effort, follow. So, I did write a bug report email for this exact issue, for emacs 23.1, 3 years ago. But I have no way to check its status. http://debbugs.gnu.org/ Is there a different interface? The bug report email stuff doesn't work very well on Windows, I had to generate it to a file, and then send the file (or something weird, it has been 3 years since I reported it first, and I've maybe forgotten the details). Where is the best way to send the bug report? That way didn't seem to produce much response, and certainly not a response that I can monitor for status in any way and the problem still exists 3 years later. Pretty sad. What is the emacs-help and how does one post on it? Is that a newsgroup, an emacs feature, or a web site, or something else? http://lists.gnu.org/archive/html/help-gnu-emacs/ Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] branch lp:~handrake/python-mode/devel-0.1
Hi, had a look at your branch this morning which looks quit reasonable for me. When checking for a possible merge however detected, python-mode now don't make use of `py-shell-list' any more. Which doesn't mean it can't be re-introduced if needed. Could you check out the current trunk or release and tell if it fits your needs? Thanks and best regards, 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
Am 28.07.2011 10:33, schrieb David Miller: Nice work on this ! Just got around to upgrading to 6.0 and discovered that the python menu has the option Switch to interpreter which maps to the function py-switch-to-python This function is undefined in the python-mode source AFAICT (e.g. based on grepping the extracted tarfile) Any ideas where the function comes from? Hi, thanks for the report. Made an entry in the bug tracker for the moment. https://bugs.launchpad.net/python-mode/+bug/817389 If people could report bugs there, it's preferable to this list. Best regards, 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
Am 28.07.2011 10:33, schrieb David Miller: Nice work on this ! Just got around to upgrading to 6.0 and discovered that the python menu has the option Switch to interpreter which maps to the function py-switch-to-python [ ... ] Hi David, it turned out having two labels pointing at the same, starting a py-shell resp. switching to basically. Deleted the first. As labeling might be a matter of taste just to mention it here. Thanks again, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] py-execute-buffer and swap buffers
Am 28.07.2011 22:16, schrieb Andrea Crotti: This is something I noticed since some time. I have the latest bzr python-mode (but also before it was like this) and emacs GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.5) When I have only two buffers open, one with the source and the other one with the output, pressing C-c C-c (py-execute-buffer) swaps the two buffers every time, which is extremely annoying... Am I the only one seeing this? Hi Andrea. could you make an entry into the bug tracker? That helps maintenance a lot, for example as usually tests will be written after fixing it, which should address the bug number. Thanks, Andreas -- https://launchpad.net/python-mode https://launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] 6.0.1 errors
Am 06.08.2011 02:22, schrieb Eric S. Johansson: running 6.0.1 on xemacs 21.4.22 (cygwin) I get these two warnings (1) (warning/warning) Unknown req `min-colors' with options `(88)' (2) (warning/warning) Unknown req `min-colors' with options `(88)' ideas? Hi Eric, AFAIS your version of XEmacs has difficulties with highlight-indentation mode. Looks like errors come from `defface' there. That mode is not crucial. Ask at XEmacs-devel if they may make it work. For the moment you may savely comment out (require 'highlight-indentation) to get rid of the warning. BTW I'll make a bug report for this, thanks, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] xemacs Potential problem
Am 09.08.2011 02:43, schrieb Eric S. Johansson: I'm experimenting with the latest beta and try to figure out what's the right set of options for configure for production version and I got this error. Any ideas? Hi Eric, think that's related to XEmacs compatibility problem you reported already with https://bugs.launchpad.net/python-mode/+bug/821824 Please ask at XEmacs devel what to do. For the moment put a semicolon before (require 'highlight-indentation) in python-mode.el, that's all. highlight-indentation is an add-on mode, displaying what (current-indention) also is saying. You are not missing any crucial without that display. Nonetheless I'll make it not loaded for XEmacs, so you will not get that error anymore with upcoming version. HTH, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] script with indentation problems - Bug 818669
Am 09.08.2011 10:18, schrieb Glenn Linderman: On 8/8/2011 10:59 PM, Andreas Röhler wrote: Hi, 3) Line 1266 (authlist = None). Point in column 1. Hit TAB. ... Hit TAB again, and it gets indented 8 spaces instead 4. at my machine it stays at current-indentation with TAB, which is a new behavior Are you saying you are testing with a newer version than this morning's? I still see this behavior except that it sometimes happens with the second TAB, and sometimes with the third. What I don't understand is why TAB would ever move text more than one indent at a time (8 character positions instead of 4). Hi Glenn, restored the good old cycling behavior. New design remains available as py-indent-line-new. Please make a bug entry should something still don't work as expected. Also known indent bugs should be gone now. Thanks again for the reports, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] script with indentation problems - Bug 818669
Am 10.08.2011 10:52, schrieb Glenn Linderman: On 8/10/2011 1:11 AM, Andreas Röhler wrote: restored the good old cycling behavior. New design remains available as py-indent-line-new. I'm not sure what cycling behavior means? Is that documented somewhere? Now, and presumely earlier also, it's the following: when called at the outermost permitted indent it jumps back to column 0. From there it steps every py-indent-offset until outermost is reached again. py-indent-line-new in contrast always jumps to the outermost. Backspace is needed then jumping py-indent-offset steps back every hit. What about restricting RET to newline and _not_ indent BTW? In contrast to C-j - newline and indent. Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] Welcome Gennady N. Uraltsev
Dear Gennady, being very pleased you joined the team. As your hints already turned out helpful chasing bugs, I'm looking forward. Think that place at the crossing of Emacs and Python is right to get some suspense, to perform some nice things. A remark concerning future developing at the occasion: basically let's focus on fixing remaining bugs. Afterwards let's have and deliver an integration of assisting packages as Pymacs, Pydb, Rope etc. There is some stuff of my own speeding up editing which I want to integrate too. Will make a Blueprint for more detailed discussion of that. Welcome again, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] xemacs Potential problem
Am 19.08.2011 09:18, schrieb Eric S. Johansson: On 8/9/2011 1:35 AM, Andreas Röhler wrote: For the moment put a semicolon before (require 'highlight-indentation) in python-mode.el, that's all. ;; (when (featurep 'xemacs) ;; (require 'highlight-indentation)) yields (1) (file-mode-spec/warning) Error in File mode specification: menu keyword must be :config, :included, :accelerator or :filter: :help Backtrace follows: backtrace(nil t) # bind (standard-output standard-output handler-arg-name) backtrace-in-condition-handler-eliminating-handler(call-trapping-errors-Ldc9FC5Hr) # bind (errstr call-trapping-errors-Ldc9FC5Hr) #compiled-function (from /home/esj/xemacs-beta/lisp/files.elc) (call-trapping-errors-Ldc9FC5Hr) ...(17) [call-trapping-errors-Ldc9FC5Hr errstr error-message-string lwarn file-mode-spec warning Error in %s: %s\n\nBacktrace follows:\n\n%s File mode specification backtrace-in-condition-handler-eliminating-handler] 8 0x694((error menu keyword must be :config, :included, :accelerator or :filter :help)) signal(error (menu keyword must be :config, :included, :accelerator or :filter :help)) # bind (menuitem item menubar-p menu) check-menu-syntax((Python :help Python-specific Features [Shift region left py-shift-left :active mark-active :help Shift by a single indentation step] [Shift region right py-shift-right :active mark-active :help Shift by a single indentation step] - [Mark block py-mark-block :help Mark innermost block at point] [Mark def/class mark-defun :help Mark innermost definition at point] - [Start of block py-beginning-of-block :help Go to start of innermost definition at point] [End of block py-end-of-block :help Go to end of innermost definition at point] [Start of def/class beginning-of-defun :help Go to start of innermost definition at point] [End of def/class end-of-defun :help Go to end of innermost definition at point] - (Templates... :help Expand templates for compound statements :filter (lambda (rest junk) (abbrev-table-menu python-mode-abbrev-table))) - [Import/reload file py-execute-import-or-reload :help Load into inferior Python session] [Eval buffer py-execute-buffer :help Evaluate buffer en bloc in inferior Python session] [Eval region py-execute-region :active mark-active :help Evaluate region en bloc in inferior Python session] [Eval def/class py-execute-defun :help Evaluate current definition in inferior Python session] [Switch to interpreter py-shell :help Switch to `inferior' Python in separate buffer] [Set default process py-set-proc :help Make buffer's inferior process the default :active (buffer-live-p py-buffer)] [Check file py-check :help Run pychecker] [Debugger pdb :help Run pdb under GUD] - [Help on symbol py-describe-symbol :help Use pydoc on symbol at point] [Complete symbol completion-at-point :help Complete (qualified) symbol before point] [Find function py-find-function :help Try to find source definition of function at point] [Update imports py-find-imports :help Update list of top-level imports for completion]) nil) # bind (in-menu before submenu menu-path) add-submenu(nil (Python :help Python-specific Features [Shift region left py-shift-left :active mark-active :help Shift by a single indentation step] [Shift region right py-shift-right :active mark-active :help Shift by a single indentation step] - [Mark block py-mark-block :help Mark innermost block at point] [Mark def/class mark-defun :help Mark innermost definition at point] - [Start of block py-beginning-of-block :help Go to start of innermost definition at point] [End of block py-end-of-block :help Go to end of innermost definition at point] [Start of def/class beginning-of-defun :help Go to start of innermost definition at point] [End of def/class end-of-defun :help Go to end of innermost definition at point] - (Templates... :help Expand templates for compound statements :filter (lambda (rest junk) (abbrev-table-menu python-mode-abbrev-table))) - [Import/reload file py-execute-import-or-reload :help Load into inferior Python session] [Eval buffer py-execute-buffer :help Evaluate buffer en bloc in inferior Python session] [Eval region py-execute-region :active mark-active :help Evaluate region en bloc in inferior Python session] [Eval def/class py-execute-defun :help Evaluate current definition in inferior Python session] [Switch to interpreter py-shell :help Switch to `inferior' Python in separate buffer] [Set default process py-set-proc :help Make buffer's inferior process the default :active (buffer-live-p py-buffer)] [Check file py-check :help Run pychecker] [Debugger pdb :help Run pdb under GUD] - [Help on symbol py-describe-symbol :help Use pydoc on symbol at point] [Complete symbol completion-at-point :help Complete (qualified) symbol before point] [Find function py-find-function :help Try to find source definition of function at point] [Update imports py-find-imports :help Update list of top-level imports for completion]) nil) # bind (before menu-items menu-name menu-path
[Python-mode] python-mode.el-6.0.2 released
Hi folks, with the help of Glenn and Gennady a couple of bugs could be fixed. Thanks Barry constantly assisting. Get the new tarball at http://launchpad.net/python-mode/trunk/6.0.2/+download/python-mode.el-6.0.2.tar.gz Also some new features resp. commands are available: - `py-electric-comment' When inserting a comment, if starting a comment, indent accordingly. If a numeric argument ARG is provided, that many colons are inserted non-electrically. With universal-prefix-key C-u \#\ Electric behavior is inhibited inside a string or comment. - New commands `py-partial-expression': . operators delimit a partial-expression on it's level. Given the function below, `py-partial-expression' called at pipe symbol would copy and return: def usage(): print Usage: %s % ( os.path.basename(sys.argv[0])) |- == path os.path.basename(sys.argv[0])) --|--- == basename(sys.argv[0])) os.path.basename(sys.argv[0])) --|--- == sys os.path.basename(sys.argv[0])) --|--- == argv[0] while `py-expression' would copy and return ( os.path.basename(sys.argv[0])) ; Also for commands a shorthand is defined: (defalias 'py-statement 'py-copy-statement) which will mark, copy and return. - Commands implementing a behavior which customizing of `py-shell-switch-buffers-on-execute' would do: py-execute-buffer-no-switch py-execute-buffer-switch py-execute-region-no-switch py-execute-region-switch Enjoy, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Bug 821986] Re: feature request: byte-compile from commandline
2 Working with ESS makes me wish Emacs provided the same level of support (and unified level of support) for Python as it does for R. Definitely. If you could list the features missed, that would help. Listing together with a short description still more. All this into a Blueprint starts being perfect. :) (Or for that matter, as JDEE does for Java--or did, since I haven't worked with that for years 6.) another point of interest HTH, Tom Rochetom_ro...@pobox.com it did, thanks, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] pymacs integration/support
Am 08.09.2011 03:45, schrieb Tom Roche: Dunno if this is relevant or helpful, but here goes: I decided to install pymacs to enable me to use python-mode, as I'm preparing to do more serious work with python (via PyNIO). I encountered a minor problem installing pymacs, about which I posted the pymacs list, and got help from the developer, François Pinard. Along the way I mentioned that I was installing pymacs for use with python-mode, and he mentioned that he was not doing much emacs work, so I asked Tom Roche 2011-09-06 17:23, what are your plans for pymacs support? François Pinard Tue, 06 Sep 2011 20:21:08 -0400 Pymacs does not have that many bugs, so I guess I could maintain it with a moderate amount of work. The story is that I transmitted maintenance to someone else, years ago. Nothing happened for a long while, which is not really a problem, as when a package is stable, I do not see the need to make releases merely to create artificial activity. But, then, the new maintainer vanished, and after a while, I saw someone else who wanted to bloat Pymacs to the point of killing the idea (in my opinion). So, I resumed maintenance, more to salvage Pymacs than because I want control. Handoff to the python-mode folks? Surely no problem with me if they are interested. I would happily leave Pymacs to people who are reasonably competent, and more interested to users than to themselves. Moreover, Pymacs may be forked by anyone who would feel otherwise -- I really mean it to be free software! :-). This might ease pymacs integration, or just be One More Thing To Do-- I dunno. But if you are interested, Pinard is easy to contact: http://pymacs.progiciels-bpi.ca/index.html report problems, comments and suggestions to François Pinard at pin...@iro.umontreal.ca. HTH, Tom Rochetom_ro...@pobox.com Hi Francoise, hi Tom, that's really good news. think we should make sure Pymacs is available with python-mode, ie delivering a copy as a fallback, should it not being installed already. Probably we should include some checks. Andreas -- https://launchpad.net/python-mode https://launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] version number in trunk
Hi Barry, intend to write (defconst py-version 6.0.3) in trunk, ie having py-version expressed number of upcoming release instead of the last one. Think if user has opened two python-mode.el from trunk and release, it's visible that way from the number, what's the trunk. Just FYI, cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Debug technique for comint, need stdin/stdout logger.
Hi Oleksandr,
thanks for your contributions.
CC this to python-mode.el list.
Andreas
--
https://launchpad.net/python-mode
https://launchpad.net/s-x-emacs-werkstatt/
Am 22.09.2011 00:12, schrieb Oleksandr Gavenko:
07.09.2011 17:32, Oleksandr Gavenko пишет:
When work with Emacs comint I need logger for stdin/stdout process
interaction.
So I change name of calling program in Emacs
and that logger/script call original command and log
stdin and stdout to files.
I try write expect script:
...
I get working one.
It is used to debug interaction with Cygwin Python in 'python-mode'.
Expect come with all Linuxes and available under Cygwin...
#!/usr/bin/env expect
set in [open logger_in.log w]
set out [open logger_out.log w]
set timeout 3600
log_user 0
set stty_init {-echo}
# exp_internal 1
set cli [open logger_cli.log w]
foreach arg $argv {
puts $cli $arg
}
close $cli
eval spawn python2.6.exe $argv
set proc_id $spawn_id
expect {
-i $user_spawn_id -re (.+)\r?\n {
puts -nonewline $in $expect_out(buffer)
send -i $proc_id $expect_out(1,string)\n
exp_continue
} eof {
send -i $proc_id \x04
sleep 1
send -i $proc_id \x04
expect -i $proc_id -re .+ {
puts -nonewline $out $expect_out(buffer)
send_user $expect_out(buffer)
exp_continue
} eof { }
} -i $proc_id -re .+ {
puts -nonewline $out $expect_out(buffer)
send_user $expect_out(buffer)
exp_continue
} eof { }
}
close $in
close $out
wait
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
