From noreply at sourceforge.net Sat Jun 4 21:58:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 12:58:01 -0700 Subject: [Python-mode] [ python-mode-Patches-1077902 ] Show upper methods and classes Message-ID: Patches item #1077902, was opened at 2004-12-02 14:57 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1077902&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Later Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: Show upper methods and classes Initial Comment: Hi, this patch shows the upper methods and classes and binds this to C-c C-x Example: class Foo: def blu(): def subblu(): print "foo" if you press C-c C-x in the last line you see Foo/blu/subblu/ This is handy if you query-replace in a long method and you want to be sure that you are still in this method and not in the next Tested with XEmacs 21.4 and Emacs 21.3.1 I tried to bind this into the mode-line, but failed. This would be better since you could see all the time in which methods and classes the cursor is. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 14:58 Message: Logged In: YES user_id=44345 I'm going to go with func-menu for now. Its nested function display isn't perfect, but I suspect it can be fixed, and if so, would probably help a broader community than just folks using Python. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-12-21 06:45 Message: Logged In: YES user_id=11105 FYI: func-menu (included with XEmacs) does something similar, and also works for other languages. It also displays the function or class/method the cursor is in in the mode-line. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-08 09:22 Message: Logged In: YES user_id=44345 I'm working on this. I noticed a number of changes of "iff" to "if". Just checking to make sure you're aware that in English "iff" is a shorthand for "if and only if". If you were just correcting spelling, I'll reword those comments to not rely on idiomatic English. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1077902&group_id=86916 From noreply at sourceforge.net Sat Jun 4 22:25:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 13:25:01 -0700 Subject: [Python-mode] [ python-mode-Patches-875046 ] py-tab-always-indent implementation Message-ID: Patches item #875046, was opened at 2004-01-11 14:29 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=875046&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gary Feldman (garyfx) >Assigned to: Skip Montanaro (montanaro) Summary: py-tab-always-indent implementation Initial Comment: This patch address the issue I raised in http://groups.google.com/groups?hl=en&threadm=mrb2rvk73vu4jfebaelglq257n2p7q5gaf%404ax.com , specifically to provide behavior similar to the C mode c-tab-always-indent, because the previous implementation had no way of setting the tab key to insert tabs in the body of a """ string while keeping the automatic indentation behavior at the beginning of the line. I've attached a diff file for the differences against 4.49, but for ease of reading, and because the patch is so small, here are the changes: (defcustom py-tab-always-indent t "*Non-nil means TAB in Python mode should always reindent the current line, regardless of where in the line point is when the TAB command is used." :type 'boolean :group 'python) (defun py-indent-line (&optional arg) "Fix the indentation of the current line according to Python rules. With \[universal-argument] (programmatically, the optional argument ARG non-nil), ignore dedenting rules for block closing statements (e.g. return, raise, break, continue, pass) This function is normally bound to `indent-line-function' so \[indent-for-tab-command] will call it." (interactive "P") (let* ((ci (current-indentation)) (move-to-indentation-p (<= (current-column) ci)) (need (py-compute-indentation (not arg)))) ;; see if we need to dedent (if (py-outdent-p) (setq need (- need py-indent-offset))) (if (or py-tab-always-indent move-to-indentation-p) (progn (if (/= ci need) (save-excursion (beginning-of-line) (delete-horizontal-space) (indent-to need))) (if move-to-indentation-p (back-to-indentation))) (insert-tab)))) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 15:25 Message: Logged In: YES user_id=44345 Added to python-mode.el 4.72. Thanks for the patch. Sorry for the delay getting to it. Is "delay" the right word when the time interval is nearly 18 months? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=875046&group_id=86916 From noreply at sourceforge.net Sat Jun 4 22:27:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 13:27:13 -0700 Subject: [Python-mode] [ python-mode-Patches-875596 ] various fixes Message-ID: Patches item #875596, was opened at 2004-01-12 13:26 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=875596&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: various fixes Initial Comment: [forwarded from http://bugs.debian.org/226337] Dave Love writes: I made a load of changes to python-mode.el and realized that several of them fix (at least in Emacs 21) old Debian bugs: 160130, 209723, 164423, 164424 and 159628. Here's what I sent to python-mode in case it's useful. This patch against recent CVS fixes/adds a bunch of things, including: * Runtime use of cl, per Emacs rules -- actually, avoid it completely; * Proper syntactic fontification in Emacs 21; * Non-ASCII identifiers in Emacs 21; * Missing cases for Emacs; * Menu lossage in transient-mark-mode; * Char tables not defined in the approved way (so you can M-C-x them); * Hooks not local that need to be; * Hooks not removed when unloading; * Losing use of `py-shell-alist'; * Compilation warnings. This is mostly for Emacs 21, but as far as I can tell, it hasn't broken anything in XEmacs. Note that the licence is inconsistent with the use of GPL'ed code in bits copied from elsewhere. 2003-12-01 Dave Love * python-mode.el: Doc fixes. (custom, cl, compile): Don't require. (compile-internal): Autoload. (comint-last-input-end): Defvar when compiling. (py-char-classes-p): New. (python-font-lock-keywords, py-defun-start-re, py-class-start-re) (py-pdbtrack-stack-entry-regexp, py-imenu-class-regexp) (py-imenu-method-regexp, py-forward-into-nomenclature): Use it. (py-quote-syntax, py-font-lock-syntactic-keywords) (py-mark-active, py-outline-level, python-mode-unload-hook): New. (py-keep-region-active, py-electric-delete): Avoid compilation warning in Emacs. (py-highlight-line, py-mouseto-exception): Add Emacs case. (py-in-literal): Define separate cases for Emacs and XEmacs, and avoid warning. Simplify Emacs case. (py-fast-in-literal): Deleted. (py-which-shell, py-which-args, py-which-bufname): Move before use. (python-mode): Set parse-sexp-lookup-properties, outline-regexp, outline-level, open-paren-in-column-0-is-defun-start. Modify font-lock-defaults value. (py-pdbtrack-track-stack-file): Bind target_buffer. (py-pdbtrack-grub-for-buffer): Bind buf, not curbuf. (py-output-buffer): defvar, not defconst. (py-help-at-point): Avoid `search'. (py-temp-directory): Maybe use temporary-file-directory. (py-menu, py-shift-region-left, py-shift-region-right): Fix use of `(mark)'. (py-beginning-of-def-or-class): Re-run if it lands in a string. (py-goto-beginning-of-tqs): Don't lose if delim is t. (py-shell-alist): Don't quote cdrs. (py-mode-map, py-shell-map, py-mode-output-map) (py-mode-syntax-table, py-dotted-expression-syntax-table): Define inside defvar. (py-imenu-create-index-engine): Avoid `first', `second'. (py-choose-shell-by-shebang): Use py-shell-alist correctly. (py-shell): Only add to comint-output-filter-functions locally. Set indent-line-function. (py-execute-region): Fix choosing shell. (py-mark-block): Activate mark. (py-python-version): New. Use it with info-lookup-maybe-add-help. (debug-ignored-errors): Add errors used here. (py-shell-map): Don't bind tab. (py-pychecker-run): Use read-shell-command conditionally. (py-mode-output-map): Maybe bind mouse-2. Use suppress-keymap. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 15:27 Message: Logged In: YES user_id=44345 Closing. It's old (out-of-date) and contains GPL'd code which (as I understand it) would make it impossible to release with the Python distribution. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-01-28 10:27 Message: Logged In: YES user_id=44345 What version of python-mode.el was this patch made against? Applying it with patch fails pretty miserably. The reject file is 490 lines and it looks like it will be almost impossible for me to sort out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=875596&group_id=86916 From noreply at sourceforge.net Sat Jun 4 22:28:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 13:28:24 -0700 Subject: [Python-mode] [ python-mode-Patches-1021881 ] Include the name of a module's package in its buffer name. Message-ID: Patches item #1021881, was opened at 2004-09-03 10:18 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1021881&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: Include the name of a module's package in its buffer name. Initial Comment: Add an option to include a module's package name in its buffer name. E.g. if module `module.py' is contained in a package whose dotted name is `a.b.c', then its buffer will be named "module.py (a.b.c)" instead of just "module.py". When using complex package hierarchies, this can be useful for keeping track of where a module is in the hierarchy. It's especially useful for keeping track of __init__.py files. In the patch, the option is turned on by default; but that could be changed. See the docs for the custom variable py-name-buffers-with-packages. For more info about file-name-handler-alist (which is used to implement the change), see ("Making Certain File Names 'Magic'"). It should work under both emacs and xemacs. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 15:28 Message: Logged In: YES user_id=44345 Closing. Seems like func-menu (standard with XEmacs, probably with GNU Emacs as well) does something similar. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-01-09 12:04 Message: Logged In: YES user_id=44345 I backed this change out. With it in place it seems that buffer names are annotated with "<2>" even if they are the only buffer associated with a given file name. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-10-23 12:37 Message: Logged In: YES user_id=44345 Looks good. Checked in as v 4.65. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-09-12 16:26 Message: Logged In: YES user_id=195958 Fixed a bug in the patch where the rename would fail if two buffers with the same name were opened. (Also, used context diff instead of unified diff.) ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-09-06 21:20 Message: Logged In: YES user_id=195958 Attatching file, take 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1021881&group_id=86916 From noreply at sourceforge.net Sat Jun 4 22:46:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 13:46:28 -0700 Subject: [Python-mode] [ python-mode-Patches-1023335 ] Handle triple-quoted strings correctly. Message-ID: Patches item #1023335, was opened at 2004-09-06 17:22 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1023335&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) >Assigned to: Edward Loper (edloper) Summary: Handle triple-quoted strings correctly. Initial Comment: This patch adds an option that will color triple-quoted strings correctly. It works by turning off syntax-highlighting for strings and comments (by registering quotes and hashes in the syntax table as normal punctuation); and using a fairly advanced keyword matcher to find all strings and comments. The keyword matcher uses a text- property to keep track of the syntax category of each character, and only updates it as needed. Therefore, the option can only be used if text-properties are available (but they are available on all current versions of emacs, as far as I know). Caveat: it's possible that this will be slow on some machines, or under certian circumstances. But it's not noticably slower on the machines & files I've tested it on. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 15:46 Message: Logged In: YES user_id=44345 Ed, this looks like this would be a good addition, but there are some problems. Is there any resolution to Johannes' note about comment breakage? I just patched my copy of python-mode.el. When I visit a .py file it complains that it can't find the text-properties package. (This is XEmacs 21.4.15.) I didn't see anything like text-properties or properties in the package list. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-01 10:15 Message: Logged In: YES user_id=469548 I applied this patch to the latest python-mode and while triple-quoted-strings mostly work fine (thank you! thank you! thank you!), comments seem to be a bit broken. Take a look at BaseHTTPServer.py from the Python CVS for a particularly bad example. I'm running "GNU Emacs 21.3.50.1 (i386-pc-linux-gnu, GTK+ Version 2.4.10) of 2004-10-11 on surfboy, modified by Debian", compiled from Emacs CVS using the emacs-snapshot package. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-09-06 21:15 Message: Logged In: YES user_id=195958 So I did. Trying again. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-09-06 20:41 Message: Logged In: YES user_id=44345 Edward, perhaps you forgot to check the box when uploading the patch? There's nothing currently attached to this item. -Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1023335&group_id=86916 From noreply at sourceforge.net Sat Jun 4 23:01:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 14:01:05 -0700 Subject: [Python-mode] [ python-mode-Patches-1064058 ] Two minor tweaks to python-mode Message-ID: Patches item #1064058, was opened at 2004-11-10 13:12 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1064058&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Rory Yorke (ryorke) Assigned to: Nobody/Anonymous (nobody) Summary: Two minor tweaks to python-mode Initial Comment: python-mode has two slightly annoying behaviours, which this patch attempts to address: 1) py-shell always changes mode-name of buffer This happens because py-toggle-shells changes mode-name regardless of what it was before (e.g., invoke py-shell from a Elisp-mode buffer, mode-name becomes Python). 2) py-shell always switches to a new window This happens even if py-shell is invoked when the *Python* buffer is the active buffer; one then ends up with two windows showing the *Python* buffer. The patch is against python-mode.el revision 4.67. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 16:01 Message: Logged In: YES user_id=44345 Rory, I applied part one of your patch as v 4.73. At first I thought I couldn't reproduce the part two problem. Then I read what you wrote properly and discovered it was still a problem. That went into v 4.74. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1064058&group_id=86916 From noreply at sourceforge.net Sun Jun 5 00:11:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 15:11:02 -0700 Subject: [Python-mode] [ python-mode-Patches-1194875 ] better (and more) coloring Message-ID: Patches item #1194875, was opened at 2005-05-03 19:44 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas K?lker (jonaskoelker) Assigned to: Nobody/Anonymous (nobody) Summary: better (and more) coloring Initial Comment: this patch fixes some coloring problems. It's made against 4.70 (I diffed the CVS version against my debian/sarge python-mode.el: equal) --- fixed stuff try:pass colors everything except the : (same for except and finally) they still color the colon turquoise if there's at least one space or newline. If colon-coloring should be turned off, it's a simple swap-three-lines operation. it also correctly colors str(id(type(len))); but only (damn!) because it alternates between typenames and builtins. fixes not coloring the last exception in a tuple (and probably other similar things). (imo) correctly colors ValueError in `exceptions.ValueError'. adds set and frozenset to typenames. --- tweakable stuff: selecting alternate face for typenames (int, dict, type) selecting alternate face for builtins (exceptions, len, id) (these two defaults to kw-turquoise) selecting alternate face for numeric literals (but currently the RE-matching is dodgy) selecting alternate face for the first variable name in a for ... in (both expressions and statements) (it should be extended to more than just the first). (these two default to a vanilla face, 'py-plain-face) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 17:11 Message: Logged In: YES user_id=44345 Thanks... I applied the patch locally and will play around with it a bit. Attached is a slightly tweaked diff. There were a couple rejects because of other recent changes with the keyword re's. Can you give it a whirl? Any chance you can fix the FIXMEs? I don't see any coloring for numeric literals. Should I? I suspect that will be something a lot of people won't want, so there should be a way to disable it, and that should probably be the default. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-05-03 19:46 Message: Logged In: YES user_id=1153395 sorry, I (something)ed up uploading the patch. Scene 24, take 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 From noreply at sourceforge.net Sun Jun 5 05:16:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 20:16:02 -0700 Subject: [Python-mode] [ python-mode-Bugs-1215039 ] eat 100% CPU when "Force full reparse" Message-ID: Bugs item #1215039, was opened at 2005-06-05 11:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shixin Zeng (pupilzeng) Assigned to: Nobody/Anonymous (nobody) Summary: eat 100% CPU when "Force full reparse" Initial Comment: it seems to come into a infinite loop, and I can't do anything but Ctrl+C to end emacs and all my datas were lost. It ocurred every time I type M-/ for code completion. my emacs is 23.0.0.1, checkout from the branch unicode-2 on April, 2, 2005 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 From noreply at sourceforge.net Sun Jun 5 13:10:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 04:10:33 -0700 Subject: [Python-mode] [ python-mode-Bugs-1215039 ] eat 100% CPU when "Force full reparse" Message-ID: Bugs item #1215039, was opened at 2005-06-04 22:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shixin Zeng (pupilzeng) Assigned to: Nobody/Anonymous (nobody) Summary: eat 100% CPU when "Force full reparse" Initial Comment: it seems to come into a infinite loop, and I can't do anything but Ctrl+C to end emacs and all my datas were lost. It ocurred every time I type M-/ for code completion. my emacs is 23.0.0.1, checkout from the branch unicode-2 on April, 2, 2005 ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 06:10 Message: Logged In: YES user_id=44345 What version of python-mode.el are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 From noreply at sourceforge.net Tue Jun 7 05:14:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Jun 2005 20:14:21 -0700 Subject: [Python-mode] [ python-mode-Patches-783254 ] python-mode patch for ipython support Message-ID: Patches item #783254, was opened at 2003-08-04 22:26 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783254&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: python-mode patch for ipython support Initial Comment: migrating #575774 from the python project. Original submission: This patch makes the prompt and traceback recognition mechanisms a bit more flexible to allow easy adaptation for ipython (in lieu of the normal python shell). The seperate file ipython.el (which I assume will end up in the ipython distribution) then enables py-execute-region, py-up-exception etc. to work just as well for ipython (which means ipython works just as well under python mode as the standard python shell). I also added something to ipython.el to convert ipython session bits to something that looks like normal interactive session bits. This, together with ipython's ability to directly execute such strings (by auto-removing leading '>>>'s) should make for very convinient doctest development (I had orginally planned to patch python-mode to incorporate such functionality because I found the manual reediting a bit tiresome). Slightly off-topic, I also have a feature request: executing a whole file ends up creating a temporary file which is instead executed. I think it would be much nicer if the actual file itself where executed with execfile, because otherwise pdb ends up pointing to the "wrong" (i.e. the temporary) buffer. It is really easy to forget about this and edit this temporary file during a debugging session and as a consequence inadvertenly loose changes. This situation crops up quite often, if one uses ipython's really nifty feature to toggle pdb activation on exceptions (or hacks up something equivalent for python), which is an extremely efficient way to quickly debug and test one's program. I would have added a patch, but some restructuring seemed necessary, and it wasn't immediately clear to me in which way this should be done. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-06 22:14 Message: Logged In: YES user_id=44345 Last of the parts of this were added in 4.75. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783254&group_id=86916 From noreply at sourceforge.net Tue Jun 7 05:19:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Jun 2005 20:19:49 -0700 Subject: [Python-mode] [ python-mode-Bugs-1215039 ] eat 100% CPU when "Force full reparse" Message-ID: Bugs item #1215039, was opened at 2005-06-04 22:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shixin Zeng (pupilzeng) >Assigned to: Skip Montanaro (montanaro) Summary: eat 100% CPU when "Force full reparse" Initial Comment: it seems to come into a infinite loop, and I can't do anything but Ctrl+C to end emacs and all my datas were lost. It ocurred every time I type M-/ for code completion. my emacs is 23.0.0.1, checkout from the branch unicode-2 on April, 2, 2005 ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-06 22:19 Message: Logged In: YES user_id=44345 Can you provide an example Python file where this happens? Given that M-/ runs dabbrev-expand, I'm skeptical this has anything to do with python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 06:10 Message: Logged In: YES user_id=44345 What version of python-mode.el are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 From noreply at sourceforge.net Tue Jun 7 05:24:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Jun 2005 20:24:24 -0700 Subject: [Python-mode] [ python-mode-Bugs-1172347 ] indentation tricked by parenthesis inside strings Message-ID: Bugs item #1172347, was opened at 2005-03-29 00:59 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1172347&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alejandro Dubrovsky (alito) Assigned to: Nobody/Anonymous (nobody) Summary: indentation tricked by parenthesis inside strings Initial Comment: r = t.find("(") next line will indent to the "still open" parenthesis from that line (related to #834290 ?) (cvs as of 29/03/05) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-06 22:24 Message: Logged In: YES user_id=44345 I can't reproduce this with v 4.75. Can you attach a complete .py file to this I can try it with? What version of Emacs are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1172347&group_id=86916 From noreply at sourceforge.net Tue Jun 7 22:59:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 13:59:51 -0700 Subject: [Python-mode] [ python-mode-Patches-1194875 ] better (and more) coloring Message-ID: Patches item #1194875, was opened at 2005-05-04 02:44 Message generated for change (Comment added) made by jonaskoelker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas K?lker (jonaskoelker) Assigned to: Nobody/Anonymous (nobody) Summary: better (and more) coloring Initial Comment: this patch fixes some coloring problems. It's made against 4.70 (I diffed the CVS version against my debian/sarge python-mode.el: equal) --- fixed stuff try:pass colors everything except the : (same for except and finally) they still color the colon turquoise if there's at least one space or newline. If colon-coloring should be turned off, it's a simple swap-three-lines operation. it also correctly colors str(id(type(len))); but only (damn!) because it alternates between typenames and builtins. fixes not coloring the last exception in a tuple (and probably other similar things). (imo) correctly colors ValueError in `exceptions.ValueError'. adds set and frozenset to typenames. --- tweakable stuff: selecting alternate face for typenames (int, dict, type) selecting alternate face for builtins (exceptions, len, id) (these two defaults to kw-turquoise) selecting alternate face for numeric literals (but currently the RE-matching is dodgy) selecting alternate face for the first variable name in a for ... in (both expressions and statements) (it should be extended to more than just the first). (these two default to a vanilla face, 'py-plain-face) ---------------------------------------------------------------------- >Comment By: Jonas K?lker (jonaskoelker) Date: 2005-06-07 22:59 Message: Logged In: YES user_id=1153395 > There were a couple rejects because of other recent changes with the keyword re's. Can you give it a whirl? Sure. > I don't see any coloring for numeric literals. Should I? Most likely: no. That is, it won't be colored unless you set the variable 'py-number-literal-face to something interesting. I attach $(head .emacs) > I suspect that will be something a lot of people won't want, so there should be a way to disable it, and that should probably be the default. See above: it is the default. > Any chance you can fix the FIXMEs? I'll try. I'll also work or improving the interface to the 'py-whatever-face variables (i.e. put them *above* the "NO USER DEFINABLE VARIABLES BEYOND THIS POINT") ...Sorry for not replying sooner--I had an exam going on. Next one is 20th june, after which I'll more or less be away from my box 'till mid-july :( But until then, I have about n spare hours a day, of which I can devote m (where m <= n) to hacking on python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 00:11 Message: Logged In: YES user_id=44345 Thanks... I applied the patch locally and will play around with it a bit. Attached is a slightly tweaked diff. There were a couple rejects because of other recent changes with the keyword re's. Can you give it a whirl? Any chance you can fix the FIXMEs? I don't see any coloring for numeric literals. Should I? I suspect that will be something a lot of people won't want, so there should be a way to disable it, and that should probably be the default. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-05-04 02:46 Message: Logged In: YES user_id=1153395 sorry, I (something)ed up uploading the patch. Scene 24, take 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 From skip at pobox.com Wed Jun 8 04:04:44 2005 From: skip at pobox.com (Skip Montanaro) Date: Tue, 7 Jun 2005 21:04:44 -0500 Subject: [Python-mode] Can we trim the number of trackers? Message-ID: <17062.21052.485636.955940@montanaro.dyndns.org> Does anyone know if we can delete some of the trackers on the python-mode project? I'm used to checking bugs and patches, and can live with RFE, but can we zap Tracker (what's that for?) and Support? I'd much prefer people to send email to this list when they need help. Skip From barry at python.org Wed Jun 8 05:37:20 2005 From: barry at python.org (Barry Warsaw) Date: Tue, 07 Jun 2005 23:37:20 -0400 Subject: [Python-mode] Can we trim the number of trackers? In-Reply-To: <17062.21052.485636.955940@montanaro.dyndns.org> References: <17062.21052.485636.955940@montanaro.dyndns.org> Message-ID: <1118201840.10250.3.camel@geddy.wooz.org> On Tue, 2005-06-07 at 22:04, Skip Montanaro wrote: > Does anyone know if we can delete some of the trackers on the python-mode > project? I'm used to checking bugs and patches, and can live with RFE, but > can we zap Tracker (what's that for?) and Support? I'd much prefer people > to send email to this list when they need help. Well, I think I hid the Support tracker (at least from non-admins), but I don't see any way to hide that Tracker link. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/python-mode/attachments/20050607/2de32323/attachment.pgp From noreply at sourceforge.net Wed Jun 8 09:00:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 00:00:34 -0700 Subject: [Python-mode] [ python-mode-Bugs-1172347 ] indentation tricked by parenthesis inside strings Message-ID: Bugs item #1172347, was opened at 2005-03-29 06:59 Message generated for change (Comment added) made by alito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1172347&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Alejandro Dubrovsky (alito) Assigned to: Nobody/Anonymous (nobody) Summary: indentation tricked by parenthesis inside strings Initial Comment: r = t.find("(") next line will indent to the "still open" parenthesis from that line (related to #834290 ?) (cvs as of 29/03/05) ---------------------------------------------------------------------- >Comment By: Alejandro Dubrovsky (alito) Date: 2005-06-08 07:00 Message: Logged In: YES user_id=12623 You are right. Can't reproduce anymore on latest cvs. Thanks ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-07 03:24 Message: Logged In: YES user_id=44345 I can't reproduce this with v 4.75. Can you attach a complete .py file to this I can try it with? What version of Emacs are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1172347&group_id=86916 From noreply at sourceforge.net Wed Jun 8 15:57:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 06:57:52 -0700 Subject: [Python-mode] [ python-mode-Bugs-1172347 ] indentation tricked by parenthesis inside strings Message-ID: Bugs item #1172347, was opened at 2005-03-29 00:59 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1172347&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alejandro Dubrovsky (alito) Assigned to: Nobody/Anonymous (nobody) Summary: indentation tricked by parenthesis inside strings Initial Comment: r = t.find("(") next line will indent to the "still open" parenthesis from that line (related to #834290 ?) (cvs as of 29/03/05) ---------------------------------------------------------------------- Comment By: Alejandro Dubrovsky (alito) Date: 2005-06-08 02:00 Message: Logged In: YES user_id=12623 You are right. Can't reproduce anymore on latest cvs. Thanks ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-06 22:24 Message: Logged In: YES user_id=44345 I can't reproduce this with v 4.75. Can you attach a complete .py file to this I can try it with? What version of Emacs are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1172347&group_id=86916 From skip at pobox.com Thu Jun 9 02:18:36 2005 From: skip at pobox.com (Skip Montanaro) Date: Wed, 8 Jun 2005 19:18:36 -0500 Subject: [Python-mode] Can we trim the number of trackers? In-Reply-To: <1118201840.10250.3.camel@geddy.wooz.org> References: <17062.21052.485636.955940@montanaro.dyndns.org> <1118201840.10250.3.camel@geddy.wooz.org> Message-ID: <17063.35548.607226.581803@montanaro.dyndns.org> >> Does anyone know if we can delete some of the trackers on the >> python-mode project? Barry> Well, I think I hid the Support tracker (at least from Barry> non-admins), but I don't see any way to hide that Tracker link. Thanks, Barry. That will make it a bit easier to keep an eye on posts to those trackers. I will see if I can get notified of all tracker submissions. That will save me having to visit SF periodically. Skip From noreply at sourceforge.net Thu Jun 9 11:44:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 02:44:17 -0700 Subject: [Python-mode] [ python-mode-Bugs-1215039 ] eat 100% CPU when "Force full reparse" Message-ID: Bugs item #1215039, was opened at 2005-06-05 11:16 Message generated for change (Comment added) made by pupilzeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shixin Zeng (pupilzeng) Assigned to: Skip Montanaro (montanaro) Summary: eat 100% CPU when "Force full reparse" Initial Comment: it seems to come into a infinite loop, and I can't do anything but Ctrl+C to end emacs and all my datas were lost. It ocurred every time I type M-/ for code completion. my emacs is 23.0.0.1, checkout from the branch unicode-2 on April, 2, 2005 ---------------------------------------------------------------------- >Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 17:44 Message: Logged In: YES user_id=1143754 OK, here's an example: #!/usr/bin/python class A: def __init__(self, name): self.name = name if __name__ == '__main__': a = A('abc') a.<------------- M-/ here, the bug can be reproduced the python-mode is 1.0alpha ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-07 11:19 Message: Logged In: YES user_id=44345 Can you provide an example Python file where this happens? Given that M-/ runs dabbrev-expand, I'm skeptical this has anything to do with python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 19:10 Message: Logged In: YES user_id=44345 What version of python-mode.el are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 From noreply at sourceforge.net Thu Jun 9 12:33:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 03:33:09 -0700 Subject: [Python-mode] [ python-mode-Bugs-1215039 ] eat 100% CPU when "Force full reparse" Message-ID: Bugs item #1215039, was opened at 2005-06-05 11:16 Message generated for change (Comment added) made by pupilzeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shixin Zeng (pupilzeng) Assigned to: Skip Montanaro (montanaro) Summary: eat 100% CPU when "Force full reparse" Initial Comment: it seems to come into a infinite loop, and I can't do anything but Ctrl+C to end emacs and all my datas were lost. It ocurred every time I type M-/ for code completion. my emacs is 23.0.0.1, checkout from the branch unicode-2 on April, 2, 2005 ---------------------------------------------------------------------- >Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 18:33 Message: Logged In: YES user_id=1143754 When I'm editing C source files in cc-mode, the problem doesn't occur ---------------------------------------------------------------------- Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 17:44 Message: Logged In: YES user_id=1143754 OK, here's an example: #!/usr/bin/python class A: def __init__(self, name): self.name = name if __name__ == '__main__': a = A('abc') a.<------------- M-/ here, the bug can be reproduced the python-mode is 1.0alpha ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-07 11:19 Message: Logged In: YES user_id=44345 Can you provide an example Python file where this happens? Given that M-/ runs dabbrev-expand, I'm skeptical this has anything to do with python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 19:10 Message: Logged In: YES user_id=44345 What version of python-mode.el are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 From noreply at sourceforge.net Thu Jun 9 13:04:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 04:04:44 -0700 Subject: [Python-mode] [ python-mode-Bugs-1215039 ] eat 100% CPU when "Force full reparse" Message-ID: Bugs item #1215039, was opened at 2005-06-04 22:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shixin Zeng (pupilzeng) Assigned to: Skip Montanaro (montanaro) Summary: eat 100% CPU when "Force full reparse" Initial Comment: it seems to come into a infinite loop, and I can't do anything but Ctrl+C to end emacs and all my datas were lost. It ocurred every time I type M-/ for code completion. my emacs is 23.0.0.1, checkout from the branch unicode-2 on April, 2, 2005 ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-09 06:04 Message: Logged In: YES user_id=44345 Hmmm... It's been years and years since Python-mode 1.0alpha was released, so I suspect you're looking in the wrong place for the version. We are currently at 4.75. You can get the current python-mode version by typing M-: py-version RET When I hit M-/ at the place you indicated, it completes with "c12". I have no idea why it chooses that completion, but it doesn't hang. It's not obvious to me what it should expand in this context. Did you have something in mind? If I change the code to ... a = A('abc') a.foo = 12 a. when I hit M-/ it properly expands to "a.foo" for me. Please try upgrading your python-mode. ---------------------------------------------------------------------- Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 05:33 Message: Logged In: YES user_id=1143754 When I'm editing C source files in cc-mode, the problem doesn't occur ---------------------------------------------------------------------- Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 04:44 Message: Logged In: YES user_id=1143754 OK, here's an example: #!/usr/bin/python class A: def __init__(self, name): self.name = name if __name__ == '__main__': a = A('abc') a.<------------- M-/ here, the bug can be reproduced the python-mode is 1.0alpha ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-06 22:19 Message: Logged In: YES user_id=44345 Can you provide an example Python file where this happens? Given that M-/ runs dabbrev-expand, I'm skeptical this has anything to do with python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 06:10 Message: Logged In: YES user_id=44345 What version of python-mode.el are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 From noreply at sourceforge.net Thu Jun 9 13:39:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 04:39:39 -0700 Subject: [Python-mode] [ python-mode-Bugs-1215039 ] eat 100% CPU when "Force full reparse" Message-ID: Bugs item #1215039, was opened at 2005-06-05 11:16 Message generated for change (Comment added) made by pupilzeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shixin Zeng (pupilzeng) Assigned to: Skip Montanaro (montanaro) Summary: eat 100% CPU when "Force full reparse" Initial Comment: it seems to come into a infinite loop, and I can't do anything but Ctrl+C to end emacs and all my datas were lost. It ocurred every time I type M-/ for code completion. my emacs is 23.0.0.1, checkout from the branch unicode-2 on April, 2, 2005 ---------------------------------------------------------------------- >Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 19:39 Message: Logged In: YES user_id=1143754 M-: py-version RET "$Revision 4.63 $" I downloaded it from http://sourceforge.net/projects/python-mode, whose version was tagged as 1.0alpha Where can I get the version 4.75? I've tried write codes as you said: a.foo = 12 a. M-/ repeatly First: "py" Seconed: Force full parse and the problem occurred. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-09 19:04 Message: Logged In: YES user_id=44345 Hmmm... It's been years and years since Python-mode 1.0alpha was released, so I suspect you're looking in the wrong place for the version. We are currently at 4.75. You can get the current python-mode version by typing M-: py-version RET When I hit M-/ at the place you indicated, it completes with "c12". I have no idea why it chooses that completion, but it doesn't hang. It's not obvious to me what it should expand in this context. Did you have something in mind? If I change the code to ... a = A('abc') a.foo = 12 a. when I hit M-/ it properly expands to "a.foo" for me. Please try upgrading your python-mode. ---------------------------------------------------------------------- Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 18:33 Message: Logged In: YES user_id=1143754 When I'm editing C source files in cc-mode, the problem doesn't occur ---------------------------------------------------------------------- Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 17:44 Message: Logged In: YES user_id=1143754 OK, here's an example: #!/usr/bin/python class A: def __init__(self, name): self.name = name if __name__ == '__main__': a = A('abc') a.<------------- M-/ here, the bug can be reproduced the python-mode is 1.0alpha ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-07 11:19 Message: Logged In: YES user_id=44345 Can you provide an example Python file where this happens? Given that M-/ runs dabbrev-expand, I'm skeptical this has anything to do with python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 19:10 Message: Logged In: YES user_id=44345 What version of python-mode.el are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1215039&group_id=86916 From noreply at sourceforge.net Fri Jun 10 13:48:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 04:48:49 -0700 Subject: [Python-mode] [ python-mode-Patches-1194875 ] better (and more) coloring Message-ID: Patches item #1194875, was opened at 2005-05-04 02:44 Message generated for change (Comment added) made by jonaskoelker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas K?lker (jonaskoelker) Assigned to: Nobody/Anonymous (nobody) Summary: better (and more) coloring Initial Comment: this patch fixes some coloring problems. It's made against 4.70 (I diffed the CVS version against my debian/sarge python-mode.el: equal) --- fixed stuff try:pass colors everything except the : (same for except and finally) they still color the colon turquoise if there's at least one space or newline. If colon-coloring should be turned off, it's a simple swap-three-lines operation. it also correctly colors str(id(type(len))); but only (damn!) because it alternates between typenames and builtins. fixes not coloring the last exception in a tuple (and probably other similar things). (imo) correctly colors ValueError in `exceptions.ValueError'. adds set and frozenset to typenames. --- tweakable stuff: selecting alternate face for typenames (int, dict, type) selecting alternate face for builtins (exceptions, len, id) (these two defaults to kw-turquoise) selecting alternate face for numeric literals (but currently the RE-matching is dodgy) selecting alternate face for the first variable name in a for ... in (both expressions and statements) (it should be extended to more than just the first). (these two default to a vanilla face, 'py-plain-face) ---------------------------------------------------------------------- >Comment By: Jonas K?lker (jonaskoelker) Date: 2005-06-10 13:48 Message: Logged In: YES user_id=1153395 Hi. I must admit that I'm a newbie around diffs/patches, so I hope what I did was all right / The Right Thing: Applied your patch (giving two rejects), fixing one (trivially) by hand, fixing a (not-in-patch) spelling error, and saving that as pristine.el. Also, I made a working copy of that as python-mode.el (from original to pristine: pristine.diff) (difference between my diff and yours: diffs.diff) noteworthy: differences: the big chunk: (see below) leav vs. leave: (the typo) `(while (and': an extra line of context required in my diff >From there, I added the changes I proposed (most of the second reject). In its current state, all the `minor' issues are still as original (as-attribute coloring fixes, seperate typenames), and I've added coloring to the second variable in for ... in (plus of course the first). I'm afraid I wouldn't know how to generalise it to arbitrary numbers of variables--but one or two variables covers 95%+ of the code I write. (from pristine to (my current) python-model.el: current.diff) Currently, you still have to set non-user-definable variables to enjoy what I consider the full benefits (i.e. blue for builtins, green for type names, ... as per the font-lock--face) My plan is that if the patches I made apply cleanly, I will work from where I am now on resolving the pending issues: 1) adding *correct* numeric literal coloring 2) moving the to-be-user-definable variables above `NO USER DEFINABLE VARIABLES BEYOND THIS POINT' And from there, perhaps on extending the use of variable-name-face to function arguments and maybe(!) assignment statements. But this is the future future league stuff; I haven't really thought any of this through. --- Also, thanks (a lot) for doing s/number/numeric/ in py-\1-literal-face. I also added a bit to tests.py. Disregard anything it says about numeric literal coloring (obviously), just look at all the pretty colors :p --- Jonas K?lker ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-06-07 22:59 Message: Logged In: YES user_id=1153395 > There were a couple rejects because of other recent changes with the keyword re's. Can you give it a whirl? Sure. > I don't see any coloring for numeric literals. Should I? Most likely: no. That is, it won't be colored unless you set the variable 'py-number-literal-face to something interesting. I attach $(head .emacs) > I suspect that will be something a lot of people won't want, so there should be a way to disable it, and that should probably be the default. See above: it is the default. > Any chance you can fix the FIXMEs? I'll try. I'll also work or improving the interface to the 'py-whatever-face variables (i.e. put them *above* the "NO USER DEFINABLE VARIABLES BEYOND THIS POINT") ...Sorry for not replying sooner--I had an exam going on. Next one is 20th june, after which I'll more or less be away from my box 'till mid-july :( But until then, I have about n spare hours a day, of which I can devote m (where m <= n) to hacking on python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 00:11 Message: Logged In: YES user_id=44345 Thanks... I applied the patch locally and will play around with it a bit. Attached is a slightly tweaked diff. There were a couple rejects because of other recent changes with the keyword re's. Can you give it a whirl? Any chance you can fix the FIXMEs? I don't see any coloring for numeric literals. Should I? I suspect that will be something a lot of people won't want, so there should be a way to disable it, and that should probably be the default. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-05-04 02:46 Message: Logged In: YES user_id=1153395 sorry, I (something)ed up uploading the patch. Scene 24, take 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 From noreply at sourceforge.net Fri Jun 10 13:49:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 04:49:50 -0700 Subject: [Python-mode] [ python-mode-Patches-1194875 ] better (and more) coloring Message-ID: Patches item #1194875, was opened at 2005-05-04 02:44 Message generated for change (Comment added) made by jonaskoelker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas K?lker (jonaskoelker) Assigned to: Nobody/Anonymous (nobody) Summary: better (and more) coloring Initial Comment: this patch fixes some coloring problems. It's made against 4.70 (I diffed the CVS version against my debian/sarge python-mode.el: equal) --- fixed stuff try:pass colors everything except the : (same for except and finally) they still color the colon turquoise if there's at least one space or newline. If colon-coloring should be turned off, it's a simple swap-three-lines operation. it also correctly colors str(id(type(len))); but only (damn!) because it alternates between typenames and builtins. fixes not coloring the last exception in a tuple (and probably other similar things). (imo) correctly colors ValueError in `exceptions.ValueError'. adds set and frozenset to typenames. --- tweakable stuff: selecting alternate face for typenames (int, dict, type) selecting alternate face for builtins (exceptions, len, id) (these two defaults to kw-turquoise) selecting alternate face for numeric literals (but currently the RE-matching is dodgy) selecting alternate face for the first variable name in a for ... in (both expressions and statements) (it should be extended to more than just the first). (these two default to a vanilla face, 'py-plain-face) ---------------------------------------------------------------------- >Comment By: Jonas K?lker (jonaskoelker) Date: 2005-06-10 13:49 Message: Logged In: YES user_id=1153395 Hi. I must admit that I'm a newbie around diffs/patches, so I hope what I did was all right / The Right Thing: Applied your patch (giving two rejects), fixing one (trivially) by hand, fixing a (not-in-patch) spelling error, and saving that as pristine.el. Also, I made a working copy of that as python-mode.el (from original to pristine: pristine.diff) (difference between my diff and yours: diffs.diff) noteworthy: differences: the big chunk: (see below) leav vs. leave: (the typo) `(while (and': an extra line of context required in my diff >From there, I added the changes I proposed (most of the second reject). In its current state, all the `minor' issues are still as original (as-attribute coloring fixes, seperate typenames), and I've added coloring to the second variable in for ... in (plus of course the first). I'm afraid I wouldn't know how to generalise it to arbitrary numbers of variables--but one or two variables covers 95%+ of the code I write. (from pristine to (my current) python-model.el: current.diff) Currently, you still have to set non-user-definable variables to enjoy what I consider the full benefits (i.e. blue for builtins, green for type names, ... as per the font-lock--face) My plan is that if the patches I made apply cleanly, I will work from where I am now on resolving the pending issues: 1) adding *correct* numeric literal coloring 2) moving the to-be-user-definable variables above `NO USER DEFINABLE VARIABLES BEYOND THIS POINT' And from there, perhaps on extending the use of variable-name-face to function arguments and maybe(!) assignment statements. But this is the future future league stuff. --- Also, thanks (a lot) for doing s/number/numeric/ in py-\1-literal-face. I also added a bit to tests.py. Disregard anything it says about numeric literal coloring (obviously), just look at all the pretty colors :p --- Kind regards, Jonas K?lker ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-06-10 13:48 Message: Logged In: YES user_id=1153395 Hi. I must admit that I'm a newbie around diffs/patches, so I hope what I did was all right / The Right Thing: Applied your patch (giving two rejects), fixing one (trivially) by hand, fixing a (not-in-patch) spelling error, and saving that as pristine.el. Also, I made a working copy of that as python-mode.el (from original to pristine: pristine.diff) (difference between my diff and yours: diffs.diff) noteworthy: differences: the big chunk: (see below) leav vs. leave: (the typo) `(while (and': an extra line of context required in my diff >From there, I added the changes I proposed (most of the second reject). In its current state, all the `minor' issues are still as original (as-attribute coloring fixes, seperate typenames), and I've added coloring to the second variable in for ... in (plus of course the first). I'm afraid I wouldn't know how to generalise it to arbitrary numbers of variables--but one or two variables covers 95%+ of the code I write. (from pristine to (my current) python-model.el: current.diff) Currently, you still have to set non-user-definable variables to enjoy what I consider the full benefits (i.e. blue for builtins, green for type names, ... as per the font-lock--face) My plan is that if the patches I made apply cleanly, I will work from where I am now on resolving the pending issues: 1) adding *correct* numeric literal coloring 2) moving the to-be-user-definable variables above `NO USER DEFINABLE VARIABLES BEYOND THIS POINT' And from there, perhaps on extending the use of variable-name-face to function arguments and maybe(!) assignment statements. But this is the future future league stuff; I haven't really thought any of this through. --- Also, thanks (a lot) for doing s/number/numeric/ in py-\1-literal-face. I also added a bit to tests.py. Disregard anything it says about numeric literal coloring (obviously), just look at all the pretty colors :p --- Jonas K?lker ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-06-07 22:59 Message: Logged In: YES user_id=1153395 > There were a couple rejects because of other recent changes with the keyword re's. Can you give it a whirl? Sure. > I don't see any coloring for numeric literals. Should I? Most likely: no. That is, it won't be colored unless you set the variable 'py-number-literal-face to something interesting. I attach $(head .emacs) > I suspect that will be something a lot of people won't want, so there should be a way to disable it, and that should probably be the default. See above: it is the default. > Any chance you can fix the FIXMEs? I'll try. I'll also work or improving the interface to the 'py-whatever-face variables (i.e. put them *above* the "NO USER DEFINABLE VARIABLES BEYOND THIS POINT") ...Sorry for not replying sooner--I had an exam going on. Next one is 20th june, after which I'll more or less be away from my box 'till mid-july :( But until then, I have about n spare hours a day, of which I can devote m (where m <= n) to hacking on python-mode. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-05 00:11 Message: Logged In: YES user_id=44345 Thanks... I applied the patch locally and will play around with it a bit. Attached is a slightly tweaked diff. There were a couple rejects because of other recent changes with the keyword re's. Can you give it a whirl? Any chance you can fix the FIXMEs? I don't see any coloring for numeric literals. Should I? I suspect that will be something a lot of people won't want, so there should be a way to disable it, and that should probably be the default. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-05-04 02:46 Message: Logged In: YES user_id=1153395 sorry, I (something)ed up uploading the patch. Scene 24, take 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1194875&group_id=86916 From rozen at mcn.org Thu Jun 9 00:43:28 2005 From: rozen at mcn.org (Don Rozenberg) Date: Wed, 08 Jun 2005 15:43:28 -0700 Subject: [Python-mode] My Extensions to python-mode.el Message-ID: <42A77490.6060000@mcn.org> Hi, I am a little slow; I just saw a reference to the python-mode project. i would like to make you aware of my extensions to python-mode.el I have had some issues with the way python-mode launches python programs and have written an extension to python mode with which I am a bit more comfortable. Unfortunately, I am not skilled with emacs-lisp so I welcome suggestions for improvement. My extensions are avail via http://page.sourceforge.net. Here is a copy of the description of the extensions which can be found at sourceforge - http://page.sourceforge.net/py-mode-ext.html ----------------- Extensions to python-mode in emacs I really like to run and debugging python programs from inside of emacs but I have wanted to see a couple of additional features added to python-mode.el This applies to executing the program as well as running with a symbolic debugger. * I want to be able to conveniently supply arguments to the program under test. * There are times when I forget to save the buffers that I am editing, so I would like to have emacs inquire if I want them saved and respond to my reply. * Frequently, my programs involve more than one module and here python-mode foils me because it saves the current buffer as a temporary file in a temporary directory with a manufactured, unique name. There is no way that another module of the program will be found. I therefore want any changed modules saved and want to be able to specify the main module to be entered. * Again, many of my programs involve multiple modules and the one I am editing may not be the one I want as the initial module of the program. So I want to be able to specify the initial program. * I would like to have history capability to remember initial modules and argument lists used in the Emacs session. * Since python-mode allows me to execute a program with a simple key sequence, I then want to execute the program with the python debugger as easily. * I am a fan of PyChecker, so I want to be able to easily run that program from Emacs and be able to jump to source lines corresponding to PyChecker messages. py-mode-ext.el is a short bit of emacs lisp which I assert accomplishes the above. I am new to writing elisp so I welcome comments and suggestions. To use these extensions, py-mode-ext.el is placed in my emacs load path. I have the following code in my .emacs. (add-hook 'python-mode-hook '(lambda () (define-key py-mode-map "\C-c\C-c" 'py-execute-prog) (define-key py-mode-map "\C-c\C-g" 'py-call-pdb) (define-key py-mode-map "\C-c\C-w" 'pychecker))) (load "py-mode-ext.el") When the user presses one of the above key sequences for py-execute-prog or py-call-pdb, he will first be asked for the initial module. 1. It first reads from the mini-buffer the name of the initial file to be executed by the interpreter. If no history exists, then the file behind the current buffer is suggested. The user may then substitute any file he wishes as the initial file to be executed by the interpreter. It will be save in a history list. 2. Next, it reads from the mini-buffer the argument string to be passed to the program being interpreted. Again, if there is a history of arguments, the most recent will be selected. The user may over ride the suggestion. The argument string passed to the program will be saved in a history list. 3. It next saves all the modified buffers based on a query. 4. Finally, it invokes python on the initial file or it invokes pdb on the initial file. If there is a history item for initial modules that will be suggested otherwise the file corresponding to the current buffer is suggested. Change the item if desired and then hit return. The next question to be asked is the argument list for the execution. Again, if there is a history then the most recent argument list will be selected. If you want to change it, go ahead and then hit return. At that point execution or the debugger is initiated. When the user initiates the command for pychecker, it will check whether any buffers have been changed and ask whether you want any of those saved. Then it will run PyChecker against the file behind the current buffer. PAGE Home ------------------- PAGE is my sourceforge project to develop a drag-and-drop GUI generator for Python. -- Don Rozenberg 707-882-3601 don.rozenberg at gmail.com From steelman at post.pl Thu Jun 23 13:32:16 2005 From: steelman at post.pl (Lukasz Stelmach) Date: Thu, 23 Jun 2005 13:32:16 +0200 Subject: [Python-mode] how to install python-mod Message-ID: <20050623113216.GA7524@delfin.lan> Greetings. Please, write it somewhere at http://python-mode.sourceforge.net/docs/... I am quite a newbie to Emacs. TIA -- By?o mi bardzo mi?o. Trzecia pospolita kl?ska, [...] >?ukasz< Ju? nie katolicka lecz z?odziejska. (c)PP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/python-mode/attachments/20050623/e4ea797c/attachment.pgp From skip at pobox.com Thu Jun 23 21:14:29 2005 From: skip at pobox.com (Skip Montanaro) Date: Thu, 23 Jun 2005 14:14:29 -0500 Subject: [Python-mode] how to install python-mod In-Reply-To: <20050623113216.GA7524@delfin.lan> References: <20050623113216.GA7524@delfin.lan> Message-ID: <17083.2581.443865.112198@montanaro.dyndns.org> Lukasz> Please, write it somewhere at Lukasz> http://python-mode.sourceforge.net/docs/... I am quite a newbie Lukasz> to Emacs. Once I get back to the nascent documentation I'll add a blurb about installing it. Generally, you just drop python-mode.el in some directory on load-path and add (setq auto-mode-alist (cons '("\\.py$" . python-mode) auto-mode-alist)) to your .emacs file. -- Skip Montanaro skip at pobox.com From steelman at post.pl Fri Jun 24 13:49:10 2005 From: steelman at post.pl (Lukasz Stelmach) Date: Fri, 24 Jun 2005 13:49:10 +0200 Subject: [Python-mode] how to install python-mod In-Reply-To: <17083.2581.443865.112198@montanaro.dyndns.org> References: <20050623113216.GA7524@delfin.lan> <17083.2581.443865.112198@montanaro.dyndns.org> Message-ID: <20050624114910.GA4717@delfin.lan> Byla godzina 14:14:29 w czwartek 23 czerwiec, gdy do autobusu wsiadl kanar i wrzasnal:"Skip Montanaro!!! Bilecik do kontroli!!!" A on(a) na to: Lukasz>> Please, write it somewhere at Lukasz>> http://python-mode.sourceforge.net/docs/... I am quite Lukasz>> a newbie to Emacs. SM> Generally, you just drop python-mode.el in some directory on SM> load-path and add [...] Thanks a lot :) -- By?o mi bardzo mi?o. Trzecia pospolita kl?ska, [...] >?ukasz< Ju? nie katolicka lecz z?odziejska. (c)PP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/python-mode/attachments/20050624/d3b93540/attachment.pgp From noreply at sourceforge.net Mon Jun 27 00:37:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 15:37:15 -0700 Subject: [Python-mode] [ python-mode-Bugs-1180180 ] Proposed improvement for pycomplete Message-ID: Bugs item #1180180, was opened at 2005-04-10 14:33 Message generated for change (Comment added) made by hugoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hugo Haas (hugoh) Assigned to: Nobody/Anonymous (nobody) Summary: Proposed improvement for pycomplete Initial Comment: Hi. I really like the idea of pycomplete a lot. However, it only completes simple cases: "sys.cl" becomes "sys.clock" once completed. What would be interesting would be to get a list of completions for "sys.". I believe that what needs to be changed is the following: - have pycomplete.py return a list of all possibilities - in py-complete() in pycomplete.el, use the output of pycomplete.py to call try-completion; if it works, use it, if not and there are several possibilities, display all the possibilities given by all-completions and allow to chose between them. The former is trivial (patch attached). I tried to do the latter, but my lack of knowledge in elisp put a rapid stop to it, so in case somebody knows elisp and is interested by this (I think it would be a cool feature), I thought I'd record the idea here. Regards, Hugo ---------------------------------------------------------------------- >Comment By: Hugo Haas (hugoh) Date: 2005-06-27 00:37 Message: Logged In: YES user_id=331657 It seems to do exactly what I was after! Except maybe for the completion prompt, as maybe it could just give a list of possibilities in a separate buffer without requiring the use of the mini-buffer, but that's a detail. Thanks a lot. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-05-27 02:52 Message: Logged In: YES user_id=374783 I've implemented these suggestions and put the resulting files at http://isnomore.net/prog/pycomplete/ . Please take a look and let me know what you (all) think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 From noreply at sourceforge.net Mon Jun 27 22:13:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 13:13:23 -0700 Subject: [Python-mode] [ python-mode-Bugs-1180180 ] Proposed improvement for pycomplete Message-ID: Bugs item #1180180, was opened at 2005-04-10 09:33 Message generated for change (Comment added) made by errebepe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hugo Haas (hugoh) Assigned to: Nobody/Anonymous (nobody) Summary: Proposed improvement for pycomplete Initial Comment: Hi. I really like the idea of pycomplete a lot. However, it only completes simple cases: "sys.cl" becomes "sys.clock" once completed. What would be interesting would be to get a list of completions for "sys.". I believe that what needs to be changed is the following: - have pycomplete.py return a list of all possibilities - in py-complete() in pycomplete.el, use the output of pycomplete.py to call try-completion; if it works, use it, if not and there are several possibilities, display all the possibilities given by all-completions and allow to chose between them. The former is trivial (patch attached). I tried to do the latter, but my lack of knowledge in elisp put a rapid stop to it, so in case somebody knows elisp and is interested by this (I think it would be a cool feature), I thought I'd record the idea here. Regards, Hugo ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-06-27 17:13 Message: Logged In: YES user_id=374783 I used minibuffer because it seems to be the way Emacs usually handles these things. It's also a close analogy with the way Eclipse does it. Anyway, I've been thinking about code-completion for a while, and it seems the best way to do it would be to parse the code and act according to context. Apparently, the Semantic package (http://cedet.sourceforge.net/semantic.shtml) does this. Now, if I can get it to work... ---------------------------------------------------------------------- Comment By: Hugo Haas (hugoh) Date: 2005-06-26 19:37 Message: Logged In: YES user_id=331657 It seems to do exactly what I was after! Except maybe for the completion prompt, as maybe it could just give a list of possibilities in a separate buffer without requiring the use of the mini-buffer, but that's a detail. Thanks a lot. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-05-26 21:52 Message: Logged In: YES user_id=374783 I've implemented these suggestions and put the resulting files at http://isnomore.net/prog/pycomplete/ . Please take a look and let me know what you (all) think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 From noreply at sourceforge.net Mon Jun 27 23:44:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 14:44:24 -0700 Subject: [Python-mode] [ python-mode-Bugs-1180180 ] Proposed improvement for pycomplete Message-ID: Bugs item #1180180, was opened at 2005-04-10 09:33 Message generated for change (Comment added) made by errebepe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hugo Haas (hugoh) Assigned to: Nobody/Anonymous (nobody) Summary: Proposed improvement for pycomplete Initial Comment: Hi. I really like the idea of pycomplete a lot. However, it only completes simple cases: "sys.cl" becomes "sys.clock" once completed. What would be interesting would be to get a list of completions for "sys.". I believe that what needs to be changed is the following: - have pycomplete.py return a list of all possibilities - in py-complete() in pycomplete.el, use the output of pycomplete.py to call try-completion; if it works, use it, if not and there are several possibilities, display all the possibilities given by all-completions and allow to chose between them. The former is trivial (patch attached). I tried to do the latter, but my lack of knowledge in elisp put a rapid stop to it, so in case somebody knows elisp and is interested by this (I think it would be a cool feature), I thought I'd record the idea here. Regards, Hugo ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-06-27 18:44 Message: Logged In: YES user_id=374783 I just managed to use Semantic with ECB (http://ecb.sourceforge.net/). Installed both, fired up ECB (M-x ecb-activate). From then on, on a source file, I type M-Tab and it completes (using the same "interface" my patch provides, which I found cool, BTW). I've spotted what is apparently a bug (when importing a module from a file I created on the current directory), but otherwise it seems to work! ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-06-27 17:13 Message: Logged In: YES user_id=374783 I used minibuffer because it seems to be the way Emacs usually handles these things. It's also a close analogy with the way Eclipse does it. Anyway, I've been thinking about code-completion for a while, and it seems the best way to do it would be to parse the code and act according to context. Apparently, the Semantic package (http://cedet.sourceforge.net/semantic.shtml) does this. Now, if I can get it to work... ---------------------------------------------------------------------- Comment By: Hugo Haas (hugoh) Date: 2005-06-26 19:37 Message: Logged In: YES user_id=331657 It seems to do exactly what I was after! Except maybe for the completion prompt, as maybe it could just give a list of possibilities in a separate buffer without requiring the use of the mini-buffer, but that's a detail. Thanks a lot. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-05-26 21:52 Message: Logged In: YES user_id=374783 I've implemented these suggestions and put the resulting files at http://isnomore.net/prog/pycomplete/ . Please take a look and let me know what you (all) think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 From noreply at sourceforge.net Tue Jun 28 05:26:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2005 20:26:03 -0700 Subject: [Python-mode] [ python-mode-Bugs-1180180 ] Proposed improvement for pycomplete Message-ID: Bugs item #1180180, was opened at 2005-04-10 09:33 Message generated for change (Comment added) made by errebepe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hugo Haas (hugoh) Assigned to: Nobody/Anonymous (nobody) Summary: Proposed improvement for pycomplete Initial Comment: Hi. I really like the idea of pycomplete a lot. However, it only completes simple cases: "sys.cl" becomes "sys.clock" once completed. What would be interesting would be to get a list of completions for "sys.". I believe that what needs to be changed is the following: - have pycomplete.py return a list of all possibilities - in py-complete() in pycomplete.el, use the output of pycomplete.py to call try-completion; if it works, use it, if not and there are several possibilities, display all the possibilities given by all-completions and allow to chose between them. The former is trivial (patch attached). I tried to do the latter, but my lack of knowledge in elisp put a rapid stop to it, so in case somebody knows elisp and is interested by this (I think it would be a cool feature), I thought I'd record the idea here. Regards, Hugo ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-06-28 00:26 Message: Logged In: YES user_id=374783 Ahn... Sorry, false alarm. I was still using my code completion code and hadn't realized it. No wonder it was so similar ;) Haven't had much luck using Semantic yet, though I still think it's the best approach. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-06-27 18:44 Message: Logged In: YES user_id=374783 I just managed to use Semantic with ECB (http://ecb.sourceforge.net/). Installed both, fired up ECB (M-x ecb-activate). From then on, on a source file, I type M-Tab and it completes (using the same "interface" my patch provides, which I found cool, BTW). I've spotted what is apparently a bug (when importing a module from a file I created on the current directory), but otherwise it seems to work! ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-06-27 17:13 Message: Logged In: YES user_id=374783 I used minibuffer because it seems to be the way Emacs usually handles these things. It's also a close analogy with the way Eclipse does it. Anyway, I've been thinking about code-completion for a while, and it seems the best way to do it would be to parse the code and act according to context. Apparently, the Semantic package (http://cedet.sourceforge.net/semantic.shtml) does this. Now, if I can get it to work... ---------------------------------------------------------------------- Comment By: Hugo Haas (hugoh) Date: 2005-06-26 19:37 Message: Logged In: YES user_id=331657 It seems to do exactly what I was after! Except maybe for the completion prompt, as maybe it could just give a list of possibilities in a separate buffer without requiring the use of the mini-buffer, but that's a detail. Thanks a lot. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2005-05-26 21:52 Message: Logged In: YES user_id=374783 I've implemented these suggestions and put the resulting files at http://isnomore.net/prog/pycomplete/ . Please take a look and let me know what you (all) think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1180180&group_id=86916 From noreply at sourceforge.net Wed Jun 29 14:30:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Jun 2005 05:30:17 -0700 Subject: [Python-mode] [ python-mode-Bugs-912521 ] python-mode kills arrow in gdb (gud.el) Message-ID: Bugs item #912521, was opened at 2004-03-09 07:34 Message generated for change (Comment added) made by d_kagedal You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=912521&group_id=86916 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode kills arrow in gdb (gud.el) Initial Comment: [this is http://python.org/sf/606250, reopened] forwarded from http://bugs.debian.org/159628 ] Once python-mode.el has been loaded, all GDB buffers stop showing the little arrow that lives in the "fringe" on the left side of an emacs21 frame. To be specific, the arrow appears and then disappears right away, each time a 'step' or 'next' command is run. I traced the problem down to the unconditional hooking of 'comint-output-filter-functions, python-mode.el line 3472 to be exact: (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file) I haven't tested it fully, but I've found that if I take this line out, GDB can show its arrow once more. There is code in python-mode.el to insert this hook in a buffer-local fashion only in the '*Python*' buffer.. maybe that should be reviewed and used instead of this global hook? (took forever to figure out it was python-mode causing the problem..) Followup: This one is still broken for me, in python-mode 4.40. (I'm the submitter of the original debian bug report). Here are some instructions to reproduce the problem: =============== 574:warner at cinla% cat hello.c #include int main(void) { printf("hello\n"); printf("world\n"); printf("\n"); return 0; } 575:warner at cinla% gcc -g -o hello hello.c 576:warner at cinla% ./hello hello world 577:warner at cinla% cat foo.py #! /usr/bin/python print "hiya" 578:warner at cinla% emacs -q M-x gdb hello RET # starts GUD session (gdb) b main RET (gdb) run RET # GDB stops on "hello". Note arrow in fringe. C-x C-f foo.py RET # loads python-mode.el C-x b *gud-hello* RET # switch back to GDB buffer (gdb) next RET # GDB stops on "world". Note lack of arrow. (gdb) next RET # arrow flickers and disappears each time =================== emacs-version reports "GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit) of 2003-10-31 on raven, modified by Debian" this is package emacs21, version 21.3+1-4 (from unstable) python-elisp is version 2.3.2.91-1, with py-version at $Revision: 4.40 $ let me know if there is anything I can do to further track it down. thanks! -Brian ---------------------------------------------------------------------- Comment By: David K?gedal (d_kagedal) Date: 2005-06-29 14:30 Message: Logged In: YES user_id=1260741 I usually work around this by applying this patch: --- python-mode.el~ 2005-04-08 16:45:30.000000000 +0200 +++ python-mode.el 2005-06-21 11:53:55.000000000 +0200 @@ -1334,7 +1334,7 @@ (setq overlay-arrow-string "=>") (set-marker overlay-arrow-position (py-point 'bol) (current-buffer)) (setq py-pdbtrack-is-tracking-p t)) - (overlay-arrow-position + (nil ;; overlay-arrow-position (setq overlay-arrow-position nil) (setq py-pdbtrack-is-tracking-p nil)) )) The problem is that the comint filter function is called even when running gud, and sinc it doesn't detect a python line to show, it disables the overlay arrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=912521&group_id=86916