Few annoyances when programming Python

[asandler]

Hi.

I would like to report two small annoyances with Python.

1) In Python document mode, when pressing HOME key, cursor goes to the first column. Second press on HOME takes the cursor to column where actual text begins. This is opposite to C/C++ mode (and perhaps other modes) where first HOME press takes the cursor to first text column and second press takes the cursor to first column.

2) When inserting for loop, typing "for" causes SE to insert "for  in :". It places the cursor between "for" and "in". This is a little inconvenient because when you're done typing expression between "for" and "in" you have to either use mouse to place the cursor after "in", or to do it with arrow keys. This breaks the flow of how you type the text in. I think it would be better to insert colon, without "in" and let programmer to type the "in" part manually. This way, number of key presses that programmer will have to do is the same as before, but hands will remain on keyboard and won't wonder looking for mouse or arrow keys.

Thanks.
Alex.

PS: I have SE 14 for Windows with revision 13 of hotfixes.

[hs2]

Concerning 2) you could use the next/prev-hotspot command(s) to go directly to the potential points of code insertion after expanding this kind of language constructs.
When defining your own aliases you can also use this feature by adding '%\c' at the appr. locations.
Example C/C++ alias tde:

Code: [Select]

typedef enum %\c_
{
} %\c;
HS2

[Graeme]

What do you mean by Python document mode?  Your home key is probably bound to begin_line_text_toggle().  I don't know what's going on but it seems the call to commentwrap_Home is going to return false for python even when in a comment region, so the cursor will first go to the first non blank, then the start of the line  - and this is what it does in a python source file for me.  Can you post some example code where the home key goes to the start of the line first.

Graeme

[asandler]

@hs2: I think I see what your point is. It does solve the problem partially. Yet it is still isn't perfect. The hotspot placement is like this: "for <hotspot> in<hotspot> :". Note the space between second hotspot and the colon. You still have to jump over that extra space character, with either arrow keys or mouse.

@Graeme: by Python document mode I mean just editing Python file. My home key is indeed bound to being-line-text-toggle. As for code sample, this one should do:

Code: [Select]

import sys

class SomeClass:
def __init__(self):
print "This is a constructor"


[Graeme]

The first press of the home key goes to the first non blank for me, but I have hotfix revision 10, not 13.  Maybe you have a python mode binding for the home key?

Hotfix revision 13 doesn't load for me so I'm surprised you have revision 13.

Graeme

[asandler]

The first press of the home key goes to the first non blank for me, but I have hotfix revision 10, not 13.  Maybe you have a python mode binding for the home key?

Are you sure you're working in Python mode - try Document->Select Mode->Python
Can you bind same key to do two different things in various modes? Anyway, I didn't touch Home key binding in any way.

Hotfix revision 13 doesn't load for me so I'm surprised you have revision 13.

This is strange. I had no problems with 13. Are you the only one who have problems with rev. 13? In any case I had this problem with rev 10 as well.

[Graeme]

I have a .py file and it's definitely in python mode.  The key bindings dialog will show you all the bindings for the home key  - mine shows 2 - one for default mode and one for process mode.

See http://community.slickedit.com/index.php?topic=4770.msg19727#msg19727 regarding hotfix rev 13.

Graeme

[chrisant]

This is strange. I had no problems with 13. Are you the only one who have problems with rev. 13? In any case I had this problem with rev 10 as well.

Rev 13 is missing a file "diff.sh"; the file is in the hotfix.xml manifest but not in the zip file.
See here and here.

[ScottW, VP of Dev]

We've also discovered a problem with pulling in dependent changes from Slick-C headers. We're working to remedy these issues and to post a new hotfix.

[asandler]

Then perhaps I've missed the error message when installed rev. 13. In any case, this is not the problem. I had it with SE 14 from the start.