Re: [Python-mode] Fwd: Simplifying python-mode.el
I personally only tend to use py-execute-region (C-c |) and py-execute-buffer (C-c C-c). Are you proposing to change or remove those? -Barry > On Jul 13, 2019, at 23:16, Andreas Röhler wrote: > > Forwarded Message > Subject: Simplifying python-mode.el > Date: Sat, 13 Jul 2019 09:56:32 +0200 > From: Andreas Röhler > To: Barry Warsaw > > > Hi Barry, hi all, > > consider to reduce the amount of commands starting with `py-execute-...` > > Such things like py-execute-block-ipython-dedicated-switch. > > It would remain > > py-execute-block-ipython > > running in dedicated buffer when called with C-u > > For switch and split options there are already > > py-switch-buffers-on-execute-p and > > py-split-window-on-execute > > Just FYI. > > Any objections? > > Cheers, > > > Andreas > > > > > ___ > Python-mode mailing list > Python-mode@python.org > https://mail.python.org/mailman/listinfo/python-mode signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode.el partial rewrite
Great, thanks for all your great work on the module. I’ve updated to 639532b and will play with this for a while. -Barry > On Jul 10, 2019, at 01:14, Andreas Röhler wrote: > > Hi Barry, hi all, > > should have fixed IPython completion and fontification, also #31, > > which caused some changes. Maybe check it out. > > Cheers, > > Andreas > > signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] py-shell interactively switch
On Jun 12, 2019, at 00:23, Andreas Röhler wrote: > > Current behavior is ruled by ‘py-switch-buffers-on-execute-p’, which > defaults to nil - display the result but don't move cursor thereto. > > Assume yours is customized to ‘t’, so new setting proposed here would > make no difference. Got it. +1 from me then. :) -Barry signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] py-shell interactively switch
Sorry, I’m unsure how what you propose differs from the current behavior. Cheers, -Barry > On Jun 11, 2019, at 05:01, Andreas Röhler wrote: > > Hi all, > > when starting a Py-shell interactively like M-x python RET, > suggest to switch into newly opened shell by default. > > Agreed? > > Cheers, > > Andreas > > > signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] lean navigation
Hi Andreas. Thanks for continuing to work on this library. Honestly, I haven’t noticed any performance problems in a long time. python-mode.el continues to work great for me. -Barry > On Dec 29, 2018, at 03:01, Andreas Röhler wrote: > > Hi all, > > when a class has a large amount of defs inside, jumping to the end of > class might take some noticeable time. (Albeit don't see a bug report so > far.) > > For now, navigating Python source internally is done by > ‘py-forward-statement’ resp. ‘py-backward-statement’ - where > ‘statement’ means just ‘section of code starting at its own indent’. > While this seems complete and reliable, it does several checks we > might get rid off in certain circumstances when speed matters. > > For example when jumping to the end from a known block-start, may > reason from the current indentation: any further start lesser/equal > indented can't be part of. > > This makes some assumptions WRT formatting and might fail in case of > uncommon or mixed formats using semicolons for example. As it's about > an editor here and not about a lexer/parser IMO the change might be > worth it. OTOH: how often exist these large classes? > > Maybe have a customizable boolean py-use-speed-navigation-p? > Just a RFC, > > Cheers, > Andreas > > > > > > signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Dropping position functions
On Jan 7, 2019, at 09:56, Andreas Röhler wrote: > > while in another re-write WRT speed and maintenance --see my previous post-- > stumble over a couple of functions reporting position like > `py--beginning-of-if-block-position' - which doesn't look useful. Consider to > drop them. Any objections? AFAIK, I don’t use them, so I don’t have any particular objections. BTW, I am playing with built-in python.el just to see what the main differences are these days. I ran into this one pretty quickly: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33979 Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Python docstring folding
On Nov 21, 2018, at 02:21, Andreas Röhler wrote: > > is this worth a feature request? It’s not something I personally use, but I know other people like it. -Barry signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Simplifying python-mode.el
On Nov 10, 2018, at 01:52, Andreas Röhler wrote: > > For example reduce the number of addressed executables: keeping > python3 and python2, but removing python2.7. Respective at IPythons > side. Several minor changes already done these days. `/usr/bin/python2` doesn’t exist everywhere, unfortunately. Since Python 2.7 will EOL in January 2020, maybe that’s the time to remove python2.7? -Barry signature.asc Description: Message signed with OpenPGP ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Simplifying - drop decorator special forms
On Nov 12, 2018, at 03:15, Andreas Röhler wrote:
>
> as decorators are part of function definitions, consider to drop all special
> handling. Beginning of def-or-class would reach the decorator - same with
> mark, copying and send.
Is it possible to use C-u to choose whether to go to the first decorator or the
function definition? Remember, you can have a bunch of function decorators,
not just one. So going to the first decorator could put you way off from where
you expect.
E.g. if you use click, from Mailman 3:
@click.command(
cls=I18nCommand,
context_settings=dict(help_option_names=['-h', '--help']),
help=_("""\
Master subprocess watcher.
Start and watch the configured runners, ensuring that they stay alive and
kicking. Each runner is forked and exec'd in turn, with the master waiting
on their process ids. When it detects a child runner has exited, it may
restart it.
The runners respond to SIGINT, SIGTERM, SIGUSR1 and SIGHUP. SIGINT,
SIGTERM and SIGUSR1 all cause a runner to exit cleanly. The master will
restart runners that have exited due to a SIGUSR1 or some kind of other
exit condition (say because of an uncaught exception). SIGHUP causes the
master and the runners to close their log files, and reopen then upon the
next printed message.
The master also responds to SIGINT, SIGTERM, SIGUSR1 and SIGHUP, which it
simply passes on to the runners. Note that the master will close and
reopen its own log files on receipt of a SIGHUP. The master also leaves
its own process id in the file specified in the configuration file but you
normally don't need to use this PID directly."""))
@click.option(
'-C', '--config', 'config_file',
envvar='MAILMAN_CONFIG_FILE',
type=click.Path(exists=True, dir_okay=False, resolve_path=True),
help=_("""\
Configuration file to use. If not given, the environment variable
MAILMAN_CONFIG_FILE is consulted and used if set. If neither are given, a
default configuration file is loaded."""))
@click.option(
'--no-restart', '-n', 'restartable',
is_flag=True, default=True,
help=_("""\
Don't restart the runners when they exit because of an error or a SIGUSR1.
Use this only for debugging."""))
@click.option(
'--force', '-f',
is_flag=True, default=False,
help=_("""\
If the master watcher finds an existing master lock, it will normally exit
with an error message. With this option,the master will perform an extra
level of checking. If a process matching the host/pid described in the
lock file is running, the master will still exit, requiring you to manually
clean up the lock. But if no matching process is found, the master will
remove the apparently stale lock and make another attempt to claim the
master lock."""))
@click.option(
'--runners', '-r',
metavar='runner[:slice:range]',
callback=validate_runner_spec, default=None,
multiple=True,
help=_("""\
Override the default set of runners that the master will invoke, which is
typically defined in the configuration file. Multiple -r options may be
given. The values for -r are passed straight through to bin/runner."""))
@click.option(
'-v', '--verbose',
is_flag=True, default=False,
help=_('Display more debugging information to the log file.'))
@click.version_option(MAILMAN_VERSION_FULL)
@public
def main(config_file, restartable, force, runners, verbose):
# ….
Cheers,
=Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-mode mailing list
Python-mode@python.org
https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] before 6.2.1
On Jul 21, 2015, at 01:16 PM, Andreas Röhler wrote: in current trunk `interactive-p' is replaced by `called-interactively-p', just to reduce compiler warnings. `called-interactively-p' seems introduced only with 22.1, older Emacsen will be broken. Is this a concern? Not for me :). Cheers, -Barry pgpQz65mZFKZ1.pgp Description: OpenPGP digital signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Displaying symbols in customization buffer
On Mar 14, 2015, at 10:38 AM, Andreas Röhler wrote: Hmm, you seem not that much convinced. Well, for me it's slightly confusing to see this capitalized split, which I must reconstruct into the original name in order to understand which one is at stake. It's not so much unconvinced as it is whether it's worth it to fix it in python-mode, when it's an Emacs feature. I really don't like it in *any* customize buffers, but I think it might be too weird to see it displayed nicer only in python-mode. Better I think to push a fix (or option?) upstream. BTW consider to reduce the number of customizations, replace some by defvar. Notably for handing-over string-codes, setup-codes, like py-eldoc-string-code does. Users being confident to change this will know about setq. It probably does make sense to audit the knobs and see which ones are really useful for customizing. Or maybe split them into groups which I've seen in other modes. Cheers, -Barry pgpAf40DcmCZX.pgp Description: OpenPGP digital signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Displaying symbols in customization buffer
On Mar 13, 2015, at 03:51 PM, Andreas Röhler wrote: currently most of symbols in customization buffer get splitted, resulting parts are capitalized. Would prefer to display it with real name, which permits searching it. Any opinion about that? Isn't that just how customize works in Emacs? Cheers, -Barry pgpKFsD401bm8.pgp Description: OpenPGP digital signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Displaying symbols in customization buffer
On Mar 13, 2015, at 07:54 PM, Andreas Röhler wrote: Currently it looks strange - see attachment. Agreed, but what can python-mode do about that? It's just the way Emacs' customize feature works. Cheers, -Barry pgp_YIuWqysRh.pgp Description: OpenPGP digital signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Displaying symbols in customization buffer
On Mar 13, 2015, at 10:37 PM, Andreas Röhler wrote: writing something like :tag my-correct-py-symbol-name in defcustom I kind of wish Emacs did this by default, but that's a different discussion for a different forum. ;) Is it more helpful to python-mode users to add the tag or more confusing to Emacs users to see different behavior? It's up to you for Python mode! Cheers, -Barry pgpbSVZzTS47X.pgp Description: OpenPGP digital signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode.el-6.2.0 released
On Nov 28, 2014, at 08:30 PM, Andreas Röhler wrote: so it's out there finally. For new features see https://launchpad.net/python-mode/+announcement/13077 Congrats! I'll pull bzr and run from there. I can't update the Debian version while Jessie is in freeze. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Completion of symbols defined in current buffer
On Sep 01, 2014, at 06:02 PM, Andreas Röhler wrote: being inclined to drop that feature https://bugs.launchpad.net/python-mode/+bug/1001328 Emacs provides dabbrev-expand, which is Python-agnostic but fairly effectiv. Otherwise the buffers content needs to be evaluated - with means, it must be correct already. I'm probably not qualified to say whether the feature should be kept or not, since I use dabbrev exclusively. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] TAB in script buffer
On Jun 25, 2014, at 04:04 PM, Andreas Röhler wrote: lately TAB in Python shell was bound to `py-shell-complete-or-indent'. What about doing likewise in script buffers - where TAB is currently `py-indent-line'? Unfortunatly the default completion-key M-TAB is used by most X-windows systems, so users must re-configure first. Binding it to TAB would solve that. BTW in this case completion should only be called at end of line and with word before. Otherwise TAB would `py-indent-line' - as a second TAB would do also. Comments? Hmm, maybe. I'd have to try it for a while to make sure it doesn't interfere with normal code editing. FWIW, I'm a big fan of dabbrev-complete. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] TAB-completion in Python shell
On Jun 02, 2014, at 09:06 AM, Andreas Röhler wrote: completion in py-shell always was M-TAB However, many people switching to python-mode.el expect TAB to complete there. Seems like a reasonable change to me. Indenting is pretty rare in a shell. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Reducing number of forms
On May 14, 2014, at 05:36 PM, Andreas Röhler wrote: in order to shrink the python-mode.el codebase a little bit, consider to support the following py-shell commands: python, ipython, python2, python3, jython, bpython Will drop python3.3. python2.7 etc. Calling other versions than default should be easy by mapping python3 onto PATH/TO/python3.4 That's probably fine. Maybe C-u should prompt for the name/path to the Python executable instead of the buffer? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] execute dedicated - multiple buffers?
On Mar 13, 2014, at 12:18 PM, Andreas Röhler wrote: currently, when dedicated is on, a new buffer is created with some autogenerated name. I don't really use this feature, so I don't have an opinion. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] different set of colors for pairs
On Oct 18, 2013, at 10:21 AM, Andreas Röhler wrote: IMO python-mode may provide what experienced developers need and beginners expect likewise - given the feature wanted will not go into the way of the real thing. In this case it wouldn't, as the default would inherit the key-word face. If we want to have more users and maybe developers, we must meet the wishes of beginners too - even if experience tells these wishes are not that justified to the extend. BTW there are also experienced programmers preferring what you called Tokyo-style - while I'm with you in the precise question. Adding things to font-lock-keywords themselves, that possibility is certainly at the core of Emacs. Demonstrating the relative easiness of extending at SO should encourage further action by the OP. You have to be careful though. More features means more complexity, in the code (which introduces bugs just purely through LoC increase), in the documentation, and in users' comprehension. It's not a pure win to add configurability and at some point it just gets too difficult to understand how all the different options interact with each other. It's okay to say no, and it's okay to be opinionated! This is after all, Lisp, and it's often just as easy for someone to hack their own .emacs files. I do think there's a lot of benefit in providing a lean, mean editing mode. Okay, thanks responding, Hmm, Barry, did you veto it? If you want to veto, please signal again, I don't feel like I have the right to veto python-mode decisions any more. For a long while you've done very nearly all of the work on the mode, so IMHO, that gives you the right and responsibility to make these types of decisions. I'm just a user these days. (But certainly still opinionated. ;) However, I would vote -1 on this particular feature. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org https://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Bug?
On Jun 14, 2013, at 10:24 PM, Andreas Röhler wrote: Is this a bug? http://stackoverflow.com/questions/17114573/python-mode-el-not-allowing-indentation-after-if-statement/17116654#17116654 It's bad form to use parentheses in this situation, but it *is* legal. It doesn't bother me if python-mode passive/aggressively discourage such bad form, but others might disagree. OTOH, this, which is perfectly fine form, seems to work well: def foo(): if (foo baz): bar() (i.e. parens used to span multiple lines.) -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Bug?
On Jun 14, 2013, at 05:04 PM, Felipe Reyes wrote: Hi All, On Fri, Jun 14, 2013 at 04:30:16PM -0400, Barry Warsaw wrote: It's bad form to use parentheses in this situation, but it *is* legal. It doesn't bother me if python-mode passive/aggressively discourage such bad form, but others might disagree. OTOH, this, which is perfectly fine form, seems to work well: def foo(): if (foo baz): bar() (i.e. parens used to span multiple lines.) This example raises a pep8 warning[0], Note that PEP 8 doesn't really recommend against this. There's even an example in the Maximum Line Length section that has this very problem. It's also true that there's no single convention or recommendation for dealing with this. I've been dealing with it and manually adding another indentation level to not leave 'baz' aligned with 'baz()' def foo(): if (foo baz): bar() Can this be considered a bug? I think python-mode should be able to handle it, but it needs to be configurable. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode.el-6.0.11 released
On Aug 15, 2012, at 07:35 AM, Andreas Röhler wrote: gladly announce release 6.0.11 of python-mode.el. Congrats! -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] freezed branches
On Jul 06, 2012, at 08:35 PM, Andreas Röhler wrote: in case a distro shipping python-mode.el declares a freeze, we may meet that creating a freezed branch mentioning that distro or release name Then developing might go on in trunk, whilst the freeze is honoured. I probably wouldn't tie a branch to any specific distro. That's setting a bad precedence that could potentially add lots of extra work if other distros want the same treatment. Instead, you could tie branches to python-mode version series. E.g. You could branch for 6.0.x and then 6.1.x would be developed on trunk. Just be cautious about any bug fixes you backport to the 6.0.x branch and don't backport any new features. It would then be up to distro's package maintainer ahem to cherry pick fixes from the appropriate branch during the lifetime of the stable distro release. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] huge files
On Feb 15, 2012, at 09:34 AM, Andreas Röhler wrote: think it's basically historical. People interested in developing/understanding might check out and use the components branch https://code.launchpad.net/~a-roehler/python-mode/components-python-mode I'm doing all my developing and Python editing there. It's sometimes ahead several days, if new features are introduced. But the same tests are run before commits, so a possible loss in stability is mince. BTW in future we could create a declared stable branch of components and make two tarballs for release. I've always thought that because python-mode.el is a separate download, it's better to have one big file. This makes it easier for users to add it to their Emacsen, even though it makes it more difficult to maintain, as rightly observed. But maybe we're at the tipping point where that trade-off should go the other way. Good, discoverable, installation documentation would go a long way toward alleviating those concerns. I run python-mode out of the bzr trunk, so I'm probably not a good use case. In a very real sense, this is Andreas's decision now. He who does the work, decides and Andreas has for quite a while now assumed primary ownership on the code, by virtue of his great work on the mode. I have no place to stand in the way of his decision on this. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] menu item names
On Feb 08, 2012, at 09:56 AM, Andreas Röhler wrote: being pointed at some irregularity menu items now display, what about to rename it that way: PyIndex PyShell PyTools PyCommands (?) BTW PyShell still should take the virtualenv stuff, when ready What are menus? :) Seriously, I have little useful feedback, as I disable all Emacs menus. Cheers, -Barry signature.asc Description: PGP signature ___ 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 27, 2012, at 11:19 PM, François Pinard wrote: Soon after Guido announced his first release of Python, a long long time ago, I tried it. At the time, I was trying everything :-). And besides, I was already prejudiced towards Guido because of his competent implication as a maintainer of the Audio/Sound FAQ (if I remember correctly). We corresponded for a little while on a friendly tone. I did not stay with Python for long, the window system coming with it was not as usable as I initially hoped. Life is such that I forgot the whole matter for about nine or ten years, maybe. I remember when comp.lang.python was created. Sure, I'm a Monty Python fan, but the first (seems like) several months of posts were just about the comedy team and had very little to do with a new language. So I ignored it, until about 1994. Then, Han-Wen (from the Lilypond fame) convinced me to give Python a good look. I guess it was Python 1.5.2 at the time, which I found very worth learning and using; no trace anymore of a window system or Emacs emulator to distract me from the language. Cleaning around, I found an old letter from Guido, written at the time of my initial tries, containing many interesting comments. So I replied specifically to these comments, and Guido replied to my reply, and we pursued the conversation exactly as if it has been from yesterday! :-) It was kind of surrealist, naive, and fun! How cool! -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
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] hide-show mode
On Dec 08, 2011, at 07:57 AM, Andreas Röhler wrote: to make commands like `hs-hide-block' work, hs-minor-mode must be switched on before. Consider to add a hook enabling this by default - alongside with a variable permitting to disable per defcustom. Perhaps just document that people need to enable this before it will work? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Credits
On Nov 12, 2011, at 09:23 AM, Andreas Röhler wrote: I'm in favor of introducing a CREDITS file, where all people who have sent code or bug reports --which is an important contribution too IMO-- are mentioned. I'm none too concerned about *where* folks get credited, but they definitely should get credit for contributing to python-mode.el's long and storied history. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Python Developers Emacs Environment - PDEE
On Nov 09, 2011, at 07:56 AM, Jeff Bauer wrote: Would it make sense for PDEE to be delivered through Marmalade? http://marmalade-repo.org/ I'm kind of excited that emacs will soon have a standard package manager. Wow, I don't know if I can handle that. I was kind of hoping to be able to go *another* 30 years of Emacs use without it. :) -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Bug 873372] [NEW] Comment indented incorrectly after inline comment
On Oct 13, 2011, at 06:41 PM, Andreas Röhler wrote: Am 13.10.2011 16:37, schrieb Barry Warsaw: On Oct 13, 2011, at 02:18 PM, Ryan Kaskel wrote: Another little comment bug: - foo = True # the next line is indented incorrectly # to here -- I think it should line up with 'f' in 'foo'. I'm not sure I agree entirely. I tend to avoid these types of comments, but I think this one is worth a discussion on the mailing list. so cc to it. I'm in favor of the present behavior BTW. However agree, there are two reasonable positions of a following indent. Would support a request that way: when cursor is at the indented comment in second line, a dedent should reach the column 0. In this case, but in cases where there is leading indentation, a dedent would reach that column. Right? Agreed? Seems reasonable to me. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] py-python-command default
On Sep 28, 2011, at 12:26 PM, Andreas Röhler wrote: FYI: when patch by Thomas --thanks again BTW-- was merged, py-python-command default changed 164 (defcustom py-python-command python 164 (defcustom py-python-command ipython Please tell if you want back the default python. Yes, please. :) ipython is a separate program that doesn't come with stock Python. BTW consider to deliver a couple of commands specifying the shell py-execute-region-python3 py-execute-region-python2.7 py-execute-region-ipython etc., which should be faster to use than customization. I think that would be nice. -B signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] py-python-command default
On Sep 28, 2011, at 01:15 PM, David Miller wrote: Yes, please. :) ipython is a separate program that doesn't come with stock Python. How about conditionally setting it - this is essentially what Django does with it's shell (defcustom py-python-command (if (executable-find ipython) ipython python) I'm not entirely in favor of this. While I have ipython installed, I still want to use regular 'ol python in my Emacs. Of course, should you make this change I can always customize the variable. OTOH, I don't want to stand in the way of what's really convenient for folks. So I guess I'm -0. Georg, what do you think? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Poll - Fwd: [Bug 858304] [NEW] variable name is highighted on LHS of equality (==) test, but shouldn't be
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sep 25, 2011, at 06:58 PM, Georg Brandl wrote: if anything is highlighted, then it should be only locals at assignment. Highlighting other assignments gets much too messy on the eyes (and if you start highlighting variable (no such thing in Python anyway) names on access too, you will have to color most of the code... Agreed, and personally, even highlighting assignments is too fruit salady for me so I'm glad it can be turned off. ;) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOf4+kAAoJEBJutWOnSwa/CC4P/1Ka6UxRYaLXan+y9dFe5Olc uV0tsT3HULuvi9aHgn4n2a6MrO0CChRESxp3Th3KrUHJMWaZYRhFXbTSofddC6CX OlbeuPJJDYeiv83A5k3EXOlcUZEtp8E1sbbFF3MLNbau7wdfb2ZM/COb0OWegSf9 qNU6yzTrcvxtaJ0ro0gFT7QthEa3GB43kGnhVxie5CteAkH1/v9KbmhL876BCm9L ysfx2dYwDqjnxezxZkTsunUci3+MSxjIBi3UJZNuwWQQY1Vh2YIOXsBQBaj78UtJ W8VtKNeL+IIewWmMzK2jkvw8NEgwFT5QtuULK/DqaMSyuJ7hDbsq0gAAhaf76dDw hJqBE2WDatVkGomnCQmoTZRrjd+EOLmnXgOxPE2Zr3hwLxmkJ822dDiJIjuLbi// QbVOUxTrw/KikEOezFc+RsmpSZvCBjR2zZZWIvua2MILOGVj0/1+LWU+zs5W6rzN cpDGHFiZc8+PZDYjtvniSG+uqZbVpMLwqbxIc2H4muThl/+X4OjTM2TnZtS1m2Dp whYf8zkxkNcriCiXHXGIQtshWnXQJyeYCESQqBqAzYuJui4UKrNHqrU9jLyw18TC ynAvkGwNyvOvMm0gGvHY0kEAmEGhNSnmGbPoh5pq+ij5Q/C//BcQtmagpPcgR9Pi cZubnJpdvII2Xm0KjZ7U =GlSw -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] version number in trunk
On Sep 12, 2011, at 10:17 AM, Andreas Röhler wrote: 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. There are lots of ways projects designate version number in unreleased branches. I tend to like doing x.y.z+ where x.y.z is the last official release. However, for python-mode, I think it's up to you how you want to handle this, so if this works best for you, go for it. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode modifies load-path emacs-wide.
I wrote a follow up rebuttal in the bug. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python-mode modifies load-path emacs-wide.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Aug 16, 2011, at 11:07 PM, Cavesnow wrote: I will try to explain my idea a bit better. Removing part with the direct modification of load-path I think is clear: a library shouldn't interfer with global settings. Agreed. If I understand correctly pycomplete would probably be loaded from inside python-mode and it is not meant to be a stand-alone library. Correct me if I am wrong. Andreas can answer that, but I can say that python-mode.el should be loadable standalone. It can use optional additional tools, but loading python-mode.el should not break if it can't find them, and basic editing, syntax highlighting, etc. should just continue to work. Anyway, since I have not found any place in the python-mode.el file where pycomplete.el nor did I find any auto-load instructions I thought of this solution. Let's say that at a certain point python-mode wanted to use functions provided in pycomplete and thus had to load it as a library. My idea was that in that case the loading was to be made this way: (let ((load-path (add-to-list 'load-path (concat py-library-path completion (load-library pycomplete) ) Rather, I think the right way to do this is to leave load-path hackery up to the user, but python-mode.el should have something like: (condition-case nil (require 'pycomplete) (error)) to just ignore it if it can't be found (or *maybe* echo a warning). Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOSugMAAoJEBJutWOnSwa/QUwP/0XYgRKYZB8GflhSAuSug41J 9GHHqePMjA0VyZK+VgRtqtEdyIJmCMKAST26BdgobJwBcjPtEQj9RRnbAkbToA2+ BAnndi8ToKgdMFBdLI6n7p854mP44/Y7EJQLKCFw08EqQmoWY8duPSnY6JLFVIXz NkPS9MbEst96ZNqSu7U7wTUGfm0fsa/9nd8P6R6Z0tYLlftz/vla2z1quDxG0fSI B+ZEKHE6zl8N9F8JptIyGBc293yBsqQ27nl1J0bhRh7CVkZq1/FltiLiqeSEd30w FfcKJavhrCQUQvuqIbzvJB/doZi6adi1f3wUiExtlvcnMXTBvSnH6dK8b2Pie/LR KvOoMMWR7t7Amo56W5xMDGON+FmmOK33mKiN6/pyl3hy/nFoWvp3qdQwI7u7xSt4 58XXxpS71yXBIKb2ZeLF4XOSNEP5EaL9g6vHbHXKx1VD5a2k3VvyowNXGa74CTIH 9pWC6zUV0ta5JD7721UOIwimxdQXBKOfh411X5Wdx/N+oiiAEVlFTT/TvORUrpt9 3Ml73gItH7h9qkRUu4Y5egPZinfq84CMEm0mc99TPf4kKJzl2X56vQignnhTBUTw XXDKlwO2aauhG2WbaK8P941w1k7LpQ54Xfku2Waivb3l+Kt+snqHTbHHLsHKfPh2 a6ZDtEGUrCANUFCvZjTD =XAWo -END PGP SIGNATURE- ___ 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
On Aug 10, 2011, at 06:09 PM, Andreas Röhler wrote: What about restricting RET to newline and _not_ indent BTW? Please no! You will physically hurt all of us dinosaurs. :) -Barry signature.asc Description: PGP signature ___ 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
On Jul 23, 2011, at 06:48 PM, Andreas Röhler wrote: 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 Congratulations Andreas! -Barry signature.asc Description: PGP signature ___ 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
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. 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 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 signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] execfile
On Jun 14, 2011, at 06:22 PM, Andreas Röhler wrote: should be a pleasure for me to proceed at this point. Fantastic! 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. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] execfile
On May 20, 2011, at 01:41 PM, Andreas Röhler wrote: think we should get the execfile issue fixed with next release too. Definitely. Sorry for letting this one get buried in my inbox, but I've now commented on the issue. What about introducing a var indicating the python version the code is intended to? +1 In case that var isn't set, the python version which py-execute-region would call, may be queried on the fly. Should I look for this? Yes please! python-mode.el should know whether the file it's visiting is Python 2 or Python 3, probably in a local variable which could be set automatically if you can find a decent clue (e.g. #!/usr/bin/python3). You might want to think of other ways to set this (file local variables, or auto-mode-alist perhaps?) Once you have that, then the mode can do all sorts of version-specific things, like doing different font-locking, or firing off a different Python shell, etc. In this specific case, you could run different Python code, as described in my bug comment. I think this would be a really valuable feature for python-mode.el. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
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. When the open paren ends a line, subsequent lines should get indented only one level, not to the space after an open paren. 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- 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? 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 signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
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? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
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? nil would still mean default behavior. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] Control-L's break myrkwid
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 signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
On Apr 14, 2011, at 07:59 PM, Eric S. Johansson wrote: On 4/14/2011 5:18 PM, Andreas Röhler wrote: Further fixes still ahead will take a little bit longer probably. Maybe we should keep the trunk for some days before a release, to get som e more testers. I can spend a little time this weekend testing. what do I grab? Andreas's branch can be had with: $ bzr branch lp:~a-roehler/python-mode/myrkwid -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid branch indentation bug
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? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el cleanup
On Apr 04, 2011, at 05:46 PM, Stefan Monnier wrote: ;; That isn't covered by an FSF copyright assignment (?), unlike this ;; code, and seems not to be well-maintained for Emacs (though I've ;; submitted fixes). I've said before, but it's worth repeating. While I still believe that at some point I did sign a copyright assignment for my contributions to python-mode.el, I also have absolutely no problem signing one again if for whatever (unimportant) reason, the FSF does not have one on file from me. The problem was with some of the other contributors, from what I remember. Is there a way to check specifically? I'm sure we could get Skip, Tim, and Ken to sign papers if necessary. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid bug with backspace/delete
On Apr 01, 2011, at 10:45 PM, Andreas Röhler wrote: 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. Right. But after the closing of the bar() function call, the next line can't possibly occur under the 't' because you'll get an IndentationError: -snip snip- def foo(): a = bar(one=1, two=2, three=3) x = 7 -snip snip- ## working on region in file /tmp/python-16786-mj.py... Traceback (most recent call last): File stdin, line 1, in module File /tmp/python-16786-mj.py, line 5 x = 7 ^ IndentationError: unexpected indent I'm afraid we are here in a sphere, were people will ask for different styles. Unless I miss something. Perhaps I didn't explain it well. Does the above example (default behavior for current myrkwid branch) make sense? 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... :-) This one I think has to be fixed now :) Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid ready to merge?
On Mar 31, 2011, at 11:56 AM, Andreas Röhler wrote: added still another python-mode-test.el, running test-cases independently from bugs reported: `py-run-tests' does for now 'py-beginning-of-block-test 'py-end-of-block-test 'py-beginning-of-block-or-clause-test 'py-end-of-block-or-clause-test 'py-beginning-of-def-test 'py-end-of-def-test 'py-beginning-of-def-or-class-test 'py-end-of-def-or-class-test Please tell, if there are cases you want to see. Cool, thanks. I've updated this and re-enabled it locally, so I'll play with it for the next few days. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el cleanup
Thanks for CC'ing me. I'm now subscribed to emacs-devel via Gmane. On Mar 30, 2011, at 04:10 PM, Andreas Röhler wrote: glad to see Emacs python facilities improve. As you mention python-mode.el, there are some remarks in python.el which I feel are not correct. If some solution predates historically another, there are usually some setbacks from being the first. OTOH from my perspective python-mode.el has still some point in proceding. Hopefully we may discuss the pro and cons to the benefit of users, which flavour they may choose finally. Yes, let's please try to converge Python support in Emacs as much as possible. I've heard there are now 4 Python modes, which if true, is really not helping users. All history aside, I applaud efforts to find ways to consolidate the modes, keeping in mind the features and behavior users find important from each of the flavors. Andreas is doing the majority of the work on python-mode.el these days, and we have a vibrant community on python-mode@python.org and an active project on Launchpad. I personally am much more of a user than developer these days (too busy with other things Pythonic), but by no means the only person using python-mode.el. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] myrkwid ready to merge?
On Mar 26, 2011, at 07:08 PM, Andreas Röhler wrote: AFAIS all indent-bugs reported are done with Myrkwid branch. Provided tests from inside Emacs for it: py-bug-numbered-tests.el Also tests may be run in batch-mode: python-mode-tests.sh Please have a look if it's ready: https://code.launchpad.net/~a-roehler/python-mode/myrkwid The diff is pretty big, but I'll try to find some time to review the python-mode.el parts. In the meantime, I'll grab your branch and use it for a few days. Before it gets merged, I think Skip should definitely do the same to test for XEmacs compatibility. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight-indentation
Hi Andreas, I don't disagree with anything you wrote, and of course we're allowed to use anything GPL'd. I don't think even politeness mandates pre-approval in order to *use* GPL code. The let's be nice comment wasn't directed at you personally, or really anybody here - I think we're all being nice, helpful, and polite, which to me is one of the most important principles of FLOSS. :) It also wasn't a comment on our use of GPL code. It was related to our bringing in a copy of someone else's file, which is already under their own VCS, into our VCS. Doing so could give the impression that we're the authoritative copy of the file. I wouldn't want to usurp someone else's authority on that without their approval. I hope that makes sense. Cheers, -Barry signature.asc Description: PGP signature ___ 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
On Mar 25, 2011, at 09:51 AM, Andreas Röhler wrote: while considering the request valid, even if the current non-indent is an option, what's the recommendable indent? Would not choose the block-indent step, rather signal it's something different at stake. What about indenting it to the end of first element of previous line? ;;; (longer, sequence, of_items, that, needs, to_be, wrapped) = input_list packed_entry = (long, sequence, of_items, that, needs, to_be, wrapped) ;; I must be missing something because these two snippets get indented like this for me, running r405: -snip snip- (longer, sequence, of_items, that, needs, to_be, wrapped) = input_list packed_entry = (long, sequence, of_items, that, needs, to_be, wrapped) -snip snip- which seems exactly right to me! If you do introduce a variable to control this, please do retain the current behavior as default. Cheers, -Barry signature.asc Description: PGP signature ___ 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
On Mar 25, 2011, at 08:58 PM, Andreas Röhler wrote: -snip snip- (longer, sequence, of_items, that, needs, to_be, wrapped) = input_list packed_entry = (long, sequence, of_items, that, needs, to_be, wrapped) -snip snip- What about calling the first an `left-inbound indent' --default will be 1--, the second `right-inbound-indent' --default will be (1+ column of opening parentesis)-- Those names seem pretty good to me. I would make both of them default to column_of_first_nonwhitespace_after_paren. E.g. ( one, two, three, four, five, six ) = things and ( one, two, three) = things Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[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
Hi Andreas. Did you really mean to commit a directory listing as a .el file? ;) -Barry Begin forwarded message: Date: Tue, 15 Mar 2011 11:11:16 - From: nore...@launchpad.net To: Barry Warsaw ba...@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 Roehler andreas.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 === added file 'py-bug-numbered-tests.el' --- py-bug-numbered-tests.el 1970-01-01 00:00:00 + +++ py-bug-numbered-tests.el 2011-03-15 10:08:05 + @@ -0,0 +1,46 @@ + /home/speck/arbeit/emacs/python-modes/python-mode-components: + insgesamt 1704 + -rw-r--r-- 1 speck users 4545 20. Aug 2010 string-strip.el + -rw-r--r-- 1 speck users 7354 24. Dez 14:36 sh-beg-end.el + drwxr-xr-x 3 speck users 4096 7. Jan 18:07 website + -rw-r--r-- 1 speck users 3274 7. Jan 18:07 pycomplete.py + -rw-r--r-- 1 speck users364 7. Jan 18:07 INSTALL + -rw-r--r-- 1 speck users 85097 7. Jan 18:07 doctest-mode.el + drwxr-xr-x 6 speck users 4096 7. Jan 18:07 .bzr + -rw-r--r-- 1 speck users424 10. Jan 12:12 python-mode-fixed-examples.py + -rw-r--r-- 1 speck users935 13. Jan 11:27 README + -rw-r--r-- 1 speck users 1566 13. Jan 11:28 pycomplete.el + -rw-r--r-- 1 speck users 1554 29. Jan 17:16 test-triple-strings.py + -rw-r--r-- 1 speck users 92 5. Feb 13:22 ToDo + -rw-r--r-- 1 speck users799 9. Feb 10:56 NEWS + -rw-r--r-- 1 speck users 15987 23. Feb 08:40 python-components-help.el + -rw-r--r-- 1 speck users 2520 23. Feb 08:40 py-bug-numbered-tests-example.el + -rw-r--r-- 1 speck users 8978 23. Feb 08:40 python-components-imenu.el +* -rw-r--r-- 1 speck users 21907 23. Feb 08:40 python-components-shell.el + -rw-r--r-- 1 speck users 10614 23. Feb 08:44 python-components-extensions.el + -rw-r--r-- 1 speck users 8142 23. Feb 08:45 python-components-pdb.el + -rw-r--r-- 1 speck users 6792 23. Feb 13:30 python-components-skeletons.el + -rw-r--r-- 1 speck users 21925 2. Mär 19:40 misc-utils.el + -rw-r--r-- 1 speck users 3742 6. Mär 08:53 python-modes-test + -rw-r--r-- 1 speck users930 6. Mär 13:00 vorlage-py-bug-numered-tests.el + -rw-r--r-- 1 speck users188 6. Mär 16:11 indentation-with-backslash-line-continuation-629916-exec-buffer.txt + -rw-r--r-- 1 speck users237 6. Mär 16:11 .bzrignore + -rw-r--r-- 1 speck users 18052 7. Mär 18:31 beg-end.el + -rw-r--r-- 1 speck users 20571 8. Mär 17:48 python-components-edit.el + -rwx-- 1 speck users 1966 9. Mär 16:59 test-python-mode-components +* -rw-r--r-- 1 speck users 58208 9. Mär 20:25 python-components-mode.el + -rw-r--r-- 1 speck users 2911 9. Mär 21:49 highlight-indentation.el + -rw-r--r-- 1 speck users 22333 11. Mär 08:46 ar-comment-lor.el + -rw-r--r-- 1 speck users 18972 11. Mär 21:16 python-components-intern.el + -rw-r--r-- 1 speck users 130637 12. Mär 10:10 thingatpt-utils-base.el + -rw-r--r-- 1 speck users 949711 12. Mär 10:11 thing-at-point-utils.el + -rw-r--r-- 1 speck users 4870 12. Mär 10:13 thingatpt-highlight.el + -rw-r--r-- 1 speck users 99233 12. Mär 10:13 thingatpt-python-expressions.el + -rw-r--r-- 1 speck users 26723 12. Mär 10:42 python-components-move.el + -rw-r--r-- 1 speck users 20557 12. Mär 12:02 python-components-test.elc + -rw-r--r-- 1 speck users 15669 12. Mär 12:25 py-bug-numbered-tests.el + -rw-r--r-- 1 speck users 14115 12. Mär 12:26 py-bug-numbered-tests.elc + drwxr-xr-x 21 speck users 4096 13. Mär 17:41 .. + -rw-r--r-- 1 speck users 21880 13. Mär 18:17 python-components-test.el + drwxr-xr-x 5 speck users 4096 14. Mär 10:57 . + drwxr-xr-x 2 speck users 4096 14. Mär 22:29 RCS signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] apropos py-bug-numbered-tests
On Mar 15, 2011, at 07:47 PM, Andreas Röhler wrote: To tackle remaining bugs, would change some lisp of python-mode.el towards more common forms. For example `py-save' now is as macro `ignore-errors' available. The question is cross-Emacsen compatibility, and also compatibility with older Emacsen. E.g. how far back does ignore-errors support and does it work with XEmacs? Also `py-point' forms IMHO rather obfuscate the code. Did see the explanation for it, but don't think it pays. I do like py-point a lot. Code was more verbose without it, so I do think it helps, and should be pretty easy to understand. OTOH, I guess you're doing the most work on the code now, so you get to decide. However I wouldn't necessarily recommend ripping it all out (IOW, if it ain't broke, don't fix it). Do I have green light for such a clean up? I'll leave it up to you, with the above caveats. Would commit every logical step, so it should be easy to revert, should some mistake occur. Maybe getting the tests working first would be a good idea? That way, you have some baseline to prove that your changes aren't breaking the code. What do you think? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] apropos py-bug-numbered-tests
On Mar 15, 2011, at 09:55 PM, Andreas Röhler wrote: Listen, Barry: the code is intrinsic for me to an extend, that I don't know how to fix the remaining bugs mentioned. All these bugs are absent in the components branch, because it's simplified from the scratch - more or less... Tried to backport some solution and could resolve some issues. But again and again going trapped into some wire. Obviously no one else could solve that over the years also. That's not a surprise. We are in some labyrinth, before some gordic knots. OTOH it's a pleasure for me to see solutions from different sides, python.el, components- and python-mode. So if you permit, will try to range things still. Tell if cannot bear it any longer :-) Do what you need to do! And remember that some code in python-mode.el is *ancient* so I'm not surprised if better and cleaner ways of doing things are now possible. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] r401 is broken
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
# Copyright (C) 2011 by the Free Software Foundation, Inc.
#
# This file is part of GNU Mailman.
#
# GNU Mailman is free software: you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free
# Software Foundation, either version 3 of the License, or (at your option)
# any later version.
#
# GNU Mailman is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
# more details.
#
# You should have received a copy of the GNU General Public License along with
# GNU Mailman. If not, see http://www.gnu.org/licenses/.
Testing i18n template search and interpolation.
from __future__ import absolute_import, unicode_literals
__metaclass__ = type
__all__ = [
'test_suite',
]
import os
import shutil
import tempfile
import unittest
from zope.component import getUtility
from mailman.config import config
from mailman.interfaces.languages import ILanguageManager
from mailman.testing.layers import ConfigLayer
#from mailman.utilities.i18n import find, make
from mailman.Utils import findtext
class TestFind(unittest.TestCase):
layer = ConfigLayer
def setUp(self):
getUtility(ILanguageManager).add('xx', 'utf-8', 'Xlandia')
self.template_dir = tempfile.mkdtemp()
config.push('template config', \
[paths.testing]
template_dir: {0}
.format(self.template_dir))
# Populate global tempdir with a few fake templates.
self.xx = os.path.join(self.template_dir, 'xx')
os.mkdir(self.xx)
with open(os.path.join(self.xx, 'nosub.txt'), 'w') as fp:
print fp, \
This is a template without substitutions.
def tearDown(self):
config.pop('template config')
shutil.rmtree(self.template_dir)
def test_find_global_template(self):
text, filename = findtext('nosub.txt', lang='xx')
self.assertEqual(text, 'This is a template without substitutions.')
self.assertEqual(filename, os.path.join(self.xx, 'nosub.txt'))
def test_suite():
suite = unittest.TestSuite()
suite.addTest(unittest.makeSuite(TestFind))
return suite
signature.asc
Description: PGP signature
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] highlight bug?
On Feb 25, 2011, at 12:18 PM, andrea crotti wrote: Before I wasn't sure if it was an old bug, but today I got the last revision from bzr and I see the same. Function and variable names containing reserved keywords are not highlighted correctly. For example in def generate_random_tuple() tuple is colored as it was the tuple function call... Anyone else seeing this? Not me. With r396 of python-mode.el I see this highlighting correctly. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Announcement of a new python major-mode on emacs-devel
On Feb 16, 2011, at 11:11 AM, s...@pobox.com wrote: I haven't tried it though I suspect you're right. However, how in the hell else are we ever going to reduce the number of different Python modes? So, today the new python.el maintainer seems happy. Assume GNU Emacs sucks it up. Two years from now the maintainer gets cranky, has a kid, I don't know, but something causes him to stop maintaining the code. You wind up with something which causes yet another fork. Will the GNU Emacs people ever accept XEmacs compatibility fixes? Honestly, I doubt it, but if the new python.el maintainer were reasonable, he'd accept patches for XEmacs compatibility. The harsh reality is that he probably won't be very motivated to develop those patches. But really, none of this would have happened if the Emacs people had resolved whatever problems they had with python-mode.el and just used it. Whatever. I'm not going down that path again. ;) It's ridiculous. I don't want to be a developer of this stuff. I just want it to work. Maybe it's just time to face the music and conclude that I should switch away from XEmacs. *sigh* I faced the very same dilemma two years ago. You know me, I was a XEmacs user since it was called Lucid Emacs. I loved it and I had tons of very cool specializations and custom elisp to make it work exactly how I wanted it to. Every few years I'd give GNU Emacs another try, find that it was missing some crucial stuff I really needed, and abandoned the effort. Then two years ago I was at a team sprint and I realized that not only was I in the minority as an *macs user (yes, all the kids seem to flock to Vim these days), but I was *really* an outcast as a XEmacs user. So I gave GNU Emacs one more chance and found that not only was almost everything I cared about in there, but I was also able to remove significant amounts of my custom elisp, and had my environment ported in just a couple of days. I honestly don't even miss XEmacs any more. I had a moment of silence for a great editor and moved on. It's sad to say, because Lucid Emacs/XEmacs was a great and very innovative editor in its day. Heck, I was almost even hired by Lucid to take over maintainership of it from JWZ[*]. But I think XEmacs's days are numbered if it isn't already irrelevant. GNU Emacs has re-established its leadership in innovation and has won back any lost mindshare. I apologized to Stephen Turnbull for my defection, but even he couldn't blame me too much. ;) I can only say that it wasn't that difficult to migrate, so you may want to give it a shot. If you were going to be at Pycon, I'd even give you a hand. -Barry [*] Moving to California, and Lucid's bankruptcy a few weeks after my interview kind of put the kibosh on *that* career move, which as it turns out was a good thing, or I'd never had met and worked with Guido. signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] release?
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? 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 signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el
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, 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. Apologies for fanning those old flames again. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el
On Feb 03, 2011, at 09:23 PM, Georg Brandl wrote: - From reading emacs-devel, it seems that the python.el has made changes to the mode and explicitly taken them out of the copyright assignment for the FSF, so Emacs upstream can't include them. So now we are at three different python modes for Emacs... :| Wonderful. http://thread.gmane.org/gmane.emacs.devel/135075 We should reach out and see if there's another opportunity for them to adopt python-mode.el. Anybody want to take that on? :) -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python.el
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Feb 03, 2011, at 10:13 PM, Georg Brandl wrote: Would we be able to find all the contributors and get them to sign papers for the FSF? Otherwise there's no need to even think about that step. At one point in the distant past we *did* that and sent it to the FSF (IIRC, Tim Peters, Ken M. and myself at the very least). IMHO, they lost the paperwork and we've been lax about tracking it ever since getting rebuffed. But aside from that, I would certainly be willing and able to assign copyright for my changes. Again. I haven't looked at the changelogs in a long time so I don't know how easy it would be to track everyone else down. Tim, Ken, Skip, Andreas, you should all be possible. I don't know if that's enough. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNSyPbAAoJEBJutWOnSwa/AGIP/0YUutvgBUIqmFVuj+w7dTL7 Lyx0w75+z5zsj6PdlEXqmiYxMgaiyoMeLTsunVbBAGh1wWZMHI9/LojPx580eKa5 1UzspXuZ/fPZFCZjuAA0WvHRQtb3hGVLMOF/Hh/NDg8KHJfj4Cx9gfBDATc0YdOT agMYjPvQLXeT+mfzfNRaLITPEBMkJxXa6G38uu7HkbNq0/AD6/RWFjRPUsJaOOE1 XEriv/8RXjBgrjceyJx7BSq6VeKcu1ZGd/PPw1j+obFojZlnN7TUZ2+S7lzwLvbO KTs+Til5SdIItG4ow1QSfFA0rXcACDuYUY3uE/a4U4mBsIA7egOJiuLFEabZX6eL RcvqjO+9lbxjGo+QN3WjkadWcR8sAQXayJCa/ZPg8rP/ZSfy+2ad5F9PQ4fZ8gzG axJINflyNK95ibuFq8QTmHuUj5FmkRMw0XCqmA5KHiKzLnWf/DgugTbQVwf5bClc 6WDLIm2n3f1g6GZHfQgf+s90gp3+Nork7FAa51SzTvBPVucSlK2V9oS9jiyT73m2 U0N1gjohR269gDwG9GfMPg6PSA4ZM0mWZ5tz6lCG3ZmpRV7KirXp5Uc+0x1ngT4W yjpu8eXHmmGxLN9hjwyU/nOuRw2LFNLhxeeolBfOjvonRWhGCuPhaLcu+W986cV4 qfOKbLaheOCzdyFH7KJ9 =+Rvs -END PGP SIGNATURE- ___ 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
On Jan 13, 2011, at 10:09 PM, Andreas Röhler wrote: 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 ) 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 As I said, you're doing the work, and this is internal stuff, so it's your call. :) signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Merge] lp:~a-roehler/python-mode/string-to-syntax into lp:python-mode
On Jan 12, 2011, at 09:34 AM, Andreas Röhler wrote: Bluntly said: Beside of the pps issue going to be solved, don't foresee keeping a fully compatible python-mode. Trying that, I'm afraid we will go out of business alltogether. A solution might be keeping an XEmacs compatible separate version. Would mean another split and python-mode version around... :( Which would effectively kill XEmacs support forever. If we were to fork, I suspect that fork would die a quick death. Better to keep one version even if XEmacs support is temporarily broken. If we don't have enough XEmacs testers or contributors to ensure it works before a release, we'll just to have to make a lesser guarantee and hope for patches from interested parties (hi Skip :). Speaking of which, I will wait until Skip gives me the green light and then I will release a 5.2.1 that fixes the XEmacs support. Just let me know. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Merge] lp:~a-roehler/python-mode/string-to-syntax into lp:python-mode
On Jan 12, 2011, at 07:16 AM, s...@pobox.com wrote: Why not just refer to the last version which was XEmacs-friendly on the Launchpad download site? I think 5.1.0. Modify 5.2.0 and greater if it's loaded in an XEmacs session that certain stuff won't work until such time in the future that it does work in that environment again. There doesn't seem to be a way to have the project page show downloads from anything but the current release. However, old releases are still there: https://launchpad.net/python-mode/+download Still, I think it would ultimately be best if we could continue to support XEmacs for basic editing. We'll have to rely on XEmacs users to test things, but I'm also happy waiting for Skip (or whomever) to give the green light for XEmacs compatibility before I announce a new release. I think it would also be okay if some reduced functionality is allowed to creep in, but let's be explicit about it. I.e. the mode should not crash in XEmacs, and basic editing should always work, but it would be okay if some Emacs-only feature were supported with no equivalent in XEmacs. But maybe there will come a point where XEmacs (or our support of it) just has to be declared dead. I dunno, and I don't want to make that decision, so as long as Skip's still using it I think we should try to continue to support it. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] simplified procedure
Hi Andreas, On Jan 11, 2011, at 09:55 AM, Andreas Röhler wrote: 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. Sure. I think it's fine to JFDI for trivial patches. After all, we have a version control system and post-commit notifications with diffs. I don't think you even need to do a merge proposal for those. - if funktion is changed, newly introduced, we could agree a simplified procedure, saying a delay of three days, so people may object. A merge proposal would be nice, and waiting a few days (perhaps with a ping on email or irc). Three days is probably fine, though be a little more lenient around weekends and holidays. Other than that, if you feel pretty confident about the change and no one responds, JFDI. There will be times when you might not be able to get anyone's attention for various reasons. I'd say that in the above two cases, you should not let that block your progress. Just self-approve the mp and commit. - in cases of fundamental change I won't act without your prior consent. Yep, behavior changes should require a higher barrier. A discussion on this mailing list would always be good (before, during, or after merge proposal is submitted). https://code.launchpad.net/~a-roehler/python-mode/string-to-syntax is still unmerged. It concerns XEmacs only (featurep 'xemacs)..., I commented on the mp. Cheers, -Barry P.S. Better to use my @python.org address for this mailing list. :) signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] simplified procedure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Jan 11, 2011, at 07:40 PM, Georg Brandl wrote: -BEGIN PGP SIGNED MESSAGE- Am 11.01.2011 16:20, schrieb Barry Warsaw: Sure. I think it's fine to JFDI for trivial patches. After all, we have a version control system and post-commit notifications with diffs. I don't think you even need to do a merge proposal for those. I agree -- in fact that's what I've been doing all the time except for the new font-lock faces. Me too. Yep, behavior changes should require a higher barrier. A discussion on this mailing list would always be good (before, during, or after merge proposal is submitted). Not sure if you and Andreas agree what a fundamental change or behavior change is. Oh that's easy. If it would confuse me or Guido, it counts. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNLJkWAAoJEBJutWOnSwa/AUgP/3ThvROSuJoJkSJaZSuaX9zc 2RZM6grqDKgokLKK3xsnHFGEryJHFBL1IPxmi572FDmm2hHJII0eiR03ROfYr5bS FTN90L0aY0GbWvuJypuVGCYh3L/pGzxA9Ho6QrG3cpM18lb9q3onvlNwdOCjYtVb hTZ2+UQuCBVSk5reeDGjodk99j79CZPrI5Vucy2NnCQIhDTN9IHg5HxOSdUlu79r ivn+9LiLLdWbviNb9RVXS7cCfA6Txd3lOKjdISRAnEV+LQQ3ngaG+VI8M9xDICsw wcoblWpfkT4ntdju0otzL/hTHxR4hW53puj2b63Ictr7EFGC0AEV7mqIDtLxNvSA kLhvURDI/D+zq0cgCB0RGCIxhv0ydFfBANFB1IsIg4yyMaal7u90Kr2jHKjabnhR fg2rfFlwNT/xdF2YHO6sq9ZgNMljzcvEbh0R/z594DTYdvRpK73/og3DLERG3d5G 3g8fCurtqxzQ8RPoi3egN4s0FxZex9A9JMQcqJ//3ym/9+DlUOAFsdOnfFs2HPho f6DBWTOoPi3OD4Aicx/BjysAoaFE0fMYkmA3erwE3N/l6laLMZf8Aj6tX6N5qp10 o5VP0f3N3x2Zy6TwgqYSKZo2Q5a7OGE1CPbWom4TbwGUNilYEBWnus31rVQebLVW sBhf958bgyBG6YbTPgbb =x1ne -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] avoiding edit wars
Hi Andreas, On Jan 09, 2011, at 08:34 PM, Andreas Röhler wrote: 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? To be honest, we're such a small project that I'd opt for less bureaucracy and more consensus. I think we'll probably end up agreeing 90% of the time, with another 9% where only one person cares. :) In the rare case of disagreement, let's bring the discussion to the mailing list and try to find common ground. If we can't then, to the effect that you still trust me to break the tie, I'm happy to do so. Happy to see things developing fast last days, what's great. Just makes it worthwhile to address upcoming dangers. Yes, it is fantastic all the work you've done and it's great to see Georg getting active too. Makes up for all the slacking I've done lately. :) -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] milestone 5.1.1
On Jan 09, 2011, at 08:29 AM, Georg Brandl wrote: I've now commented out the problematic code -- I'll try to find out more and maybe ask the Emacs devs, but it's not important enough to hold up a relese. BTW, NEWS says New in version 5.2.0, so if you want to call the release 5.1.1 you have to adapt this; however I'd say there are enough changes to warrant a minor-version step. I agree. I retired 5.1.1 and moved its items to the 5.2.0 milestone. I've tagged the tree and uploaded both the .el and the tgz file. Thanks for all your great work; I'm sending the announcement momentarily. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Time for a new release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Jan 07, 2011, at 12:24 PM, Georg Brandl wrote: It doesn't appear to affect behavior and I have no idea how to fix it, so I think it shouldn't block your branch. OK, it is now merged. Cool, thanks. Meanwhile, I found the bug -- I was trying to do too much at once. But please do test the solution as well. I've got r374 and will test it with real world code over the next few days. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNJzYQAAoJEBJutWOnSwa/Q7QQAI4lnzTNbfKhYsp0uGDQcj7N qHtA0zR8oD32KAc6GauWpTJBF/Y4tGkssshLgZ0PVgsEdcUGXyWjNPCWVDeYFBTf pA4ZFSct/8+gGCIukCRtT9RjvuxCSTnbmWxH6ngiaezFv6xSGOtcJwjnecPxtPt2 nSoJ+b0FQA9YyBjFqbrnKKNHel8M0TKFbuv3VGa/P6qy+GobBLdA9/OOzvbP41rs ZrK0OIbBjQdZ+DV6of2CYs2fcq5ojLfa0QbNPqvUexPso4vNxGCrMAU3Y4Q+I9ze xkM9siPrbHinjSiQ+mR+3bzIcj3Nfhbe23R4ul3gpu1dMbeIj6z60bODUv0SJyr2 kK/bCSAmI+k6c+74ETcx5fgDONkyZ4Vz7iPbTsshp2XVUY+ehASgYbKuDkYzeZwM /nSc2/lFiP4Guly/fQdkBfXhnbzRqka72XJGOfLblUlsrnd8BWijY+1dKxhMIFQo hjVDiuTxSJZ0wHX8aGUZHKcLoRjhgjNy62N/lYDd62FPVQplEMxyqd2HrzXDvOfY eHqb0wozB0AAqJ3wGtgDmgFx3EvZKIF0QpBAUaYmG0FQcEE3OehfpF9mkXPThVfW 0+eKEYZzYPoHiRl0CHiWZsYj795NxEehgF3HiFWdiDyHJVJARfKc3vWKyavn+x6M V37/1oywiJPrxFEi0jjO =3EwK -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Time for a new release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Jan 06, 2011, at 09:00 AM, Georg Brandl wrote: Okay, I'll have a look at the customization issue. It doesn't appear to affect behavior and I have no idea how to fix it, so I think it shouldn't block your branch. The problem is that after applying this patch, I see larger files mis-highlighted when I open them and jump to somewhere in the middle of the buffer (or when the point is placed there automatically on openening, because that was my last editing position). Basically, I guess some string boundary isn't recognized, and the highlighting string - code is reversed: code is highlighted as string, and vice versa. It can be fixed by moving point into a correctly highlighted region and calling `font-lock-fontify-buffer'. But with no change to the buffer other than that? Sounds like possibly a bug in Emacs, though I also vaguely recall that font-lock did or does have some maximum limit of buffer size on which it operated. I think this was put in at the time where then-modern machines really couldn't keep up with on-the-fly highlighting. BTW, while looking at this, something is still not quite right with the parsing of triple-quoted string literals... as can be witnessed when filling a TQS with embedded SQS... Can you provide an example? Try filling this string: The output conforms to the XHTML version 1.0 Transitional DTD (*almost* strict). The output contains a minimum of formatting information. The cascading style sheet html4css1.css is required for proper viewing with a modern graphical browser. It results in this: The output conforms to the XHTML version 1.0 Transitional DTD (*almost* strict). The outputcontains a minimum of formatting information. The cascading style sheet html4css1.css is required for proper viewing with a modern graphical browser. behaving as if the string stopped at the single double-quote before contains. Confirmed, and if you change those embedded double quotes to single quotes, the paragraph fills correctly. The font-locking *seems* to be all-right, however I've still seen an instance where the text between the single quotes has code-coloring -- cannot reproduce though. Me neither with r372. If I can figure out how to do it, I'll commit these changes separately to a private branch on launchpad, so that they can be reviewed. Two additional things would be nice if anyone's so inclined. * Adding a NEWS file; I don't care how far back into history it goes. * Maybe some nice screen grabs of face examples so folks have a visual way of seeing what their font-lock options are. I'll see what I can do. Thanks very much for adding the NEWS file! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNJfVrAAoJEBJutWOnSwa/rdEP/i+yMLtXrdvDLDDLJQj8lb2i ra0m5vPsRJ3lx++Y+vEQuiDSK47tg0LZOBprG9L4V+UbO/prQj9VvDYSxxQxKiF4 xbZXSPjzBeEc6SEXKlXceWt/GQTF/8D3481CwAihqsthfC+6qgrUSnfowzW/wJXj eNZUMHOOvBfHBwpWCYXGT0ZO0qMoJ4lbau+GOz/BBNnKYKO0K7+mDrywM6rheibz DLvSbYnUhFlwxQsNDkPDG33K5ZMb9+IOLj9bjBxYzEAP74eD2to1u7rGDKh7Nh+s gT5R30d81LjfYNlAbYx2X7cUwRxPdHeYMGFQtVyTZofgno+P1jYb+ML5QtR5Z2nI lIBFxSRcjEpOe7YOMld0srcRPt3NZkhF3IPU0TLtIic9gpf1fvjCFN/6nrQ1aczQ 10O23KB8gqIrJlX9V8oOnYeaM0n9VNpb/Bo+c4LPjHBe99N5/76HmwLCsa8/FwfT 4Gt06OfSxpLe5C7Ws7jpJH7eUG3ZRmsXy7/xcpPoXue8augVJCwHG+H8rHXYYQ2q cykYWbB6ZNQtKSEO8c7L/BiOx5nLXwbNJwPbTwJ88vtPo0DoIofM/FFNlGX7nVgk 4rXgCtox75NqS5fOzs01i4M9awaO4+Ml5pswhR9LaqXLCjA07exIpBdjsJwIgR3K 1AqOLi2PAnrtGoofO6VW =rdfN -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] Time for a new release?
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 signature.asc Description: PGP signature ___ 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 Mar 19, 2010, at 05:12 PM, Reinout van Rees wrote: On 03/19/2010 04:21 PM, Barry Warsaw wrote: Any objections to C-c C-e? None at all. That e-for-explain you mentioned sounds fine. Cool. Bug updated. -B signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] simple comment/string-tweak branch
On Mar 16, 2010, at 04:22 PM, Tom Roche wrote: Perhaps this will be useful. As I know little about your procedures, had never used bzr at all until yesterday, and had never done a bzr commit until 10 min ago, please let me know if anything needs done better/ correctly. I think you did it just about perfectly. I've reviewed and accepted the merge proposal. Maybe Andreas would like to merge and push it? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] simple comment/string-tweak branch
On Mar 18, 2010, at 04:19 PM, Deniz Dogan wrote: While we are already updating documentation, could someone change the instructions to use `add-to-list' instead of using `setq' in combination with `cons'? I'm not sure when `add-to-list' was added to Emacs/XEmacs, but I'm pretty sure it's ancient enough by now. Someone should also change the $ in the first regex to \\'. +1 if these work with current versions of Emacs and XEmacs. I no longer have the latter to test with. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] plan for emacs python tooling (esp python.el, python-mode.el)?
On Mar 16, 2010, at 07:37 AM, Eric M. Ludlam wrote: Exuberent ctags supports python (though I don't know by how much), and adding support in the CEDET/Semantic exuberant ctags support wouldn't be too hard. Likely something like the patch attached. exuberent-tags is a separate package on Ubuntu, and it supports Python well. Actually too well IMO. I don't like variable or import tags so something like --python-kinds=-vi [*] should work pretty well. -Barry [*] ironic, ain't it? :) signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] bazaar merge oddity
On Mar 18, 2010, at 09:50 AM, Andreas Roehler wrote: after a merge bazaar requires a local commit nonetheless. However, the difficulty and confusion IMHO arises from the commit-message, necessary that way also. As you may see in the current trunk now, your revision 353 is gone completely. It's place is taken by my patch, while your changing appears as rev 354 but with my commit message. Or made I some mistake? I don't think you made any mistake, I think it's just the way dvcs in general, and Bazaar in particular handles things. The fundamental problem of course is that revision numbers (e.g. 353) are by definition local and not stable. If I were to commit a change now, it would be r355 locally. If you did the same thing we'd both have r355 in our local repositories. The first one of us to push to the master branch would win and the second would have to first merge and then push, which I'm sure is what you did. Every revision also has a revision id, which is a globally unique, but not human friendly, id that will never change. % bzr log -c 354 --show-ids revno: 354 [merge] revision-id: andreas.roeh...@online.de-20100318083644-0msjrlaxvmv4mlvl parent: andreas.roeh...@online.de-20100123170127-dqmdxlkb156bncvb parent: ba...@python.org-20100119204450-7iekyt7gnxw2qhfn committer: Andreas Roehler andreas.roeh...@online.de branch nick: 328781-bod-lands-in-string timestamp: Thu 2010-03-18 09:36:44 +0100 message: revision/353 Fix some indentation merged Use --include-merges or -n0 to see merged revisions. You can see that the parent of your change is my indentation change: % bzr log -c ba...@python.org-20100119204450-7iekyt7gnxw2qhfn revno: 352.1.1 committer: Barry Warsaw ba...@python.org branch nick: python-mode timestamp: Tue 2010-01-19 15:44:50 -0500 message: Fix some indentation. and the revno gets a dotted path, which is unique to the master branch (and once you've reconciled/merged it to your local branch, yours as well). This shows the parenting relationship between the revisions. Normally, this is hidden because it's mostly uninteresting, but it does make things confusing in cases like this. Suffice to say that Bazaar makes it pretty difficult for you to do anything destructive like lose a revision. IOW, you did the right thing! -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] plan for emacs python tooling (esp python.el, python-mode.el)?
The plan is to ship it with python.el until we can ship it with python-mode.el (the barrier being coipyright assignments). Although I believe I've already done so, I've repeatedly said that I have no problem assigning my changes in python-mode.el to the FSF (again). I think we can get Skip, Ken, and Tim to do the same, though I also think some or all of them have already done so. I really don't know what more I can do about the copyright assignment problem. That having been said, python-mode.el is GPL and I nothing against y'all stealing as much from python.el as makes sense. If python-mode.el is never distributed with Emacs, so be it. But there really shouldn't be anything stopping python-mode.el from having the best of both worlds. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] form inserting print
On Mar 12, 2010, at 11:21 AM, Georg Brandl wrote: Wouldn't that be the job of one of the numerous snippet packages that are floating around? I'm using yasnippet myself, and it works very well. (I know that python.el has some definitions for skeleton mode, but python-mode.el doesn't, and I'm not sure it should.) I'm not sure either. python-mode.el does contain some hooks for imenu so there's some precedence. I guess if we're going to support such functionality, it should be via standard available hooks. I don't use stuff like that much though, so I don't have a strong opinion either way. -Barry signature.asc Description: PGP signature ___ 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 18, 2010, at 06:27 PM, m h wrote: I'm using pdb (from gud.el) with emacs, which is working pretty good. I've got two gripes. * After I run pdb on a testfile, the point goes to the top of the buffer * I'd like to be able to click on files in the stacktrace (on unittest failures) and have emacs open the buffer to the correct line I figure if I can fix the later 80% of the other issues are covered. Any pointers or tips are greatly appreciated. I've searched gud.el for alist and find-file, but alas my elisp is not quite up to snuff to tell if this is actually supported. I'm afraid I can't help much. I generally use pdb-track instead of gud, and haven't really noticed any problems. -Barry signature.asc Description: PGP signature ___ 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 19, 2010, at 12:18 PM, m h wrote: Wow, didn't you add python support to gud? If I did, it was a million years ago and I don't remember it ;). Would you (or anyone else) care to mention their workflow? I've just been trying to get python-mode C-c C-c to allow me to use pdb. But I get an error: stdin(181)_test() (Pdb) Traceback (most recent call last): File stdin, line 186, in module File stdin, line 181, in _test File stdin, line 181, in _test File /usr/lib64/python2.6/bdb.py, line 46, in trace_dispatch return self.dispatch_line(frame) File /usr/lib64/python2.6/bdb.py, line 65, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit 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. I owe Ken Manheimer a lifetime supply of [insert beverage] for this beautiful hack. -Barry signature.asc Description: PGP signature ___ 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 19, 2010, at 06:12 PM, Jeff Bauer wrote: clickable? Is that like using that mouse thing? To paraphrase a wise man, There's no clicking in Emacs! :) But the track ball scroll wheel is AWESOME. Hi Jeff! Yes, I completely agree. :) -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Problem with Multi-Line Comments
On Dec 11, 2009, at 1:13 PM, Andreas Roehler wrote: Already tried to tackle the issue. Works with GNU Emacs for me, not with XEmacs until now. Introduced some stuff from python.el - defconst python-font-lock-syntactic-keywords etc. Patch attached - not polished yet, but works here some weeks now. Why not push a branch to Launchpad so we can more easily play with it and diff it against trunk? :) -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Bug 450552] [NEW] python-mode breaks for python 3
On Oct 17, 2009, at 11:54 AM, Andreas Roehler wrote: (defcustom py-adressed-python-version *With different Python versions, changes have been made, which affect python execution as editing likewise. If a version is specified here, python-mode will adapt its proceeding to it. Otherwise python-mode will try some guess from the installed system. You may switch the addressed python-version with M-x py-switch- addressed-version during your emacs-session. :type 'string :group 'python) Any hints, objections, ideas? I'd definitely love to see some enhancements to python-mode to deal with Python 3, but of course I have no time for that myself. ;) I'd suggest two variables: (defvar py-python-major-version ...) This would be a buffer-local variable, defaulting to 2, specifying the Python major version of the code in the current buffer. (defcustom py-guess-python-version ...) This would be a global customizable variable specifying whether to apply heuristics to guess the py-python-major-version when a buffer is visited. It should probably default to t. +1 for working on this! -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] beginning-of-defun-function.patch
On Sep 14, 2009, at 2:22 AM, Andreas Roehler wrote: Not this time. :) Sorry. Note to self: first sleep, /then/ reply. -B PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] beginning-of-defun-function.patch
On Sep 13, 2009, at 6:29 AM, Andreas Roehler wrote: as mentioned, several modes like C++ or python-mode need a more sophisticated determination of beginning- or end-of-defun than a regexp may provide. A additional function-call will be possible with patch attached. It allows use of `M-x end-of-defun' in python-mode for example. Should no one object, I'll try to check it in into the mercurial repo. I think you meant the Bazaar repo? :) Can you do a proper branch and merge proposal for this change? Please create a bug too. It just helps us track things much better. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] triple-quoted-string bug fixed
On Sep 10, 2009, at 7:54 AM, Andreas Roehler wrote: Hi Barry, diff attached against latest python-mode.el solves bug 328790, the triple string bug for me - checked with X- and GNU Emacs. Took some stuff from python.el, thanks towards its excellent author BTW. Did create a branch for it. Log now reads revno: 352 committer: Andreas Roehler andreas.roeh...@online.de branch nick: python-mode timestamp: Thu 2009-09-10 13:30:24 +0200 message: --fixes=lp:328790 Should I try bzr push lp:~a-roehler/python-mode/triple-quoted-string-bug-328790.el Hi Andreas, thanks for the patch! If you're up for it, I'd love to use Launchpad's merge proposals to handle this. * push the branch to launchpad * link the branch to the bug [1] * submit a merge proposal for the branch [1] You can do this from bzr with: bzr commit --fixes=lp:328790 though you might need to include --unchanged if all your changes are already committed. If you do use --fixes, do this before you push. After a short delay, LP will automatically link your branch to the bug. Let me know if you have any questions. You can assign the merge proposal to me and I will get an email notification. We'll handle it from there. Thanks! -Barry PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] triple-quoted-string bug fixed (3)
On Sep 11, 2009, at 3:55 PM, Andreas Roehler wrote: as it turns out, assumed fix was wrong as far it concerns XEmacs. Change only works for GNU Emacs. Will see. Cool, thanks. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] looking for a discussion of things python(-mode) ish
On Sep 9, 2009, at 5:56 AM, Andreas Roehler wrote: checking for the triple-quoted-bug: with python.el, (nth 8 (syntax-ppss)) shows the correct result. Unfortunately with python-mode.el (nth 8 (syntax-ppss)) fails. From there I assume, setting the syntax-table properly might solve the bug I haven't looked at this stuff in ages. Has the syntax table grown more support for the kind of things Python's triple quoted strings needs? -Barry PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] What text editor is everyone using for Python
On May 28, 2009, at 7:09 AM, Andreas Roehler wrote: python-mode.el was its bloody-minded determination to regard '_' as a word character, something which caused me more typing that it ever saved. Its just one line to comment in python-mode.el, like this: ;; (modify-syntax-entry ?\_ w py-mode-syntax-table) This one is ancient and I remember that Guido and I talked about this for a long time before settling on the behavior. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
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. 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. :) -Barryu PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] pdbtrack
On Apr 30, 2009, at 4:07 PM, Andreas Roehler wrote: I'll send you two screenshots offlist. Please feel free to forward them to interested persons, just didn't want to publish my path at the list. 20090428_pdbtrack3.png displays pdbtrack opened second windows, cursor displayed at line 4 import With 20090428_pdbtrack4.png you see shell-output from line 8, but cursor in second window still is at line 4. Always get Traceback cue not found Cause seems var `py-pdbtrack-stack-entry-regexp'. That doesn't happen, if pdb.set_trace() is inside the python-file. Did someone else remark this? Hi Andreas, I haven't heard this one before, but perhaps it's because of the ipython prompt? I think pdbtrack expects (by default) the standard (pdb) prompt. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] pdbtrack
On May 1, 2009, at 4:50 PM, Andreas Roehler wrote: Hhm. Could you give me an example, how you run script activating pdbtrace, reaching the standard (pdb) prompt from Emacs? I almost always just add the following line to the source code at the point I want to start debugging: import pdb; pdb.set_trace() Then I fire up my application from the shell. When that line gets it, Python breaks and pdbtrack starts up. It's worked pretty much that way for me since forever. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
