From noreply at sourceforge.net Sun Jul 10 08:13:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 23:13:56 -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-08 22:34 Message generated for change (Comment added) made by gustavh 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: Gustav H?llberg (gustavh) Date: 2005-07-09 23:13 Message: Logged In: YES user_id=1310184 I did some testing around this about two years ago, and I then concluded that the right fix is similar to what d_kagedal suggests, but that you want the deactivation to be run iff py-pdbtrack-is-tracking-p: --- python-mode.el~ 2004-10-21 14:27:30.000000000 -0700 +++ python-mode.el 2005-07-09 23:03:43.417759376 -0700 @@ -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 + (py-pdbtrack-is-tracking-p (setq overlay-arrow-position nil) (setq py-pdbtrack-is-tracking-p nil)) )) ---------------------------------------------------------------------- Comment By: David K?gedal (d_kagedal) Date: 2005-06-29 05: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 From noreply at sourceforge.net Tue Jul 12 19:41:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 10:41:32 -0700 Subject: [Python-mode] [ python-mode-Patches-785816 ] Py #567468: A different patch for python-mode vs gdb Message-ID: Patches item #785816, was opened at 2003-08-09 03:03 Message generated for change (Comment added) made by gustavh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=785816&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: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Py #567468: A different patch for python-mode vs gdb Initial Comment: This is from http://python.org/sf/567468: Patch 509975 fixes the conflict between gdb-mode and python-mode by checking whether the current process is a python process. My patch fixes it more simply, by only clearing the overlay arrow if we were the ones who set it. I'd be happy with either patch. -------------------------------------------------------------- Date: 2002-07-16 18:53 Sender: bwarsaw Logged In: YES user_id=12800 I've rejected 509975 because it doesn't play nice when you're pdb tracking from the shell (see comments in that patch). I'm not sure this patch works correctly either, but for a different reason: it doesn't actually work for me! If I add "import pdb; pdb.set_trace()" to a file and then execute the file from the shell buffer, I see the overlay arrow. If I then switch to a gdb debugging a C program and hit "next", the overlay arrow in the .py buffer disappears. This seems like a tricky problem and I don't have a good solution, but I think I have to reject this patch too. ----------------------------------------------------------------- Date: 2002-07-16 19:02 Sender: nobody Logged In: NO The problem my patch was intended to fix is that currently just loading python-mode.el (as happens by default under Red Hat 7.3) breaks gdb-mode. With my patch, it works fine. emacs only supports one overlay arrow at a time; if you hit 'next' in gdb, gdb-mode will set the overlay arrow, which means that it will no longer be set in the python buffer. This may not be ideal behavior, but it's a limitation of emacs, not a bug in my patch. ----------------------------------------------------------------- Date: 2002-07-16 19:30 Sender: bwarsaw Logged In: YES user_id=12800 Hmm, it must work differently in emacs than in XEmacs (which is what I use). In a vanilla Emacs 21.2.1 I can't get the overlay arrow to work even without python-mode.el loaded, so I'll have to take your word for it. In XEmacs, I definitely do get two overlay arrows, one in the C buffer and one in the python-mode buffer. As I step through the python program, the C arrow stays nicely visible and highlighted. As I step through gdb though, the python overlay arrow disappears. Your patch makes no difference to me and I can't get overlay arrow working at all in Emacs, so I suppose the patch is benign. I'll reopen it but I'd like confirmation from some other Emacs user that this fixes the problem in that editor. Alternatively, maybe I should just apply it and worry about it if people complain. ---------------------------------------------------------------------- Comment By: Gustav H?llberg (gustavh) Date: 2005-07-12 10:41 Message: Logged In: YES user_id=1310184 This patch should really be applied. It works perfectly fine in emacs 21 Cf. discussion in bug 912521 : python-mode kills arrow in gdb (gud.el) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=785816&group_id=86916 From noreply at sourceforge.net Fri Jul 15 13:29:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 04:29:20 -0700 Subject: [Python-mode] [ python-mode-Bugs-1238835 ] py-mark-block doesn't highlight region Message-ID: Bugs item #1238835, was opened at 2005-07-15 13:29 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=1238835&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: David Reitter (davidswelt) Assigned to: Nobody/Anonymous (nobody) Summary: py-mark-block doesn't highlight region Initial Comment: py-mark-block doesn't highlight the region, while py-mark-def-or-class does it (as expected). I use transient-mark-mode (and cua-mode), the active region is supposed to be highlighted. I tried fixing it myself, no luck, sorry! (This is the CVS version as of 07/2005) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1238835&group_id=86916 From noreply at sourceforge.net Mon Jul 18 20:21:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 11:21:35 -0700 Subject: [Python-mode] [ python-mode-Patches-1240446 ] tab completion for py-shell Message-ID: Patches item #1240446, was opened at 2005-07-18 20:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1240446&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: Lukasz Pankowski (lupan) Assigned to: Nobody/Anonymous (nobody) Summary: tab completion for py-shell Initial Comment: I always used py-shell for its Emacs editing capabilities and Python in the Linux shell for its support for completion with readline. Finally I sit down to have both in one (polished recently). What are the chances to include this (modified as needed, names for sure are not perfect)? Here are the features/issues: 0. Works for both GNU Emacs (21.4 in Debian Sid) and XEmacs (21.4 in Debian Sid). For XEmacs with some emulation of GNU Emacs comint functions. 1. It can complete in multiline input -- it collects the input send interactively to Python in case of completion, injects the completion code after C-c and resends the the saved lines. 2. The python completion code may omit some wizard-only knowledge (if any). 3. completion function inserts tab if nothing to complete -- good candidate for tab key. 4. I send it as separate module so py-comint-output-filter-function (from revision: 4.62) is included with small modification. py-shell-hook needed to run it inculded the module comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1240446&group_id=86916 From noreply at sourceforge.net Tue Jul 19 00:27:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 15:27:59 -0700 Subject: [Python-mode] [ python-mode-Bugs-1240558 ] comment badly affects following line indentation Message-ID: Bugs item #1240558, was opened at 2005-07-18 17:27 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=1240558&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: comment badly affects following line indentation Initial Comment: In code like this: def foo(): x = 1 # indentation is wrong after this comment y = 1 the 'y = 1' line is not properly indented. (Hitting tab in this line does not fix it either.) It seems like the indentation engine should ignore comments. (In case this form messes up whitespace, the 'x = 1' line is indented and the others are not.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1240558&group_id=86916 From noreply at sourceforge.net Tue Jul 19 23:31:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jul 2005 14:31:32 -0700 Subject: [Python-mode] [ python-mode-Bugs-1241188 ] fill-paragraph (M-q) does awful things to python code Message-ID: Bugs item #1241188, was opened at 2005-07-19 16:31 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=1241188&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: fill-paragraph (M-q) does awful things to python code Initial Comment: It would be nice if fill-paragraph (M-q) did reasonable things to python code. For example, it could wrap all strings and comments in the enclosing function, breaking up strings into adjacent one-line substrings "like" "this". Even better, it would be nice if it would reformat long expressions so that they were nicely wrapped (e.g., arranging split binary expressions so that the operator is at the beginning of a line rather than the end). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=1241188&group_id=86916 From noreply at sourceforge.net Thu Jul 28 16:04:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jul 2005 07:04:08 -0700 Subject: [Python-mode] [ python-mode-Bugs-783235 ] python-mode and nested indents Message-ID: Bugs item #783235, was opened at 2003-08-04 20:04 Message generated for change (Comment added) made by docwhat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=783235&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: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode and nested indents Initial Comment: (migrated from python project, bug #587239) Original submission: Using Python-mode 4.6 and GNU emacs 21.2.2, I enter the following: if x < 0: for i in range(100): print i else: print "x is negative" If I now put the cursor on the "else:" line and hit tab, it erroneously changes the indentation to line the "else" up with the "for" above it. Followup comments: Date: 2002-07-26 17:40 Sender: tim_one Logged In: YES user_id=31435 It's up to Barry to decide (and I assigned the report to him). I'll only add that the behavior does appear to be as documented: """ The \[indent-for-tab-command] and \[py-newline- and- indent] keys try to suggest plausible indentation, based on the indentation of preceding statements. [example snipped] Python-mode cannot know whether that's what you intended, or whether \tif a > 0: \t c = d \t_ was your intent. In general, Python-mode either reproduces the indentation of the (closest code or indenting-comment) preceding statement, or adds an extra py-indent-offset blanks if the preceding statement has `:' as its last significant (non-whitespace and non- comment) character. If the suggested indentation is too much, use \[py-electric-backspace] to reduce it. "" That seems (to me) easy to remember and to live with. Date: 2002-07-26 17:14 Sender: arkoenig Logged In: YES user_id=418174 If you really believe that hitting tab means that the block structure isn't what you intended, then you should also believe that hitting tab repeatedly on a line that can legally be indented in exactly two different ways (presumably with different meanings) should cycle between the meanings. Which it doesn't in this case. I am willing to accept that hitting tab should generate the maximum legal indent, which would mean that the behavior I described with "else:" isn't a bug. I do think, though, that generating an illegal indent should be considered a bug. I also think that for most cases, lining up an "else" with the nearest preceding "if" or "elif" rather than the nearest preceding "for" or "while" is less surprising, though I'll admit that's a matter of taste. Date: 2002-07-26 17:05 Sender: tim_one Logged In: YES user_id=31435 I agree that the second one (elif) may be considered a bug. Afraid I can't agree aboiut the first reason, though: of course hitting tab in pymode can change the meaning. When you've got if whatever: ->x y and hit tab when on the line containing y, it assumes you're hitting tab for a reason, not just to make trouble <wink>. I believe there's a discussion about this in the long form of the pymode help. Since pymod can't *know* the block structure you intend, it does its best to guess, and hitting a "guess the block structure I intended" key is taken as meaning, for a start, that the block structure on the current line isn't what you intended (else why would have hit the key? as a Python programmer, you should already know this isn't C mode <wink>). Date: 2002-07-26 16:49 Sender: arkoenig Logged In: YES user_id=418174 Frankly, I hadn't thought of that possibility! However, I still consider the behavior a bug, for two reasons: (1) I can type something that's syntactically valid, hit tab, and have it change the meaning of what I typed, and (2) It changes the indentation in the same way if I say "elif:" instead of "else:", even though that change is not syntactically valid. That is (using -> to indicate a tab): if x < 0: ->for i in range(100): ->->print i elif x > 0: ->print x Again, hitting tab on the "elif" line will indent the "elif" to line up with the "for", even though the result is syntactically invalid. Date: 2002-07-26 16:14 Sender: tim_one Logged In: YES user_id=31435 Andrew, why is that erroneous? Loops in Python have (optional) "else:" clauses too. There's no way for pymode to guess whether you intended the else to go with the if or the for. I expect it looks backward for the closest- preceding construct the else-statement could "belong to", and finds the for-loop first. ---------------------------------------------------------------------- Comment By: Christian H?ltje (docwhat) Date: 2005-07-28 07:04 Message: Logged In: YES user_id=267 I'm having a hard time following this bug, because the formatting is strange in sourceforge. (Is there someplace else I can read this that'll be easier to read?) Anyway, I think you're talking about how I can type something like (_==spaces): if a: __x __y If I move to y and hit tab, the indent cycles between being indented two characters or none. I personally hate this behaviour. I bump the tab and then the line gets screwed up. I would really like a way to disable this. The cases where it the best guess isn't right is few enough that I don't really care that I have to hit backspace after tab. I think this was the previous behaviour, because I don't remember this from before. :-( So, an option to turn this off would be apprecated... Love the mode, otherwise. :-) Ciao! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=581349&aid=783235&group_id=86916 From noreply at sourceforge.net Sat Jul 30 18:29:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 09:29:58 -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 23:16 Message generated for change (Comment added) made by todddeluca 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: Todd DeLuca (todddeluca) Date: 2005-07-30 12:29 Message: Logged In: YES user_id=1321242 I am having the same problem. It started happening around the time my box was upgraded to the new Debian stable release, Sarge. I am using version 4.75 of python-mode. The problem manifests seemingly randomly for me. It seems to happen more with short python files. I can not think of a long or old (pre-upgrade to sarge) python file where I've had this problem. I am not using M-/ (code completion). The problem may manifest when I hit return to go to a new line or when I hit backspace to unindent out of a block that I've just ended. I am using gnu emacs version 21.4.1 I am forced to kill from a different terminal to close my emacs, since I run it in the foreground of a terminal. Any suggestions for how to fix this problem would be greatly appreciated. It makes it nearly impossible to use python-mode when at any time emacs can freeze and loose all of my work (since my last save.) I'm sorry I have not been able to reproduce the problem consistently yet. If that is helpful I will attempt to do so. Best regards, Todd DeLuca P.S. some diagnostic info (a repeat of what was mentioned above): $ emacs --version GNU Emacs 21.4.1 from top command: 3440 td23 14 0 19336 18m 2900 R 99.9 0.5 16:05.32 emacs python-mode version (from C-c C-v): version $Revision: 4.75 $ ---------------------------------------------------------------------- Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 07: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 07: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 06: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 05: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 23: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 07: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 Sat Jul 30 19:03:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 10:03:22 -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 23:16 Message generated for change (Comment added) made by todddeluca 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: Todd DeLuca (todddeluca) Date: 2005-07-30 13:03 Message: Logged In: YES user_id=1321242 Ok, I've created a simple reproducible example. The following code consistently freezes if the last character in the file is '1'. If there is a newline following the '1', then everything is fine. if 1 < 2: # die here x = 1 It also freezes under the same condition if you replace the if statement with a for i in range(10): loop. The following file does NOT freeze even if the '1' is the last character in the file: x = 1 So perhaps it has something to do with the indentation. Everything seems to hinge on there being no characters following the last line of code. I tried putting spaces on the end of the 'x = 1' line and it still froze with a 'Force full reparse' message. Sometimes the 'Force full reparse' message is not displayed when it freezes, but I think that detail is insignificant. I hope these code snippets are helpful in debugging the problem. Thank y'all for producing and maintaining python-mode. Its coloring and indenting features have been very helpful to me, and I get the feeling I'm just scratching the surface. Cheers, Todd ---------------------------------------------------------------------- Comment By: Todd DeLuca (todddeluca) Date: 2005-07-30 12:29 Message: Logged In: YES user_id=1321242 I am having the same problem. It started happening around the time my box was upgraded to the new Debian stable release, Sarge. I am using version 4.75 of python-mode. The problem manifests seemingly randomly for me. It seems to happen more with short python files. I can not think of a long or old (pre-upgrade to sarge) python file where I've had this problem. I am not using M-/ (code completion). The problem may manifest when I hit return to go to a new line or when I hit backspace to unindent out of a block that I've just ended. I am using gnu emacs version 21.4.1 I am forced to kill from a different terminal to close my emacs, since I run it in the foreground of a terminal. Any suggestions for how to fix this problem would be greatly appreciated. It makes it nearly impossible to use python-mode when at any time emacs can freeze and loose all of my work (since my last save.) I'm sorry I have not been able to reproduce the problem consistently yet. If that is helpful I will attempt to do so. Best regards, Todd DeLuca P.S. some diagnostic info (a repeat of what was mentioned above): $ emacs --version GNU Emacs 21.4.1 from top command: 3440 td23 14 0 19336 18m 2900 R 99.9 0.5 16:05.32 emacs python-mode version (from C-c C-v): version $Revision: 4.75 $ ---------------------------------------------------------------------- Comment By: Shixin Zeng (pupilzeng) Date: 2005-06-09 07: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 07: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 06: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 05: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 23: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 07: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