1998-10-10 15:48:31 -03:00
|
|
|
import string
|
1999-06-02 08:05:19 -03:00
|
|
|
#from Tkinter import TclError
|
|
|
|
#import tkMessageBox
|
|
|
|
#import tkSimpleDialog
|
1999-05-21 01:38:27 -03:00
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
###$ event <<newline-and-indent>>
|
|
|
|
###$ win <Key-Return>
|
|
|
|
###$ win <KP_Enter>
|
|
|
|
###$ unix <Key-Return>
|
|
|
|
###$ unix <KP_Enter>
|
|
|
|
|
|
|
|
###$ event <<indent-region>>
|
|
|
|
###$ win <Control-bracketright>
|
|
|
|
###$ unix <Alt-bracketright>
|
|
|
|
###$ unix <Control-bracketright>
|
|
|
|
|
|
|
|
###$ event <<dedent-region>>
|
|
|
|
###$ win <Control-bracketleft>
|
|
|
|
###$ unix <Alt-bracketleft>
|
|
|
|
###$ unix <Control-bracketleft>
|
|
|
|
|
|
|
|
###$ event <<comment-region>>
|
|
|
|
###$ win <Alt-Key-3>
|
|
|
|
###$ unix <Alt-Key-3>
|
|
|
|
|
|
|
|
###$ event <<uncomment-region>>
|
|
|
|
###$ win <Alt-Key-4>
|
|
|
|
###$ unix <Alt-Key-4>
|
|
|
|
|
|
|
|
###$ event <<tabify-region>>
|
|
|
|
###$ win <Alt-Key-5>
|
|
|
|
###$ unix <Alt-Key-5>
|
|
|
|
|
|
|
|
###$ event <<untabify-region>>
|
|
|
|
###$ win <Alt-Key-6>
|
|
|
|
###$ unix <Alt-Key-6>
|
1998-10-10 15:48:31 -03:00
|
|
|
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
import PyParse
|
|
|
|
|
1998-10-10 15:48:31 -03:00
|
|
|
class AutoIndent:
|
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
menudefs = [
|
|
|
|
('edit', [
|
|
|
|
None,
|
|
|
|
('_Indent region', '<<indent-region>>'),
|
|
|
|
('_Dedent region', '<<dedent-region>>'),
|
|
|
|
('Comment _out region', '<<comment-region>>'),
|
|
|
|
('U_ncomment region', '<<uncomment-region>>'),
|
|
|
|
('Tabify region', '<<tabify-region>>'),
|
|
|
|
('Untabify region', '<<untabify-region>>'),
|
1999-05-21 01:38:27 -03:00
|
|
|
('Toggle tabs', '<<toggle-tabs>>'),
|
|
|
|
('New indent width', '<<change-indentwidth>>'),
|
1999-01-02 17:28:54 -04:00
|
|
|
]),
|
|
|
|
]
|
|
|
|
|
1999-01-02 20:47:35 -04:00
|
|
|
keydefs = {
|
|
|
|
'<<smart-backspace>>': ['<Key-BackSpace>'],
|
1999-01-02 17:28:54 -04:00
|
|
|
'<<newline-and-indent>>': ['<Key-Return>', '<KP_Enter>'],
|
1999-04-19 13:23:15 -03:00
|
|
|
'<<smart-indent>>': ['<Key-Tab>']
|
1999-01-02 20:47:35 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
windows_keydefs = {
|
1999-01-02 17:28:54 -04:00
|
|
|
'<<indent-region>>': ['<Control-bracketright>'],
|
|
|
|
'<<dedent-region>>': ['<Control-bracketleft>'],
|
|
|
|
'<<comment-region>>': ['<Alt-Key-3>'],
|
|
|
|
'<<uncomment-region>>': ['<Alt-Key-4>'],
|
|
|
|
'<<tabify-region>>': ['<Alt-Key-5>'],
|
|
|
|
'<<untabify-region>>': ['<Alt-Key-6>'],
|
1999-05-21 01:38:27 -03:00
|
|
|
'<<toggle-tabs>>': ['<Alt-Key-t>'],
|
1999-06-01 16:47:56 -03:00
|
|
|
'<<change-indentwidth>>': ['<Alt-Key-u>'],
|
1999-01-02 17:28:54 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
unix_keydefs = {
|
|
|
|
'<<indent-region>>': ['<Alt-bracketright>',
|
|
|
|
'<Meta-bracketright>',
|
|
|
|
'<Control-bracketright>'],
|
|
|
|
'<<dedent-region>>': ['<Alt-bracketleft>',
|
|
|
|
'<Meta-bracketleft>',
|
|
|
|
'<Control-bracketleft>'],
|
|
|
|
'<<comment-region>>': ['<Alt-Key-3>', '<Meta-Key-3>'],
|
|
|
|
'<<uncomment-region>>': ['<Alt-Key-4>', '<Meta-Key-4>'],
|
|
|
|
'<<tabify-region>>': ['<Alt-Key-5>', '<Meta-Key-5>'],
|
|
|
|
'<<untabify-region>>': ['<Alt-Key-6>', '<Meta-Key-6>'],
|
1999-06-01 17:06:44 -03:00
|
|
|
'<<toggle-tabs>>': ['<Alt-Key-t>'],
|
|
|
|
'<<change-indentwidth>>': ['<Alt-Key-u>'],
|
1999-01-02 17:28:54 -04:00
|
|
|
}
|
|
|
|
|
1999-05-21 01:38:27 -03:00
|
|
|
# usetabs true -> literal tab characters are used by indent and
|
|
|
|
# dedent cmds, possibly mixed with spaces if
|
|
|
|
# indentwidth is not a multiple of tabwidth
|
|
|
|
# false -> tab characters are converted to spaces by indent
|
|
|
|
# and dedent cmds, and ditto TAB keystrokes
|
1999-06-01 16:47:56 -03:00
|
|
|
# indentwidth is the number of characters per logical indent level.
|
|
|
|
# tabwidth is the display width of a literal tab character.
|
|
|
|
# CAUTION: telling Tk to use anything other than its default
|
|
|
|
# tab setting causes it to use an entirely different tabbing algorithm,
|
|
|
|
# treating tab stops as fixed distances from the left margin.
|
|
|
|
# Nobody expects this, so for now tabwidth should never be changed.
|
1999-06-08 09:54:23 -03:00
|
|
|
usetabs = 1
|
1999-05-21 01:38:27 -03:00
|
|
|
indentwidth = 4
|
1999-06-11 12:03:00 -03:00
|
|
|
tabwidth = 8 # for IDLE use, must remain 8 until Tk is fixed
|
1999-01-02 17:28:54 -04:00
|
|
|
|
Tim Peters again:
The new version (attached) is fast enough all the time in every real module
I have <whew!>. You can make it slow by, e.g., creating an open list with
5,000 90-character identifiers (+ trailing comma) each on its own line, then
adding an item to the end -- but that still consumes less than a second on
my P5-166. Response time in real code appears instantaneous.
Fixed some bugs.
New feature: when hitting ENTER and the cursor is beyond the line's leading
indentation, whitespace is removed on both sides of the cursor; before
whitespace was removed only on the left; e.g., assuming the cursor is
between the comma and the space:
def something(arg1, arg2):
^ cursor to the left of here, and hit ENTER
arg2): # new line used to end up here
arg2): # but now lines up the way you expect
New hack: AutoIndent has grown a context_use_ps1 Boolean config option,
defaulting to 0 (false) and set to 1 (only) by PyShell. Reason: handling
the fancy stuff requires looking backward for a parsing synch point; ps1
lines are the only sensible thing to look for in a shell window, but are a
bad thing to look for in a file window (ps1 lines show up in my module
docstrings often). PythonWin's shell should set this true too.
Persistent problem: strings containing def/class can still screw things up
completely. No improvement. Simplest workaround is on the user's head, and
consists of inserting e.g.
def _(): pass
(or any other def/class) after the end of the multiline string that's
screwing them up. This is especially irksome because IDLE's syntax coloring
is *not* confused, so when this happens the colors don't match the
indentation behavior they see.
1999-06-01 16:55:34 -03:00
|
|
|
# If context_use_ps1 is true, parsing searches back for a ps1 line;
|
1999-06-03 11:32:16 -03:00
|
|
|
# else searches for a popular (if, def, ...) Python stmt.
|
Tim Peters again:
The new version (attached) is fast enough all the time in every real module
I have <whew!>. You can make it slow by, e.g., creating an open list with
5,000 90-character identifiers (+ trailing comma) each on its own line, then
adding an item to the end -- but that still consumes less than a second on
my P5-166. Response time in real code appears instantaneous.
Fixed some bugs.
New feature: when hitting ENTER and the cursor is beyond the line's leading
indentation, whitespace is removed on both sides of the cursor; before
whitespace was removed only on the left; e.g., assuming the cursor is
between the comma and the space:
def something(arg1, arg2):
^ cursor to the left of here, and hit ENTER
arg2): # new line used to end up here
arg2): # but now lines up the way you expect
New hack: AutoIndent has grown a context_use_ps1 Boolean config option,
defaulting to 0 (false) and set to 1 (only) by PyShell. Reason: handling
the fancy stuff requires looking backward for a parsing synch point; ps1
lines are the only sensible thing to look for in a shell window, but are a
bad thing to look for in a file window (ps1 lines show up in my module
docstrings often). PythonWin's shell should set this true too.
Persistent problem: strings containing def/class can still screw things up
completely. No improvement. Simplest workaround is on the user's head, and
consists of inserting e.g.
def _(): pass
(or any other def/class) after the end of the multiline string that's
screwing them up. This is especially irksome because IDLE's syntax coloring
is *not* confused, so when this happens the colors don't match the
indentation behavior they see.
1999-06-01 16:55:34 -03:00
|
|
|
context_use_ps1 = 0
|
|
|
|
|
1999-06-03 11:32:16 -03:00
|
|
|
# When searching backwards for a reliable place to begin parsing,
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
# first start num_context_lines[0] lines back, then
|
|
|
|
# num_context_lines[1] lines back if that didn't work, and so on.
|
|
|
|
# The last value should be huge (larger than the # of lines in a
|
|
|
|
# conceivable file).
|
|
|
|
# Making the initial values larger slows things down more often.
|
|
|
|
num_context_lines = 50, 500, 5000000
|
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def __init__(self, editwin):
|
1999-06-02 08:05:19 -03:00
|
|
|
self.editwin = editwin
|
1999-01-02 17:28:54 -04:00
|
|
|
self.text = editwin.text
|
1998-10-10 15:48:31 -03:00
|
|
|
|
|
|
|
def config(self, **options):
|
|
|
|
for key, value in options.items():
|
1999-05-21 01:38:27 -03:00
|
|
|
if key == 'usetabs':
|
|
|
|
self.usetabs = value
|
|
|
|
elif key == 'indentwidth':
|
|
|
|
self.indentwidth = value
|
|
|
|
elif key == 'tabwidth':
|
|
|
|
self.tabwidth = value
|
Tim Peters again:
The new version (attached) is fast enough all the time in every real module
I have <whew!>. You can make it slow by, e.g., creating an open list with
5,000 90-character identifiers (+ trailing comma) each on its own line, then
adding an item to the end -- but that still consumes less than a second on
my P5-166. Response time in real code appears instantaneous.
Fixed some bugs.
New feature: when hitting ENTER and the cursor is beyond the line's leading
indentation, whitespace is removed on both sides of the cursor; before
whitespace was removed only on the left; e.g., assuming the cursor is
between the comma and the space:
def something(arg1, arg2):
^ cursor to the left of here, and hit ENTER
arg2): # new line used to end up here
arg2): # but now lines up the way you expect
New hack: AutoIndent has grown a context_use_ps1 Boolean config option,
defaulting to 0 (false) and set to 1 (only) by PyShell. Reason: handling
the fancy stuff requires looking backward for a parsing synch point; ps1
lines are the only sensible thing to look for in a shell window, but are a
bad thing to look for in a file window (ps1 lines show up in my module
docstrings often). PythonWin's shell should set this true too.
Persistent problem: strings containing def/class can still screw things up
completely. No improvement. Simplest workaround is on the user's head, and
consists of inserting e.g.
def _(): pass
(or any other def/class) after the end of the multiline string that's
screwing them up. This is especially irksome because IDLE's syntax coloring
is *not* confused, so when this happens the colors don't match the
indentation behavior they see.
1999-06-01 16:55:34 -03:00
|
|
|
elif key == 'context_use_ps1':
|
|
|
|
self.context_use_ps1 = value
|
1998-10-10 15:48:31 -03:00
|
|
|
else:
|
|
|
|
raise KeyError, "bad option name: %s" % `key`
|
|
|
|
|
1999-05-21 01:38:27 -03:00
|
|
|
# If ispythonsource and guess are true, guess a good value for
|
|
|
|
# indentwidth based on file content (if possible), and if
|
|
|
|
# indentwidth != tabwidth set usetabs false.
|
|
|
|
# In any case, adjust the Text widget's view of what a tab
|
|
|
|
# character means.
|
|
|
|
|
|
|
|
def set_indentation_params(self, ispythonsource, guess=1):
|
|
|
|
if guess and ispythonsource:
|
|
|
|
i = self.guess_indent()
|
|
|
|
if 2 <= i <= 8:
|
|
|
|
self.indentwidth = i
|
|
|
|
if self.indentwidth != self.tabwidth:
|
|
|
|
self.usetabs = 0
|
|
|
|
|
1999-06-11 12:03:00 -03:00
|
|
|
self.editwin.set_tabwidth(self.tabwidth)
|
1999-05-21 01:38:27 -03:00
|
|
|
|
1999-01-02 20:47:35 -04:00
|
|
|
def smart_backspace_event(self, event):
|
|
|
|
text = self.text
|
1999-06-11 12:03:00 -03:00
|
|
|
first, last = self.editwin.get_selection_indices()
|
1999-01-02 20:47:35 -04:00
|
|
|
if first and last:
|
|
|
|
text.delete(first, last)
|
|
|
|
text.mark_set("insert", first)
|
|
|
|
return "break"
|
1999-06-11 12:03:00 -03:00
|
|
|
# Delete whitespace left, until hitting a real char or closest
|
|
|
|
# preceding virtual tab stop.
|
1999-01-02 20:47:35 -04:00
|
|
|
chars = text.get("insert linestart", "insert")
|
1999-06-11 12:03:00 -03:00
|
|
|
if chars == '':
|
|
|
|
if text.compare("insert", ">", "1.0"):
|
|
|
|
# easy: delete preceding newline
|
|
|
|
text.delete("insert-1c")
|
|
|
|
else:
|
|
|
|
text.bell() # at start of buffer
|
|
|
|
return "break"
|
|
|
|
if chars[-1] not in " \t":
|
|
|
|
# easy: delete preceding real char
|
|
|
|
text.delete("insert-1c")
|
|
|
|
return "break"
|
|
|
|
# Ick. It may require *inserting* spaces if we back up over a
|
|
|
|
# tab character! This is written to be clear, not fast.
|
|
|
|
expand, tabwidth = string.expandtabs, self.tabwidth
|
|
|
|
have = len(expand(chars, tabwidth))
|
|
|
|
assert have > 0
|
|
|
|
want = int((have - 1) / self.indentwidth) * self.indentwidth
|
|
|
|
ncharsdeleted = 0
|
|
|
|
while 1:
|
|
|
|
chars = chars[:-1]
|
|
|
|
ncharsdeleted = ncharsdeleted + 1
|
|
|
|
have = len(expand(chars, tabwidth))
|
|
|
|
if have <= want or chars[-1] not in " \t":
|
|
|
|
break
|
|
|
|
text.undo_block_start()
|
|
|
|
text.delete("insert-%dc" % ncharsdeleted, "insert")
|
|
|
|
if have < want:
|
|
|
|
text.insert("insert", ' ' * (want - have))
|
|
|
|
text.undo_block_stop()
|
1999-01-02 20:47:35 -04:00
|
|
|
return "break"
|
|
|
|
|
1999-04-19 13:23:15 -03:00
|
|
|
def smart_indent_event(self, event):
|
|
|
|
# if intraline selection:
|
|
|
|
# delete it
|
|
|
|
# elif multiline selection:
|
|
|
|
# do indent-region & return
|
1999-05-21 01:38:27 -03:00
|
|
|
# indent one level
|
1999-04-19 13:23:15 -03:00
|
|
|
text = self.text
|
1999-06-11 12:03:00 -03:00
|
|
|
first, last = self.editwin.get_selection_indices()
|
1999-05-03 12:49:52 -03:00
|
|
|
text.undo_block_start()
|
|
|
|
try:
|
|
|
|
if first and last:
|
|
|
|
if index2line(first) != index2line(last):
|
|
|
|
return self.indent_region_event(event)
|
|
|
|
text.delete(first, last)
|
|
|
|
text.mark_set("insert", first)
|
1999-05-21 01:38:27 -03:00
|
|
|
prefix = text.get("insert linestart", "insert")
|
|
|
|
raw, effective = classifyws(prefix, self.tabwidth)
|
|
|
|
if raw == len(prefix):
|
|
|
|
# only whitespace to the left
|
|
|
|
self.reindent_to(effective + self.indentwidth)
|
1999-05-03 12:49:52 -03:00
|
|
|
else:
|
1999-05-21 01:38:27 -03:00
|
|
|
if self.usetabs:
|
|
|
|
pad = '\t'
|
|
|
|
else:
|
|
|
|
effective = len(string.expandtabs(prefix,
|
|
|
|
self.tabwidth))
|
|
|
|
n = self.indentwidth
|
|
|
|
pad = ' ' * (n - effective % n)
|
|
|
|
text.insert("insert", pad)
|
1999-05-03 12:49:52 -03:00
|
|
|
text.see("insert")
|
|
|
|
return "break"
|
|
|
|
finally:
|
|
|
|
text.undo_block_stop()
|
1999-04-19 13:23:15 -03:00
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def newline_and_indent_event(self, event):
|
1998-10-10 15:48:31 -03:00
|
|
|
text = self.text
|
1999-06-11 12:03:00 -03:00
|
|
|
first, last = self.editwin.get_selection_indices()
|
1999-05-03 12:49:52 -03:00
|
|
|
text.undo_block_start()
|
|
|
|
try:
|
|
|
|
if first and last:
|
|
|
|
text.delete(first, last)
|
|
|
|
text.mark_set("insert", first)
|
|
|
|
line = text.get("insert linestart", "insert")
|
|
|
|
i, n = 0, len(line)
|
|
|
|
while i < n and line[i] in " \t":
|
|
|
|
i = i+1
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
if i == n:
|
|
|
|
# the cursor is in or at leading indentation; just inject
|
|
|
|
# an empty line at the start
|
|
|
|
text.insert("insert linestart", '\n')
|
|
|
|
return "break"
|
1999-05-03 12:49:52 -03:00
|
|
|
indent = line[:i]
|
Tim Peters again:
The new version (attached) is fast enough all the time in every real module
I have <whew!>. You can make it slow by, e.g., creating an open list with
5,000 90-character identifiers (+ trailing comma) each on its own line, then
adding an item to the end -- but that still consumes less than a second on
my P5-166. Response time in real code appears instantaneous.
Fixed some bugs.
New feature: when hitting ENTER and the cursor is beyond the line's leading
indentation, whitespace is removed on both sides of the cursor; before
whitespace was removed only on the left; e.g., assuming the cursor is
between the comma and the space:
def something(arg1, arg2):
^ cursor to the left of here, and hit ENTER
arg2): # new line used to end up here
arg2): # but now lines up the way you expect
New hack: AutoIndent has grown a context_use_ps1 Boolean config option,
defaulting to 0 (false) and set to 1 (only) by PyShell. Reason: handling
the fancy stuff requires looking backward for a parsing synch point; ps1
lines are the only sensible thing to look for in a shell window, but are a
bad thing to look for in a file window (ps1 lines show up in my module
docstrings often). PythonWin's shell should set this true too.
Persistent problem: strings containing def/class can still screw things up
completely. No improvement. Simplest workaround is on the user's head, and
consists of inserting e.g.
def _(): pass
(or any other def/class) after the end of the multiline string that's
screwing them up. This is especially irksome because IDLE's syntax coloring
is *not* confused, so when this happens the colors don't match the
indentation behavior they see.
1999-06-01 16:55:34 -03:00
|
|
|
# strip whitespace before insert point
|
1999-05-03 12:49:52 -03:00
|
|
|
i = 0
|
|
|
|
while line and line[-1] in " \t":
|
|
|
|
line = line[:-1]
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
i = i+1
|
1999-05-03 12:49:52 -03:00
|
|
|
if i:
|
|
|
|
text.delete("insert - %d chars" % i, "insert")
|
Tim Peters again:
The new version (attached) is fast enough all the time in every real module
I have <whew!>. You can make it slow by, e.g., creating an open list with
5,000 90-character identifiers (+ trailing comma) each on its own line, then
adding an item to the end -- but that still consumes less than a second on
my P5-166. Response time in real code appears instantaneous.
Fixed some bugs.
New feature: when hitting ENTER and the cursor is beyond the line's leading
indentation, whitespace is removed on both sides of the cursor; before
whitespace was removed only on the left; e.g., assuming the cursor is
between the comma and the space:
def something(arg1, arg2):
^ cursor to the left of here, and hit ENTER
arg2): # new line used to end up here
arg2): # but now lines up the way you expect
New hack: AutoIndent has grown a context_use_ps1 Boolean config option,
defaulting to 0 (false) and set to 1 (only) by PyShell. Reason: handling
the fancy stuff requires looking backward for a parsing synch point; ps1
lines are the only sensible thing to look for in a shell window, but are a
bad thing to look for in a file window (ps1 lines show up in my module
docstrings often). PythonWin's shell should set this true too.
Persistent problem: strings containing def/class can still screw things up
completely. No improvement. Simplest workaround is on the user's head, and
consists of inserting e.g.
def _(): pass
(or any other def/class) after the end of the multiline string that's
screwing them up. This is especially irksome because IDLE's syntax coloring
is *not* confused, so when this happens the colors don't match the
indentation behavior they see.
1999-06-01 16:55:34 -03:00
|
|
|
# strip whitespace after insert point
|
|
|
|
while text.get("insert") in " \t":
|
|
|
|
text.delete("insert")
|
|
|
|
# start new line
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
text.insert("insert", '\n')
|
1999-06-03 11:32:16 -03:00
|
|
|
|
1999-06-11 12:03:00 -03:00
|
|
|
# adjust indentation for continuations and block
|
|
|
|
# open/close first need to find the last stmt
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
lno = index2line(text.index('insert'))
|
|
|
|
y = PyParse.Parser(self.indentwidth, self.tabwidth)
|
|
|
|
for context in self.num_context_lines:
|
|
|
|
startat = max(lno - context, 1)
|
1999-06-03 11:32:16 -03:00
|
|
|
startatindex = `startat` + ".0"
|
|
|
|
rawtext = text.get(startatindex, "insert")
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
y.set_str(rawtext)
|
1999-06-03 11:32:16 -03:00
|
|
|
bod = y.find_good_parse_start(
|
|
|
|
self.context_use_ps1,
|
|
|
|
self._build_char_in_string_func(startatindex))
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
if bod is not None or startat == 1:
|
|
|
|
break
|
|
|
|
y.set_lo(bod or 0)
|
|
|
|
c = y.get_continuation_type()
|
|
|
|
if c != PyParse.C_NONE:
|
|
|
|
# The current stmt hasn't ended yet.
|
|
|
|
if c == PyParse.C_STRING:
|
|
|
|
# inside a string; just mimic the current indent
|
|
|
|
text.insert("insert", indent)
|
|
|
|
elif c == PyParse.C_BRACKET:
|
|
|
|
# line up with the first (if any) element of the
|
|
|
|
# last open bracket structure; else indent one
|
1999-06-11 12:03:00 -03:00
|
|
|
# level beyond the indent of the line with the
|
|
|
|
# last open bracket
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
self.reindent_to(y.compute_bracket_indent())
|
|
|
|
elif c == PyParse.C_BACKSLASH:
|
|
|
|
# if more than one line in this stmt already, just
|
1999-06-11 12:03:00 -03:00
|
|
|
# mimic the current indent; else if initial line
|
|
|
|
# has a start on an assignment stmt, indent to
|
|
|
|
# beyond leftmost =; else to beyond first chunk of
|
|
|
|
# non-whitespace on initial line
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
if y.get_num_lines_in_stmt() > 1:
|
|
|
|
text.insert("insert", indent)
|
|
|
|
else:
|
|
|
|
self.reindent_to(y.compute_backslash_indent())
|
1999-06-01 16:47:56 -03:00
|
|
|
else:
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
assert 0, "bogus continuation type " + `c`
|
|
|
|
return "break"
|
|
|
|
|
|
|
|
# This line starts a brand new stmt; indent relative to
|
1999-06-11 12:03:00 -03:00
|
|
|
# indentation of initial line of closest preceding
|
|
|
|
# interesting stmt.
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
indent = y.get_base_indent_string()
|
|
|
|
text.insert("insert", indent)
|
|
|
|
if y.is_block_opener():
|
|
|
|
self.smart_indent_event(event)
|
|
|
|
elif indent and y.is_block_closer():
|
1999-05-03 12:49:52 -03:00
|
|
|
self.smart_backspace_event(event)
|
|
|
|
return "break"
|
|
|
|
finally:
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
text.see("insert")
|
1999-05-03 12:49:52 -03:00
|
|
|
text.undo_block_stop()
|
1998-10-10 15:48:31 -03:00
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
auto_indent = newline_and_indent_event
|
|
|
|
|
1999-06-11 12:03:00 -03:00
|
|
|
# Our editwin provides a is_char_in_string function that works
|
|
|
|
# with a Tk text index, but PyParse only knows about offsets into
|
|
|
|
# a string. This builds a function for PyParse that accepts an
|
|
|
|
# offset.
|
1999-06-03 11:32:16 -03:00
|
|
|
|
|
|
|
def _build_char_in_string_func(self, startindex):
|
|
|
|
def inner(offset, _startindex=startindex,
|
|
|
|
_icis=self.editwin.is_char_in_string):
|
|
|
|
return _icis(_startindex + "+%dc" % offset)
|
|
|
|
return inner
|
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def indent_region_event(self, event):
|
|
|
|
head, tail, chars, lines = self.get_region()
|
1998-10-10 15:48:31 -03:00
|
|
|
for pos in range(len(lines)):
|
|
|
|
line = lines[pos]
|
|
|
|
if line:
|
1999-05-21 01:38:27 -03:00
|
|
|
raw, effective = classifyws(line, self.tabwidth)
|
|
|
|
effective = effective + self.indentwidth
|
|
|
|
lines[pos] = self._make_blanks(effective) + line[raw:]
|
1999-01-02 17:28:54 -04:00
|
|
|
self.set_region(head, tail, chars, lines)
|
1998-10-10 15:48:31 -03:00
|
|
|
return "break"
|
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def dedent_region_event(self, event):
|
|
|
|
head, tail, chars, lines = self.get_region()
|
1998-10-10 15:48:31 -03:00
|
|
|
for pos in range(len(lines)):
|
|
|
|
line = lines[pos]
|
|
|
|
if line:
|
1999-05-21 01:38:27 -03:00
|
|
|
raw, effective = classifyws(line, self.tabwidth)
|
|
|
|
effective = max(effective - self.indentwidth, 0)
|
|
|
|
lines[pos] = self._make_blanks(effective) + line[raw:]
|
1999-01-02 17:28:54 -04:00
|
|
|
self.set_region(head, tail, chars, lines)
|
1998-10-10 15:48:31 -03:00
|
|
|
return "break"
|
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def comment_region_event(self, event):
|
|
|
|
head, tail, chars, lines = self.get_region()
|
1999-06-10 11:44:48 -03:00
|
|
|
for pos in range(len(lines) - 1):
|
1998-10-10 15:48:31 -03:00
|
|
|
line = lines[pos]
|
1999-06-08 09:54:23 -03:00
|
|
|
lines[pos] = '##' + line
|
1999-01-02 17:28:54 -04:00
|
|
|
self.set_region(head, tail, chars, lines)
|
1998-10-10 15:48:31 -03:00
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def uncomment_region_event(self, event):
|
|
|
|
head, tail, chars, lines = self.get_region()
|
1998-10-10 15:48:31 -03:00
|
|
|
for pos in range(len(lines)):
|
|
|
|
line = lines[pos]
|
|
|
|
if not line:
|
|
|
|
continue
|
|
|
|
if line[:2] == '##':
|
|
|
|
line = line[2:]
|
|
|
|
elif line[:1] == '#':
|
|
|
|
line = line[1:]
|
|
|
|
lines[pos] = line
|
1999-01-02 17:28:54 -04:00
|
|
|
self.set_region(head, tail, chars, lines)
|
1998-10-10 15:48:31 -03:00
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def tabify_region_event(self, event):
|
|
|
|
head, tail, chars, lines = self.get_region()
|
1999-06-01 16:47:56 -03:00
|
|
|
tabwidth = self._asktabwidth()
|
1999-05-21 01:38:27 -03:00
|
|
|
for pos in range(len(lines)):
|
|
|
|
line = lines[pos]
|
|
|
|
if line:
|
1999-06-01 16:47:56 -03:00
|
|
|
raw, effective = classifyws(line, tabwidth)
|
|
|
|
ntabs, nspaces = divmod(effective, tabwidth)
|
1999-05-21 01:38:27 -03:00
|
|
|
lines[pos] = '\t' * ntabs + ' ' * nspaces + line[raw:]
|
1999-01-02 17:28:54 -04:00
|
|
|
self.set_region(head, tail, chars, lines)
|
|
|
|
|
|
|
|
def untabify_region_event(self, event):
|
|
|
|
head, tail, chars, lines = self.get_region()
|
1999-06-01 16:47:56 -03:00
|
|
|
tabwidth = self._asktabwidth()
|
1999-05-21 01:38:27 -03:00
|
|
|
for pos in range(len(lines)):
|
1999-06-01 16:47:56 -03:00
|
|
|
lines[pos] = string.expandtabs(lines[pos], tabwidth)
|
1999-01-02 17:28:54 -04:00
|
|
|
self.set_region(head, tail, chars, lines)
|
|
|
|
|
1999-05-21 01:38:27 -03:00
|
|
|
def toggle_tabs_event(self, event):
|
1999-06-02 08:05:19 -03:00
|
|
|
if self.editwin.askyesno(
|
1999-06-01 16:47:56 -03:00
|
|
|
"Toggle tabs",
|
1999-05-21 01:38:27 -03:00
|
|
|
"Turn tabs " + ("on", "off")[self.usetabs] + "?",
|
|
|
|
parent=self.text):
|
|
|
|
self.usetabs = not self.usetabs
|
|
|
|
return "break"
|
|
|
|
|
1999-06-01 16:47:56 -03:00
|
|
|
# XXX this isn't bound to anything -- see class tabwidth comments
|
1999-05-21 01:38:27 -03:00
|
|
|
def change_tabwidth_event(self, event):
|
1999-06-01 16:47:56 -03:00
|
|
|
new = self._asktabwidth()
|
|
|
|
if new != self.tabwidth:
|
1999-05-21 01:38:27 -03:00
|
|
|
self.tabwidth = new
|
|
|
|
self.set_indentation_params(0, guess=0)
|
|
|
|
return "break"
|
|
|
|
|
|
|
|
def change_indentwidth_event(self, event):
|
1999-06-02 08:05:19 -03:00
|
|
|
new = self.editwin.askinteger(
|
1999-06-01 16:47:56 -03:00
|
|
|
"Indent width",
|
|
|
|
"New indent width (1-16)",
|
|
|
|
parent=self.text,
|
|
|
|
initialvalue=self.indentwidth,
|
|
|
|
minvalue=1,
|
|
|
|
maxvalue=16)
|
1999-05-21 01:38:27 -03:00
|
|
|
if new and new != self.indentwidth:
|
|
|
|
self.indentwidth = new
|
|
|
|
return "break"
|
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def get_region(self):
|
1998-10-10 15:48:31 -03:00
|
|
|
text = self.text
|
1999-06-11 12:03:00 -03:00
|
|
|
first, last = self.editwin.get_selection_indices()
|
|
|
|
if first and last:
|
|
|
|
head = text.index(first + " linestart")
|
|
|
|
tail = text.index(last + "-1c lineend +1c")
|
|
|
|
else:
|
1998-10-10 15:48:31 -03:00
|
|
|
head = text.index("insert linestart")
|
|
|
|
tail = text.index("insert lineend +1c")
|
|
|
|
chars = text.get(head, tail)
|
|
|
|
lines = string.split(chars, "\n")
|
|
|
|
return head, tail, chars, lines
|
|
|
|
|
1999-01-02 17:28:54 -04:00
|
|
|
def set_region(self, head, tail, chars, lines):
|
1998-10-10 15:48:31 -03:00
|
|
|
text = self.text
|
|
|
|
newchars = string.join(lines, "\n")
|
|
|
|
if newchars == chars:
|
|
|
|
text.bell()
|
|
|
|
return
|
|
|
|
text.tag_remove("sel", "1.0", "end")
|
|
|
|
text.mark_set("insert", head)
|
1999-05-03 12:49:52 -03:00
|
|
|
text.undo_block_start()
|
1998-10-10 15:48:31 -03:00
|
|
|
text.delete(head, tail)
|
|
|
|
text.insert(head, newchars)
|
1999-05-03 12:49:52 -03:00
|
|
|
text.undo_block_stop()
|
1998-10-10 15:48:31 -03:00
|
|
|
text.tag_add("sel", head, "insert")
|
1999-01-02 17:28:54 -04:00
|
|
|
|
1999-05-21 01:38:27 -03:00
|
|
|
# Make string that displays as n leading blanks.
|
|
|
|
|
|
|
|
def _make_blanks(self, n):
|
|
|
|
if self.usetabs:
|
|
|
|
ntabs, nspaces = divmod(n, self.tabwidth)
|
|
|
|
return '\t' * ntabs + ' ' * nspaces
|
|
|
|
else:
|
|
|
|
return ' ' * n
|
|
|
|
|
|
|
|
# Delete from beginning of line to insert point, then reinsert
|
|
|
|
# column logical (meaning use tabs if appropriate) spaces.
|
|
|
|
|
|
|
|
def reindent_to(self, column):
|
|
|
|
text = self.text
|
|
|
|
text.undo_block_start()
|
Tim Peters again:
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
1999-06-01 16:52:34 -03:00
|
|
|
if text.compare("insert linestart", "!=", "insert"):
|
|
|
|
text.delete("insert linestart", "insert")
|
1999-05-21 01:38:27 -03:00
|
|
|
if column:
|
|
|
|
text.insert("insert", self._make_blanks(column))
|
|
|
|
text.undo_block_stop()
|
|
|
|
|
1999-06-01 16:47:56 -03:00
|
|
|
def _asktabwidth(self):
|
1999-06-02 08:05:19 -03:00
|
|
|
return self.editwin.askinteger(
|
1999-06-01 16:47:56 -03:00
|
|
|
"Tab width",
|
|
|
|
"Spaces per tab?",
|
|
|
|
parent=self.text,
|
|
|
|
initialvalue=self.tabwidth,
|
|
|
|
minvalue=1,
|
|
|
|
maxvalue=16) or self.tabwidth
|
|
|
|
|
1999-05-21 01:38:27 -03:00
|
|
|
# Guess indentwidth from text content.
|
|
|
|
# Return guessed indentwidth. This should not be believed unless
|
|
|
|
# it's in a reasonable range (e.g., it will be 0 if no indented
|
|
|
|
# blocks are found).
|
|
|
|
|
|
|
|
def guess_indent(self):
|
|
|
|
opener, indented = IndentSearcher(self.text, self.tabwidth).run()
|
|
|
|
if opener and indented:
|
|
|
|
raw, indentsmall = classifyws(opener, self.tabwidth)
|
|
|
|
raw, indentlarge = classifyws(indented, self.tabwidth)
|
|
|
|
else:
|
|
|
|
indentsmall = indentlarge = 0
|
|
|
|
return indentlarge - indentsmall
|
1999-04-19 13:23:15 -03:00
|
|
|
|
|
|
|
# "line.col" -> line, as an int
|
|
|
|
def index2line(index):
|
|
|
|
return int(float(index))
|
1999-05-21 01:38:27 -03:00
|
|
|
|
|
|
|
# Look at the leading whitespace in s.
|
|
|
|
# Return pair (# of leading ws characters,
|
|
|
|
# effective # of leading blanks after expanding
|
|
|
|
# tabs to width tabwidth)
|
|
|
|
|
|
|
|
def classifyws(s, tabwidth):
|
|
|
|
raw = effective = 0
|
|
|
|
for ch in s:
|
|
|
|
if ch == ' ':
|
|
|
|
raw = raw + 1
|
|
|
|
effective = effective + 1
|
|
|
|
elif ch == '\t':
|
|
|
|
raw = raw + 1
|
|
|
|
effective = (effective / tabwidth + 1) * tabwidth
|
|
|
|
else:
|
|
|
|
break
|
|
|
|
return raw, effective
|
|
|
|
|
|
|
|
import tokenize
|
|
|
|
_tokenize = tokenize
|
|
|
|
del tokenize
|
|
|
|
|
|
|
|
class IndentSearcher:
|
|
|
|
|
|
|
|
# .run() chews over the Text widget, looking for a block opener
|
|
|
|
# and the stmt following it. Returns a pair,
|
|
|
|
# (line containing block opener, line containing stmt)
|
|
|
|
# Either or both may be None.
|
|
|
|
|
|
|
|
def __init__(self, text, tabwidth):
|
|
|
|
self.text = text
|
|
|
|
self.tabwidth = tabwidth
|
|
|
|
self.i = self.finished = 0
|
|
|
|
self.blkopenline = self.indentedline = None
|
|
|
|
|
|
|
|
def readline(self):
|
|
|
|
if self.finished:
|
|
|
|
return ""
|
|
|
|
i = self.i = self.i + 1
|
|
|
|
mark = `i` + ".0"
|
|
|
|
if self.text.compare(mark, ">=", "end"):
|
|
|
|
return ""
|
|
|
|
return self.text.get(mark, mark + " lineend+1c")
|
|
|
|
|
|
|
|
def tokeneater(self, type, token, start, end, line,
|
|
|
|
INDENT=_tokenize.INDENT,
|
|
|
|
NAME=_tokenize.NAME,
|
|
|
|
OPENERS=('class', 'def', 'for', 'if', 'try', 'while')):
|
|
|
|
if self.finished:
|
|
|
|
pass
|
|
|
|
elif type == NAME and token in OPENERS:
|
|
|
|
self.blkopenline = line
|
|
|
|
elif type == INDENT and self.blkopenline:
|
|
|
|
self.indentedline = line
|
|
|
|
self.finished = 1
|
|
|
|
|
|
|
|
def run(self):
|
|
|
|
save_tabsize = _tokenize.tabsize
|
|
|
|
_tokenize.tabsize = self.tabwidth
|
|
|
|
try:
|
|
|
|
try:
|
|
|
|
_tokenize.tokenize(self.readline, self.tokeneater)
|
|
|
|
except _tokenize.TokenError:
|
|
|
|
# since we cut off the tokenizer early, we can trigger
|
|
|
|
# spurious errors
|
|
|
|
pass
|
|
|
|
finally:
|
|
|
|
_tokenize.tabsize = save_tabsize
|
|
|
|
return self.blkopenline, self.indentedline
|