Re: [Python-mode] Pymacs runs from python-mode
Andreas Röhler andreas.roeh...@online.de writes: started a Blueprint delivering the reasons for the kind of proceeding tried currently https://blueprints.launchpad.net/python-mode/+spec/pymacs Think such a Blueprint might be a good place for listing pros and cons. Using Make has it's merits too, bien sure. Hello, Andreas, and gang. After a quick visit to the link above, its purpose is not clear. Is that a device you happen to like for organizing your own thoughts on the matter, and where you can later direct people when you feel useful to so? If yes : nice, good, great! Enjoy, and have a lot of fun! :-) Am I expected to follow what's in it? No problem I get an email whenever it gets edited. Otherwise, as I really do not feel like having-yet-another-thing-to-check-daily. I have far too much already. Do you expect me to share ideas in there? Do you really expect me to use Web editors for speaking to a blueprint? I much prefer humans. And moreover, what's wrong with Emacs, email, and this mailing list? As a grown up, you surely not need me to jump into your chosen sandbox for organizing thoughts in your place, are you? *You* do that! ;-) If you want to help me organizing my own ideas, thanks, but I can manage. François P.S. Who hates the useless multiplication of maintainer toys, and who honestly needs a good incentive before taking the time it takes to study what each is meant to do, and how (badly) it does (not do) it... ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Andreas Röhler andreas.roeh...@easy-emacs.de writes: [...] we should let the user decide, what features to use: ipython or not, pdbtrack or pydb, which completion, refactoring, which checks and tests etc. As a general principle, users should have full control. However, if a user did not explicitly activate or inhibit features, python-mode should ideally check what's available and auto-configure itself while starting, in the most advantageous way possible for the user. Users should not have to explicitly turn on configuration switches to raise below some minimal configuration. The default python-mode behaviour should be on the side of the user rather than minimalism. If some use happens to not like an available feature which python-mode decide to be a desirable one, (s)he should turn it off explicitly. Just an example, by default, python-mode should have an *opinion* about the best way to auto-complete, and activate the *best* way possible, given what's has been installed besides python-mode. Of course, *best* is extremely debatable. Another example : I would consider that hideshow or highlight-indentation are desirable. Opinions may differ, and we cannot at the same time please me, you and everybody. Yet, python-mode should at least have an opinion. Not activating things, as a way to stay neutral and avoiding the expression of any opinion, does not serve the average python-mode user, who would prefer something as interesting as possible, by default, without having anything to do on the configuration side. François ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] making stack traces clickable in gud.el pdb output.
Barry Warsaw ba...@python.org writes: How do I invoke pdbtrack from python-mode? It's really easy. You still insert 'import pdb; pdb.set_trace()' at the spot in your code where you want to break. Then run your code from a shell buffer. When you hit the break point, you'll drop into pdb. pdb-track will notice the new prompt and you'll be able to interact with it right there. You'll use pdb commands but you'll get the nice two-screen view with code tracking. Hi, python-mode people. I quote Barry's explanation above, as an example of fruitful instructions about how to use python-mode. Looking at the mailing list archives, here and there, I read other nice advice or tricks. But it's a pity that these did not get collected into a user documentation. So my suggestions: * take the above quote and drop it *as is* within the README file (yes, the README, not in the doc/ directory, nor any fancier place). Right now, without hesitation. * whenever any usage advice is given on the list, someone with commit powers immediately copies it, as is, within the README. * do not try to devise a fancy structure or flowing text right away, the emergency right now is to give some informational meat to users, rather than a nice structure filled with lots of TBDs (to be done). The TBDs should go to the TODO file (which, by the way, is the traditional capitalisation for it), not in the README. * do not worry, structure will come very naturally, later, as material accumulates within README. Information first, structure later. * integrate the INSTALL file within README, get rid of it as a separate file. It is not worth a file as it stands right now. Let it grow within README, and give it an existence in a separate file only when it will hold enough substance to be worth its own file. Do not think INSTALL exists so people may start without having to read README. On the contrary, manage so users will more likely peruse README. * get rid of doc/, or at least change its name. Users are mislead to think there is a documentation in there that is usable for them. François P.S. Reading further, Barry wrote: I owe Ken Manheimer a lifetime supply of [insert beverage] for this beautiful hack. Sigh! If only I could have developed something so attractive that Barry did such an offer to *me*. I spoiled my life! :-) ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Don't bind C-c C-h
Deniz Dogan deniz.a.m.do...@gmail.com writes: Unfortunately, that breaks yet another convention, which is that C-c letter are for users and should not be bound to anything in any external mode. Doing `C-h m' while visiting a Python file, I currently see two culprits: C-c c py-compute-indentation C-x n d py-narrow-to-defun This is important to respect the convention. The space left for users to install their own keybinding is tiny, and should be respected. For one, I have many C-c letter prefixes, opening into a lot of three keys commands. By the way, let me mention that Org mode has a rather original way to circumvent this convention, without breaking it. If I remember correctly, they clearly and prominently document that users should install these bindings or prefixes themselves, explaining how to do so, and providing examples. Since the user does it, and not them, they are lawful good. Users then choose bindings differently than in the examples, if they know they would clash in some way. Forcefully defining C-c letter in modes with the excuse that users may redefine them if they do not like it, is breaking the convention. François ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] making stack traces clickable in gud.el pdb output.
François, Hah! So funny for you to bring up *that* specific post from Barry. It's been sitting in my inbox as msg #1 for the past couple years. Even though I copied it to my org notes, I've always had it there. So when your email arrived, my reader threaded it back to Barry's 2-year-old post. What!? Then I read your text and it all made sense. ;-) P.S. to Barry: My upgrade to Emacs 24 via launchpad has been a totally painless non-event. Jeff Shawn White Bauer Rubicon, Inc. On Thu, Jan 26, 2012 at 10:44:05PM -0500, François Pinard wrote: Barry Warsaw ba...@python.org writes: How do I invoke pdbtrack from python-mode? It's really easy. You still insert 'import pdb; pdb.set_trace()' at the spot in your code where you want to break. Then run your code from a shell buffer. When you hit the break point, you'll drop into pdb. pdb-track will notice the new prompt and you'll be able to interact with it right there. You'll use pdb commands but you'll get the nice two-screen view with code tracking. Hi, python-mode people. I quote Barry's explanation above, as an example of fruitful instructions about how to use python-mode. Looking at the mailing list archives, here and there, I read other nice advice or tricks. But it's a pity that these did not get collected into a user documentation. So my suggestions: * take the above quote and drop it *as is* within the README file (yes, the README, not in the doc/ directory, nor any fancier place). Right now, without hesitation. * whenever any usage advice is given on the list, someone with commit powers immediately copies it, as is, within the README. * do not try to devise a fancy structure or flowing text right away, the emergency right now is to give some informational meat to users, rather than a nice structure filled with lots of TBDs (to be done). The TBDs should go to the TODO file (which, by the way, is the traditional capitalisation for it), not in the README. * do not worry, structure will come very naturally, later, as material accumulates within README. Information first, structure later. * integrate the INSTALL file within README, get rid of it as a separate file. It is not worth a file as it stands right now. Let it grow within README, and give it an existence in a separate file only when it will hold enough substance to be worth its own file. Do not think INSTALL exists so people may start without having to read README. On the contrary, manage so users will more likely peruse README. * get rid of doc/, or at least change its name. Users are mislead to think there is a documentation in there that is usable for them. François P.S. Reading further, Barry wrote: I owe Ken Manheimer a lifetime supply of [insert beverage] for this beautiful hack. Sigh! If only I could have developed something so attractive that Barry did such an offer to *me*. I spoiled my life! :-) ___ 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] Don't bind C-c C-h
On Jan 26, 2012, at 11:03 PM, François Pinard wrote: C-x n d py-narrow-to-defun Is this one a problem? Shouldn't narrow-to-defun be mode-sensitive? (Also, it doesn't sit on C-c letter.) -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] making stack traces clickable in gud.el pdb output.
On Jan 26, 2012, at 10:12 PM, Jeff Bauer wrote: Hah! So funny for you to bring up *that* specific post from Barry. It's been sitting in my inbox as msg #1 for the past couple years. Even though I copied it to my org notes, I've always had it there. So when your email arrived, my reader threaded it back to Barry's 2-year-old post. What!? Wait. I wrote that two *freakin'* years ago?! P.S. to Barry: My upgrade to Emacs 24 via launchpad has been a totally painless non-event. \o/ So, who's gonna be at Pycon this year? -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Don't bind C-c C-h
Barry Warsaw ba...@python.org writes: On Jan 26, 2012, at 11:03 PM, François Pinard wrote: C-x n d py-narrow-to-defun Is this one a problem? Shouldn't narrow-to-defun be mode-sensitive? (Also, it doesn't sit on C-c letter.) Sorry, I misread! Strike this line out in my message! François ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Pymacs runs from python-mode
Am 27.01.2012 03:27, schrieb François Pinard: Andreas Röhlerandreas.roeh...@online.de writes: started a Blueprint delivering the reasons for the kind of proceeding tried currently https://blueprints.launchpad.net/python-mode/+spec/pymacs Think such a Blueprint might be a good place for listing pros and cons. Using Make has it's merits too, bien sure. Hello, Andreas, and gang. Bon jour François, After a quick visit to the link above, its purpose is not clear. Is that a device you happen to like for organizing your own thoughts on the matter, and where you can later direct people when you feel useful to so? consider it a kind of organizer for a certain title resp. task If yes : nice, good, great! Enjoy, and have a lot of fun! :-) Am I expected to follow what's in it? No problem I get an email whenever it gets edited. Otherwise, as I really do not feel like having-yet-another-thing-to-check-daily. I have far too much already. Do you expect me to share ideas in there? Do you really expect me to use Web editors for speaking to a blueprint? I much prefer humans. it's just a possibility, some editable notice. Always listening :) And moreover, what's wrong with Emacs, email, and this mailing list? Sending Mails onto the Blueprint works too As a grown up, you surely not need me to jump into your chosen sandbox for organizing thoughts in your place, are you? *You* do that! ;-) If you want to help me organizing my own ideas, thanks, but I can manage. it's rather to make public some project, discussion with results it. a kind of public reflecting. François P.S. Who hates the useless multiplication of maintainer toys, and who honestly needs a good incentive before taking the time it takes to study what each is meant to do, and how (badly) it does (not do) it... okay So let's come to the very issue of https://blueprints.launchpad.net/python-mode/+spec/pymacs not mentioned yet :) BTW did you see https://blueprints.launchpad.net/~fpinard Isn't that nice ;) Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Am 27.01.2012 04:12, schrieb François Pinard: Andreas Röhlerandreas.roeh...@easy-emacs.de writes: [...] we should let the user decide, what features to use: ipython or not, pdbtrack or pydb, which completion, refactoring, which checks and tests etc. As a general principle, users should have full control. However, if a user did not explicitly activate or inhibit features, python-mode should ideally check what's available and auto-configure itself while starting, in the most advantageous way possible for the user. Users should not have to explicitly turn on configuration switches to raise below some minimal configuration. The default python-mode behaviour should be on the side of the user rather than minimalism. If some use happens to not like an available feature which python-mode decide to be a desirable one, (s)he should turn it off explicitly. Just an example, by default, python-mode should have an *opinion* about the best way to auto-complete, and activate the *best* way possible, given what's has been installed besides python-mode. Of course, *best* is extremely debatable. Another example : I would consider that hideshow or highlight-indentation are desirable. Opinions may differ, and we cannot at the same time please me, you and everybody. Yet, python-mode should at least have an opinion. Not activating things, as a way to stay neutral and avoiding the expression of any opinion, does not serve the average python-mode user, who would prefer something as interesting as possible, by default, without having anything to do on the configuration side. François Thanks! IMO a quite perfect description of some principle to act. Think it's good to keep that somewhere, being able to refer to also for new users/developers studying python-mode stored it here for the moment: https://blueprints.launchpad.net/python-mode/+spec/features title might be to change still ___ 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 27.01.2012 05:44, schrieb François Pinard: Andreas Röhlerandreas.roeh...@online.de writes: (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. While I understand Andreas reply, we should not loose sight that Python users do not necessarily want to know that much about Emacs. There is a quite a long way between starting Emacs to edit Python code, and knowing about Emacs variables, discovering M-x functions like describe-variable (there are so many of these functions, and so many ways to get help), and load-path details. To develop python-mode, knowing Emacs more deeply is inescapable. To use python-mode, we should expect about nothing from user knowledge about Emacs Lisp. So, for any basic good question, this is python-mode's README that should tell you. It should be sufficient to get fully started. François will add that onto https://blueprints.launchpad.net/python-mode/+spec/features Thanks, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
