mirror of https://github.com/python/cpython.git
#initial stylistic rewrite
This commit is contained in:
Barry Warsaw
parent
3b0a5cdb23
commit
7b0f5681d8
|
|
@ -1,7 +1,40 @@
|
|||
;;; Major mode for editing Python programs, version 1.10
|
||||
;; by: Tim Peters <tim@ksr.com>
|
||||
;; after an original idea by: Michael A. Guravage
|
||||
;;; python-mode.el --- Major mode for editing Python programs
|
||||
|
||||
;; Copyright (C) 1992,1993,1994 Tim Peters
|
||||
|
||||
;; Author: 1995 Barry A. Warsaw <bwarsaw@cnri.reston.va.us>
|
||||
;; 1992-1994 Tim Peters <tim@ksr.com>
|
||||
;; Maintainer: bwarsaw@cnri.reston.va.us
|
||||
;; Created: ???
|
||||
;; Version: $Revision$
|
||||
;; Last Modified: $Date$
|
||||
;; Keywords: python editing language major-mode
|
||||
|
||||
;; This file is not part of GNU Emacs.
|
||||
|
||||
;; This program is free software; you can redistribute it and/or modify
|
||||
;; it under the terms of the GNU General Public License as published by
|
||||
;; the Free Software Foundation; either version 2 of the License, or
|
||||
;; (at your option) any later version.
|
||||
;;
|
||||
;; This program is distributed in the hope that it will be useful,
|
||||
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
;; GNU General Public License for more details.
|
||||
;;
|
||||
;; You should have received a copy of the GNU General Public License
|
||||
;; along with this program; if not, write to the Free Software
|
||||
;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
;;; Commentary:
|
||||
;;
|
||||
;; This is a major mode for editing Python programs. It was developed
|
||||
;; by Tim Peters <tim@ksr.com> after an original idea by Michael
|
||||
;; A. Guravage. Tim doesn't appear to be on the 'net any longer so I
|
||||
;; have undertaken maintenance of the mode. Here is Tim's original
|
||||
;; copyright notice:
|
||||
|
||||
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
||||
;; Copyright (c) 1992,1993,1994 Tim Peters
|
||||
;;
|
||||
;; This software is provided as-is, without express or implied warranty.
|
||||
|
|
@ -9,39 +42,54 @@
|
|||
;; without fee, for any purpose and by any individual or organization, is
|
||||
;; hereby granted, provided that the above copyright notice and this
|
||||
;; paragraph appear in all copies.
|
||||
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
||||
|
||||
;; At some point this mode will undergo a rewrite to bring it more in
|
||||
;; line with GNU Emacs Lisp coding standards. But all in all, the
|
||||
;; mode works exceedingly well.
|
||||
|
||||
;; The following statements, placed in your .emacs file or
|
||||
;; site-init.el, will cause this file to be autoloaded, and
|
||||
;; python-mode invoked, when visiting .py files (assuming this file is
|
||||
;; in your load-path):
|
||||
;;
|
||||
;;
|
||||
;; The following statements, placed in your .emacs file or site-init.el,
|
||||
;; will cause this file to be autoloaded, and python-mode invoked, when
|
||||
;; visiting .py files (assuming the file is in your load-path):
|
||||
;;
|
||||
;; (autoload 'python-mode "python-mode" "" t)
|
||||
;; (autoload 'python-mode "python-mode" "Python editing mode." t)
|
||||
;; (setq auto-mode-alist
|
||||
;; (cons '("\\.py$" . python-mode) auto-mode-alist))
|
||||
|
||||
(provide 'python-mode)
|
||||
;; Here's a brief to do list:
|
||||
;;
|
||||
;; 1. Better integration with gud-mode for debugging.
|
||||
;; 2. Rewrite according to GNU Emacs Lisp standards.
|
||||
|
||||
;;; Differentiate between Emacs 18, Lucid Emacs, and Emacs 19.
|
||||
;;; This seems to be the standard way of checking this.
|
||||
;; If you can think of more things you'd like to see, drop me a line.
|
||||
;; If you want to report bugs, use py-submit-bug-report (C-c C-b).
|
||||
;;
|
||||
;; Note that I only test things on XEmacs (currently 19.11). If you
|
||||
;; port stuff to FSF Emacs 19, or Emacs 18, please send me your
|
||||
;; patches.
|
||||
|
||||
(setq py-this-is-lucid-emacs-p (string-match "Lucid" emacs-version))
|
||||
(setq py-this-is-emacs-19-p
|
||||
(and
|
||||
(not py-this-is-lucid-emacs-p)
|
||||
(string-match "^19\\." emacs-version)))
|
||||
;; LCD Archive Entry:
|
||||
;; python-mode|Barry A. Warsaw|bwarsaw@cnri.reston.va.us
|
||||
;; |Major mode for editing Python programs
|
||||
;; |$Date$|$Revision$|
|
||||
|
||||
;;; Constants and variables
|
||||
;;; Code:
|
||||
|
||||
|
||||
;; user definable variables
|
||||
;; vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|
||||
|
||||
(defvar py-python-command "python"
|
||||
"*Shell command used to start Python interpreter.")
|
||||
|
||||
(defvar py-indent-offset 8 ; argue with Guido <grin>
|
||||
"*Indentation increment.
|
||||
Note that `\\[py-guess-indent-offset]' can usually guess a good value when you're
|
||||
editing someone else's Python code.")
|
||||
Note that `\\[py-guess-indent-offset]' can usually guess a good value
|
||||
when you're editing someone else's Python code.")
|
||||
|
||||
(defvar py-block-comment-prefix "##"
|
||||
"*String used by py-comment-region to comment out a block of code.
|
||||
"*String used by `py-comment-region' to comment out a block of code.
|
||||
This should follow the convention for non-indenting comment lines so
|
||||
that the indentation commands won't get confused (i.e., the string
|
||||
should be of the form `#x...' where `x' is not a blank or a tab, and
|
||||
|
|
@ -105,6 +153,34 @@ By default, the first directory from this list that exists and that you
|
|||
can write into: the value (if any) of the environment variable TMPDIR,
|
||||
/usr/tmp, /tmp, or the current directory.")
|
||||
|
||||
(defvar py-beep-if-tab-change t
|
||||
"*Ring the bell if tab-width is changed.
|
||||
If a comment of the form
|
||||
|
||||
\t# vi:set tabsize=<number>:
|
||||
|
||||
is found before the first code line when the file is entered, and the
|
||||
current value of (the general Emacs variable) `tab-width' does not
|
||||
equal <number>, `tab-width' is set to <number>, a message saying so is
|
||||
displayed in the echo area, and if `py-beep-if-tab-change' is non-nil
|
||||
the Emacs bell is also rung as a warning.")
|
||||
|
||||
|
||||
|
||||
;; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
;; NO USER DEFINABLE VARIABLES BEYOND THIS POINT
|
||||
|
||||
;; Differentiate between Emacs 18, Lucid Emacs, and Emacs 19. This
|
||||
;; seems to be the standard way of checking this.
|
||||
;; BAW - This is *not* the right solution. When at all possible,
|
||||
;; instead of testing for the version of Emacs, use feature tests.
|
||||
|
||||
(setq py-this-is-lucid-emacs-p (string-match "Lucid\\|XEmacs" emacs-version))
|
||||
(setq py-this-is-emacs-19-p
|
||||
(and
|
||||
(not py-this-is-lucid-emacs-p)
|
||||
(string-match "^19\\." emacs-version)))
|
||||
|
||||
;; have to bind py-file-queue before installing the kill-emacs hook
|
||||
(defvar py-file-queue nil
|
||||
"Queue of Python temp files awaiting execution.
|
||||
|
|
@ -112,49 +188,34 @@ Currently-active file is at the head of the list.")
|
|||
|
||||
;; define a mode-specific abbrev table for those who use such things
|
||||
(defvar python-mode-abbrev-table nil
|
||||
"Abbrev table in use in python-mode buffers.")
|
||||
"Abbrev table in use in `python-mode' buffers.")
|
||||
(define-abbrev-table 'python-mode-abbrev-table nil)
|
||||
|
||||
;; arrange to kill temp files no matter what
|
||||
(if (or py-this-is-emacs-19-p py-this-is-lucid-emacs-p)
|
||||
(add-hook 'kill-emacs-hook 'py-kill-emacs-hook)
|
||||
;; have to trust that other people are as respectful of our hook
|
||||
;; fiddling as we are of theirs
|
||||
(if (boundp 'py-inherited-kill-emacs-hook)
|
||||
;; we were loaded before -- trust others not to have screwed us
|
||||
;; in the meantime (no choice, really)
|
||||
nil
|
||||
;; else arrange for our hook to run theirs
|
||||
(setq py-inherited-kill-emacs-hook kill-emacs-hook)
|
||||
(setq kill-emacs-hook 'py-kill-emacs-hook)))
|
||||
|
||||
(defvar python-mode-hook nil
|
||||
"*Hook called by `python-mode'.")
|
||||
|
||||
;; in previous version of python-mode.el, the hook was incorrectly
|
||||
;; called py-mode-hook, and was not defvar'd. deprecate its use.
|
||||
(and (fboundp 'make-obsolete-variable)
|
||||
(make-obsolete-variable 'py-mode-hook 'python-mode-hook))
|
||||
|
||||
(defvar py-beep-if-tab-change t
|
||||
"*Ring the bell if tab-width is changed.
|
||||
If a comment of the form
|
||||
\t# vi:set tabsize=<number>:
|
||||
is found before the first code line when the file is entered, and
|
||||
the current value of (the general Emacs variable) tab-width does not
|
||||
equal <number>, tab-width is set to <number>, a message saying so is
|
||||
displayed in the echo area, and if py-beep-if-tab-change is non-nil the
|
||||
Emacs bell is also rung as a warning.")
|
||||
(defvar py-mode-map ()
|
||||
"Keymap used in `python-mode' buffers.")
|
||||
|
||||
(defvar py-mode-map nil "Keymap used in Python mode buffers.")
|
||||
(if py-mode-map
|
||||
()
|
||||
(setq py-mode-map (make-sparse-keymap))
|
||||
|
||||
;; shadow global bindings for newline-and-indent w/ the py- version
|
||||
;; shadow global bindings for newline-and-indent w/ the py- version.
|
||||
;; BAW - this is extremely bad form, but I'm not going to change it
|
||||
;; for now.
|
||||
(mapcar (function (lambda (key)
|
||||
(define-key
|
||||
py-mode-map key 'py-newline-and-indent)))
|
||||
(where-is-internal 'newline-and-indent))
|
||||
|
||||
;; BAW - you could do it this way, but its not considered proper
|
||||
;; major-mode form.
|
||||
(mapcar (function
|
||||
(lambda (x)
|
||||
(define-key py-mode-map (car x) (cdr x))))
|
||||
|
|
@ -178,10 +239,13 @@ Emacs bell is also rung as a warning.")
|
|||
("\e\C-e" . end-of-python-def-or-class)
|
||||
( "\e\C-h" . mark-python-def-or-class))))
|
||||
|
||||
(defvar py-mode-syntax-table nil "Python mode syntax table")
|
||||
(defvar py-mode-syntax-table nil
|
||||
"Syntax table used in `python-mode' buffers.")
|
||||
|
||||
(if py-mode-syntax-table
|
||||
()
|
||||
(setq py-mode-syntax-table (make-syntax-table))
|
||||
;; BAW - again, blech.
|
||||
(mapcar (function
|
||||
(lambda (x) (modify-syntax-entry
|
||||
(car x) (cdr x) py-mode-syntax-table)))
|
||||
|
|
@ -205,7 +269,7 @@ Emacs bell is also rung as a warning.")
|
|||
"'\\([^'\n\\]\\|\\\\.\\)*'" ; single-quoted
|
||||
"\\|" ; or
|
||||
"\"\\([^\"\n\\]\\|\\\\.\\)*\"") ; double-quoted
|
||||
"regexp matching a Python string literal")
|
||||
"Regexp matching a Python string literal.")
|
||||
|
||||
;; this is tricky because a trailing backslash does not mean
|
||||
;; continuation if it's in a comment
|
||||
|
|
@ -213,18 +277,23 @@ Emacs bell is also rung as a warning.")
|
|||
(concat
|
||||
"\\(" "[^#'\"\n\\]" "\\|" py-stringlit-re "\\)*"
|
||||
"\\\\$")
|
||||
"regexp matching Python lines that are continued via backslash")
|
||||
"Regexp matching Python lines that are continued via backslash.")
|
||||
|
||||
(defconst py-blank-or-comment-re "[ \t]*\\($\\|#\\)"
|
||||
"regexp matching blank or comment lines")
|
||||
"Regexp matching blank or comment lines.")
|
||||
|
||||
;;; General Functions
|
||||
|
||||
|
||||
;;;###autoload
|
||||
(defun python-mode ()
|
||||
"Major mode for editing Python files.
|
||||
Do `\\[py-describe-mode]' for detailed documentation.
|
||||
Knows about Python indentation, tokens, comments and continuation lines.
|
||||
Paragraphs are separated by blank lines only.
|
||||
To submit a problem report, enter `\\[py-submit-bug-report]' from a
|
||||
`python-mode' buffer. Do `\\[py-describe-mode]' for detailed
|
||||
documentation. To see what version of `python-mode' you are running,
|
||||
enter `\\[py-version]'.
|
||||
|
||||
This mode knows about Python indentation, tokens, comments and
|
||||
continuation lines. Paragraphs are separated by blank lines only.
|
||||
|
||||
COMMANDS
|
||||
\\{py-mode-map}
|
||||
|
|
@ -238,12 +307,12 @@ py-temp-directory\tdirectory used for temp files (if needed)
|
|||
py-beep-if-tab-change\tring the bell if tab-width is changed"
|
||||
(interactive)
|
||||
(kill-all-local-variables)
|
||||
(set-syntax-table py-mode-syntax-table)
|
||||
(setq major-mode 'python-mode
|
||||
mode-name "Python"
|
||||
local-abbrev-table python-mode-abbrev-table)
|
||||
(use-local-map py-mode-map)
|
||||
(set-syntax-table py-mode-syntax-table)
|
||||
|
||||
;; BAW -- style...
|
||||
(mapcar (function (lambda (x)
|
||||
(make-local-variable (car x))
|
||||
(set (car x) (cdr x))))
|
||||
|
|
@ -255,12 +324,14 @@ py-beep-if-tab-change\tring the bell if tab-width is changed"
|
|||
(comment-column . 40)
|
||||
(indent-region-function . py-indent-region)
|
||||
(indent-line-function . py-indent-line)))
|
||||
|
||||
;; hack to allow overriding the tabsize in the file (see tokenizer.c)
|
||||
|
||||
;; not sure where the magic comment has to be; to save time searching
|
||||
;; for a rarity, we give up if it's not found prior to the first
|
||||
;; executable statement
|
||||
;;
|
||||
;; not sure where the magic comment has to be; to save time
|
||||
;; searching for a rarity, we give up if it's not found prior to the
|
||||
;; first executable statement.
|
||||
;;
|
||||
;; BAW - on first glance, this seems like complete hackery. Why was
|
||||
;; this necessary, and is it still necessary?
|
||||
(let ((case-fold-search nil)
|
||||
(start (point))
|
||||
new-tab-width)
|
||||
|
|
@ -279,12 +350,13 @@ py-beep-if-tab-change\tring the bell if tab-width is changed"
|
|||
(if py-beep-if-tab-change (beep)))))
|
||||
(goto-char start))
|
||||
|
||||
;; run the mode hook. py-mode-hook use is deprecated
|
||||
(if python-mode-hook
|
||||
(run-hooks 'python-mode-hook)
|
||||
(run-hooks 'py-mode-hook)))
|
||||
|
||||
|
||||
;;; Functions that execute Python commands in a subprocess
|
||||
|
||||
(defun py-shell ()
|
||||
"Start an interactive Python interpreter in another window.
|
||||
This is like Shell mode, except that Python is running in the window
|
||||
|
|
@ -292,16 +364,17 @@ instead of a shell. See the `Interactive Shell' and `Shell Mode'
|
|||
sections of the Emacs manual for details, especially for the key
|
||||
bindings active in the `*Python*' buffer.
|
||||
|
||||
See the docs for variable py-scroll-buffer for info on scrolling
|
||||
See the docs for variable `py-scroll-buffer' for info on scrolling
|
||||
behavior in the process window.
|
||||
|
||||
Warning: Don't use an interactive Python if you change sys.ps1 or
|
||||
sys.ps2 from their default values, or if you're running code that prints
|
||||
`>>> ' or `... ' at the start of a line. Python mode can't distinguish
|
||||
your output from Python's output, and assumes that `>>> ' at the start
|
||||
of a line is a prompt from Python. Similarly, the Emacs Shell mode code
|
||||
assumes that both `>>> ' and `... ' at the start of a line are Python
|
||||
prompts. Bad things can happen if you fool either mode.
|
||||
sys.ps2 from their default values, or if you're running code that
|
||||
prints `>>> ' or `... ' at the start of a line. `python-mode' can't
|
||||
distinguish your output from Python's output, and assumes that `>>> '
|
||||
at the start of a line is a prompt from Python. Similarly, the Emacs
|
||||
Shell mode code assumes that both `>>> ' and `... ' at the start of a
|
||||
line are Python prompts. Bad things can happen if you fool either
|
||||
mode.
|
||||
|
||||
Warning: If you do any editing *in* the process buffer *while* the
|
||||
buffer is accepting output from Python, do NOT attempt to `undo' the
|
||||
|
|
@ -310,6 +383,8 @@ be lost if you do. This appears to be an Emacs bug, an unfortunate
|
|||
interaction between undo and process filters; the same problem exists in
|
||||
non-Python process buffers using the default (Emacs-supplied) process
|
||||
filter."
|
||||
;; BAW - should undo be disabled in the python process buffer, if
|
||||
;; this bug still exists?
|
||||
(interactive)
|
||||
(if py-this-is-emacs-19-p
|
||||
(progn
|
||||
|
|
@ -330,31 +405,32 @@ filter."
|
|||
"Send the region between START and END to a Python interpreter.
|
||||
If there is a *Python* process it is used.
|
||||
|
||||
Hint: If you want to execute part of a Python file several times (e.g.,
|
||||
perhaps you're developing a function and want to flesh it out a bit at a
|
||||
time), use `\\[narrow-to-region]' to restrict the buffer to the region of interest,
|
||||
and send the code to a *Python* process via `\\[py-execute-buffer]' instead.
|
||||
Hint: If you want to execute part of a Python file several times
|
||||
\(e.g., perhaps you're developing a function and want to flesh it out
|
||||
a bit at a time), use `\\[narrow-to-region]' to restrict the buffer to
|
||||
the region of interest, and send the code to a *Python* process via
|
||||
`\\[py-execute-buffer]' instead.
|
||||
|
||||
Following are subtleties to note when using a *Python* process:
|
||||
|
||||
If a *Python* process is used, the region is copied into a temp file (in
|
||||
directory py-temp-directory), and an `execfile' command is sent to
|
||||
Python naming that file. If you send regions faster than Python can
|
||||
execute them, Python mode will save them into distinct temp files, and
|
||||
execute the next one in the queue the next time it sees a `>>> ' prompt
|
||||
from Python. Each time this happens, the process buffer is popped into
|
||||
a window (if it's not already in some window) so you can see it, and a
|
||||
comment of the form
|
||||
If a *Python* process is used, the region is copied into a temporary
|
||||
file (in directory `py-temp-directory'), and an `execfile' command is
|
||||
sent to Python naming that file. If you send regions faster than
|
||||
Python can execute them, `python-mode' will save them into distinct
|
||||
temp files, and execute the next one in the queue the next time it
|
||||
sees a `>>> ' prompt from Python. Each time this happens, the process
|
||||
buffer is popped into a window (if it's not already in some window) so
|
||||
you can see it, and a comment of the form
|
||||
|
||||
\t## working on region in file <name> ...
|
||||
|
||||
is inserted at the end.
|
||||
|
||||
Caution: No more than 26 regions can be pending at any given time. This
|
||||
limit is (indirectly) inherited from libc's mktemp(3). Python mode does
|
||||
not try to protect you from exceeding the limit. It's extremely
|
||||
unlikely that you'll get anywhere close to the limit in practice, unless
|
||||
you're trying to be a jerk <grin>.
|
||||
Caution: No more than 26 regions can be pending at any given time.
|
||||
This limit is (indirectly) inherited from libc's mktemp(3).
|
||||
`python-mode' does not try to protect you from exceeding the limit.
|
||||
It's extremely unlikely that you'll get anywhere close to the limit in
|
||||
practice, unless you're trying to be a jerk <grin>.
|
||||
|
||||
See the `\\[py-shell]' docs for additional warnings."
|
||||
(interactive "r")
|
||||
|
|
@ -386,19 +462,22 @@ See the `\\[py-shell]' docs for additional warnings."
|
|||
|
||||
;; make sure we switch to a different buffer at least once. if we
|
||||
;; *don't* do this, then if the process buffer is in the selected
|
||||
;; window, and point is before the end, and lots of output is coming
|
||||
;; at a fast pace, then (a) simple cursor-movement commands like
|
||||
;; C-p, C-n, C-f, C-b, C-a, C-e take an incredibly long time to have
|
||||
;; a visible effect (the window just doesn't get updated, sometimes
|
||||
;; for minutes(!)), and (b) it takes about 5x longer to get all the
|
||||
;; process output (until the next python prompt).
|
||||
;; window, and point is before the end, and lots of output is
|
||||
;; coming at a fast pace, then (a) simple cursor-movement commands
|
||||
;; like C-p, C-n, C-f, C-b, C-a, C-e take an incredibly long time
|
||||
;; to have a visible effect (the window just doesn't get updated,
|
||||
;; sometimes for minutes(!)), and (b) it takes about 5x longer to
|
||||
;; get all the process output (until the next python prompt).
|
||||
;;
|
||||
;; #b makes no sense to me at all. #a almost makes sense: unless we
|
||||
;; actually change buffers, set_buffer_internal in buffer.c doesn't
|
||||
;; set windows_or_buffers_changed to 1, & that in turn seems to make
|
||||
;; the Emacs command loop reluctant to update the display. Perhaps
|
||||
;; the default process filter in process.c's read_process_output has
|
||||
;; update_mode_lines++ for a similar reason? beats me ...
|
||||
;; #b makes no sense to me at all. #a almost makes sense: unless
|
||||
;; we actually change buffers, set_buffer_internal in buffer.c
|
||||
;; doesn't set windows_or_buffers_changed to 1, & that in turn
|
||||
;; seems to make the Emacs command loop reluctant to update the
|
||||
;; display. Perhaps the default process filter in process.c's
|
||||
;; read_process_output has update_mode_lines++ for a similar
|
||||
;; reason? beats me ...
|
||||
|
||||
;; BAW - we want to check to see if this still applies
|
||||
(if (eq curbuf pbuf) ; mysterious ugly hack
|
||||
(set-buffer (get-buffer-create "*scratch*")))
|
||||
|
||||
|
|
@ -441,8 +520,8 @@ See the `\\[py-execute-region]' docs for an account of some subtleties."
|
|||
(py-execute-region (point-min) (point-max)))
|
||||
|
||||
|
||||
;;; Functions for Python style indentation
|
||||
|
||||
|
||||
;; Functions for Python style indentation
|
||||
(defun py-delete-char ()
|
||||
"Reduce indentation or delete character.
|
||||
If point is at the leftmost column, deletes the preceding newline.
|
||||
|
|
@ -451,8 +530,8 @@ Else if point is at the leftmost non-blank character of a line that is
|
|||
neither a continuation line nor a non-indenting comment line, or if
|
||||
point is at the end of a blank line, reduces the indentation to match
|
||||
that of the line that opened the current block of code. The line that
|
||||
opened the block is displayed in the echo area to help you keep track of
|
||||
where you are.
|
||||
opened the block is displayed in the echo area to help you keep track
|
||||
of where you are.
|
||||
|
||||
Else the preceding character is deleted, converting a tab to spaces if
|
||||
needed so that only a single column position is deleted."
|
||||
|
|
@ -497,7 +576,7 @@ needed so that only a single column position is deleted."
|
|||
(if move-to-indentation-p (back-to-indentation))))
|
||||
|
||||
(defun py-newline-and-indent ()
|
||||
"Strives to act like the Emacs newline-and-indent.
|
||||
"Strives to act like the Emacs `newline-and-indent'.
|
||||
This is just `strives to' because correct indentation can't be computed
|
||||
from scratch for Python code. In general, deletes the whitespace before
|
||||
point, inserts a newline, and takes an educated guess as to how you want
|
||||
|
|
@ -596,7 +675,9 @@ the new line indented."
|
|||
;; happens to be a continuation line too
|
||||
(re-search-backward "^[ \t]*\\([^ \t\n#]\\|#[ \t\n]\\)"
|
||||
nil 'move)
|
||||
;; if we landed inside a string, go to the beginning of that string
|
||||
;; if we landed inside a string, go to the beginning of that
|
||||
;; string. this handles triple quoted, multi-line spanning
|
||||
;; strings.
|
||||
(let ((state (parse-partial-sexp
|
||||
(save-excursion (beginning-of-python-def-or-class)
|
||||
(point))
|
||||
|
|
@ -609,22 +690,23 @@ the new line indented."
|
|||
(current-indentation))))))
|
||||
|
||||
(defun py-guess-indent-offset (&optional global)
|
||||
"Guess a good value for, and change, py-indent-offset.
|
||||
"Guess a good value for, and change, `py-indent-offset'.
|
||||
By default (without a prefix arg), makes a buffer-local copy of
|
||||
py-indent-offset with the new value. This will not affect any other
|
||||
`py-indent-offset' with the new value. This will not affect any other
|
||||
Python buffers. With a prefix arg, changes the global value of
|
||||
py-indent-offset. This affects all Python buffers (that don't have
|
||||
`py-indent-offset'. This affects all Python buffers (that don't have
|
||||
their own buffer-local copy), both those currently existing and those
|
||||
created later in the Emacs session.
|
||||
|
||||
Some people use a different value for py-indent-offset than you use.
|
||||
Some people use a different value for `py-indent-offset' than you use.
|
||||
There's no excuse for such foolishness, but sometimes you have to deal
|
||||
with their ugly code anyway. This function examines the file and sets
|
||||
py-indent-offset to what it thinks it was when they created the mess.
|
||||
`py-indent-offset' to what it thinks it was when they created the
|
||||
mess.
|
||||
|
||||
Specifically, it searches forward from the statement containing point,
|
||||
looking for a line that opens a block of code. py-indent-offset is set
|
||||
to the difference in indentation between that line and the Python
|
||||
looking for a line that opens a block of code. `py-indent-offset' is
|
||||
set to the difference in indentation between that line and the Python
|
||||
statement following it. If the search doesn't succeed going forward,
|
||||
it's tried again going backward."
|
||||
(interactive "P") ; raw prefix arg
|
||||
|
|
@ -676,7 +758,7 @@ it's tried again going backward."
|
|||
"Shift region of Python code to the left.
|
||||
The lines from the line containing the start of the current region up
|
||||
to (but not including) the line containing the end of the region are
|
||||
shifted to the left, by py-indent-offset columns.
|
||||
shifted to the left, by `py-indent-offset' columns.
|
||||
|
||||
If a prefix argument is given, the region is instead shifted by that
|
||||
many columns."
|
||||
|
|
@ -689,7 +771,7 @@ many columns."
|
|||
"Shift region of Python code to the right.
|
||||
The lines from the line containing the start of the current region up
|
||||
to (but not including) the line containing the end of the region are
|
||||
shifted to the right, by py-indent-offset columns.
|
||||
shifted to the right, by `py-indent-offset' columns.
|
||||
|
||||
If a prefix argument is given, the region is instead shifted by that
|
||||
many columns."
|
||||
|
|
@ -702,17 +784,17 @@ many columns."
|
|||
The lines from the line containing the start of the current region up
|
||||
to (but not including) the line containing the end of the region are
|
||||
reindented. If the first line of the region has a non-whitespace
|
||||
character in the first column, the first line is left alone and the rest
|
||||
of the region is reindented with respect to it. Else the entire region
|
||||
is reindented with respect to the (closest code or indenting-comment)
|
||||
statement immediately preceding the region.
|
||||
character in the first column, the first line is left alone and the
|
||||
rest of the region is reindented with respect to it. Else the entire
|
||||
region is reindented with respect to the (closest code or
|
||||
indenting-comment) statement immediately preceding the region.
|
||||
|
||||
This is useful when code blocks are moved or yanked, when enclosing
|
||||
control structures are introduced or removed, or to reformat code using
|
||||
a new value for the indentation offset.
|
||||
control structures are introduced or removed, or to reformat code
|
||||
using a new value for the indentation offset.
|
||||
|
||||
If a numeric prefix argument is given, it will be used as the value of
|
||||
the indentation offset. Else the value of py-indent-offset will be
|
||||
the indentation offset. Else the value of `py-indent-offset' will be
|
||||
used.
|
||||
|
||||
Warning: The region must be consistently indented before this function
|
||||
|
|
@ -720,15 +802,14 @@ is called! This function does not compute proper indentation from
|
|||
scratch (that's impossible in Python), it merely adjusts the existing
|
||||
indentation to be correct in context.
|
||||
|
||||
Warning: This function really has no idea what to do with non-indenting
|
||||
comment lines, and shifts them as if they were indenting comment lines.
|
||||
Fixing this appears to require telepathy.
|
||||
Warning: This function really has no idea what to do with
|
||||
non-indenting comment lines, and shifts them as if they were indenting
|
||||
comment lines. Fixing this appears to require telepathy.
|
||||
|
||||
Special cases: whitespace is deleted from blank lines; continuation
|
||||
lines are shifted by the same amount their initial line was shifted, in
|
||||
order to preserve their relative indentation with respect to their
|
||||
lines are shifted by the same amount their initial line was shifted,
|
||||
in order to preserve their relative indentation with respect to their
|
||||
initial line; and comment lines beginning in column 1 are ignored."
|
||||
|
||||
(interactive "*r\nP") ; region; raw prefix arg
|
||||
(save-excursion
|
||||
(goto-char end) (beginning-of-line) (setq end (point-marker))
|
||||
|
|
@ -773,8 +854,8 @@ initial line; and comment lines beginning in column 1 are ignored."
|
|||
(forward-line 1))))
|
||||
(set-marker end nil))
|
||||
|
||||
;;; Functions for moving point
|
||||
|
||||
|
||||
;; Functions for moving point
|
||||
(defun py-previous-statement (count)
|
||||
"Go to the start of previous Python statement.
|
||||
If the statement at point is the i'th Python statement, goes to the
|
||||
|
|
@ -819,7 +900,8 @@ speaking, this will be the closest preceding statement that ends with a
|
|||
colon and is indented less than the statement you started on. If
|
||||
successful, also sets the mark to the starting point.
|
||||
|
||||
`\\[py-mark-block]' can be used afterward to mark the whole code block, if desired.
|
||||
`\\[py-mark-block]' can be used afterward to mark the whole code
|
||||
block, if desired.
|
||||
|
||||
If called from a program, the mark will not be set if optional argument
|
||||
NOMARK is not nil."
|
||||
|
|
@ -856,23 +938,24 @@ NOMARK is not nil."
|
|||
"Move point to start of def (or class, with prefix arg).
|
||||
|
||||
Searches back for the closest preceding `def'. If you supply a prefix
|
||||
arg, looks for a `class' instead. The docs assume the `def' case; just
|
||||
substitute `class' for `def' for the other case.
|
||||
arg, looks for a `class' instead. The docs assume the `def' case;
|
||||
just substitute `class' for `def' for the other case.
|
||||
|
||||
If point is in a def statement already, and after the `d', simply moves
|
||||
point to the start of the statement.
|
||||
If point is in a def statement already, and after the `d', simply
|
||||
moves point to the start of the statement.
|
||||
|
||||
Else (point is not in a def statement, or at or before the `d' of a def
|
||||
statement), searches for the closest preceding def statement, and leaves
|
||||
point at its start. If no such statement can be found, leaves point at
|
||||
the start of the buffer.
|
||||
Else (point is not in a def statement, or at or before the `d' of a
|
||||
def statement), searches for the closest preceding def statement, and
|
||||
leaves point at its start. If no such statement can be found, leaves
|
||||
point at the start of the buffer.
|
||||
|
||||
Returns t iff a def statement is found by these rules.
|
||||
|
||||
Note that doing this command repeatedly will take you closer to the start
|
||||
of the buffer each time.
|
||||
Note that doing this command repeatedly will take you closer to the
|
||||
start of the buffer each time.
|
||||
|
||||
If you want to mark the current def/class, see `\\[mark-python-def-or-class]'."
|
||||
If you want to mark the current def/class, see
|
||||
`\\[mark-python-def-or-class]'."
|
||||
(interactive "P") ; raw prefix arg
|
||||
(let ((at-or-before-p (<= (current-column) (current-indentation)))
|
||||
(start-of-line (progn (beginning-of-line) (point)))
|
||||
|
|
@ -892,21 +975,22 @@ substitute `class' for `def' for the other case.
|
|||
|
||||
If point is in a def statement already, this is the def we use.
|
||||
|
||||
Else if the def found by `\\[beginning-of-python-def-or-class]' contains the statement you
|
||||
started on, that's the def we use.
|
||||
Else if the def found by `\\[beginning-of-python-def-or-class]'
|
||||
contains the statement you started on, that's the def we use.
|
||||
|
||||
Else we search forward for the closest following def, and use that.
|
||||
|
||||
If a def can be found by these rules, point is moved to the start of the
|
||||
line immediately following the def block, and the position of the start
|
||||
of the def is returned.
|
||||
If a def can be found by these rules, point is moved to the start of
|
||||
the line immediately following the def block, and the position of the
|
||||
start of the def is returned.
|
||||
|
||||
Else point is moved to the end of the buffer, and nil is returned.
|
||||
|
||||
Note that doing this command repeatedly will take you closer to the end
|
||||
of the buffer each time.
|
||||
Note that doing this command repeatedly will take you closer to the
|
||||
end of the buffer each time.
|
||||
|
||||
If you want to mark the current def/class, see `\\[mark-python-def-or-class]'."
|
||||
If you want to mark the current def/class, see
|
||||
`\\[mark-python-def-or-class]'."
|
||||
(interactive "P") ; raw prefix arg
|
||||
(let ((start (progn (py-goto-initial-line) (point)))
|
||||
(which (if class "class" "def"))
|
||||
|
|
@ -930,8 +1014,8 @@ If you want to mark the current def/class, see `\\[mark-python-def-or-class]'."
|
|||
((eq state 'not-found) nil)
|
||||
(t (error "internal error in end-of-python-def-or-class")))))
|
||||
|
||||
;;; Functions for marking regions
|
||||
|
||||
|
||||
;; Functions for marking regions
|
||||
(defun py-mark-block (&optional extend just-move)
|
||||
"Mark following block of lines. With prefix arg, mark structure.
|
||||
Easier to use than explain. It sets the region to an `interesting'
|
||||
|
|
@ -944,25 +1028,27 @@ of the region depends on the kind of line at the start:
|
|||
|
||||
- Else if a prefix arg is given, and the line begins one of these
|
||||
structures:
|
||||
\tif elif else try except finally for while def class
|
||||
|
||||
if elif else try except finally for while def class
|
||||
|
||||
the region will be set to the body of the structure, including
|
||||
following blocks that `belong' to it, but excluding trailing blank
|
||||
and comment lines. E.g., if on a `try' statement, the `try' block
|
||||
and all (if any) of the following `except' and `finally' blocks that
|
||||
belong to the `try' structure will be in the region. Ditto for
|
||||
if/elif/else, for/else and while/else structures, and (a bit
|
||||
degenerate, since they're always one-block structures) def and class
|
||||
blocks.
|
||||
and all (if any) of the following `except' and `finally' blocks
|
||||
that belong to the `try' structure will be in the region. Ditto
|
||||
for if/elif/else, for/else and while/else structures, and (a bit
|
||||
degenerate, since they're always one-block structures) def and
|
||||
class blocks.
|
||||
|
||||
- Else if no prefix argument is given, and the line begins a Python
|
||||
block (see list above), and the block is not a `one-liner' (i.e., the
|
||||
statement ends with a colon, not with code), the region will include
|
||||
all succeeding lines up to (but not including) the next code
|
||||
statement (if any) that's indented no more than the starting line,
|
||||
except that trailing blank and comment lines are excluded. E.g., if
|
||||
the starting line begins a multi-statement `def' structure, the
|
||||
region will be set to the full function definition, but without any
|
||||
trailing `noise' lines.
|
||||
block (see list above), and the block is not a `one-liner' (i.e.,
|
||||
the statement ends with a colon, not with code), the region will
|
||||
include all succeeding lines up to (but not including) the next
|
||||
code statement (if any) that's indented no more than the starting
|
||||
line, except that trailing blank and comment lines are excluded.
|
||||
E.g., if the starting line begins a multi-statement `def'
|
||||
structure, the region will be set to the full function definition,
|
||||
but without any trailing `noise' lines.
|
||||
|
||||
- Else the region will include all succeeding lines up to (but not
|
||||
including) the next blank line, or code or indenting-comment line
|
||||
|
|
@ -973,10 +1059,9 @@ of the region depends on the kind of line at the start:
|
|||
A msg identifying the location of the mark is displayed in the echo
|
||||
area; or do `\\[exchange-point-and-mark]' to flip down to the end.
|
||||
|
||||
If called from a program, optional argument EXTEND plays the role of the
|
||||
prefix arg, and if optional argument JUST-MOVE is not nil, just moves to
|
||||
the end of the block (& does not set mark or display a msg)."
|
||||
|
||||
If called from a program, optional argument EXTEND plays the role of
|
||||
the prefix arg, and if optional argument JUST-MOVE is not nil, just
|
||||
moves to the end of the block (& does not set mark or display a msg)."
|
||||
(interactive "P") ; raw prefix arg
|
||||
(py-goto-initial-line)
|
||||
;; skip over blank lines
|
||||
|
|
@ -1056,32 +1141,34 @@ Pushes the current mark, then point, on the mark ring (all language
|
|||
modes do this, but although it's handy it's never documented ...).
|
||||
|
||||
In most Emacs language modes, this function bears at least a
|
||||
hallucinogenic resemblance to `\\[end-of-python-def-or-class]' and `\\[beginning-of-python-def-or-class]'.
|
||||
hallucinogenic resemblance to `\\[end-of-python-def-or-class]' and
|
||||
`\\[beginning-of-python-def-or-class]'.
|
||||
|
||||
And in earlier versions of Python mode, all 3 were tightly connected.
|
||||
Turned out that was more confusing than useful: the `goto start' and
|
||||
`goto end' commands are usually used to search through a file, and people
|
||||
expect them to act a lot like `search backward' and `search forward'
|
||||
string-search commands. But because Python `def' and `class' can nest to
|
||||
arbitrary levels, finding the smallest def containing point cannot be
|
||||
done via a simple backward search: the def containing point may not be
|
||||
the closest preceding def, or even the closest preceding def that's
|
||||
indented less. The fancy algorithm required is appropriate for the usual
|
||||
uses of this `mark' command, but not for the `goto' variations.
|
||||
`goto end' commands are usually used to search through a file, and
|
||||
people expect them to act a lot like `search backward' and `search
|
||||
forward' string-search commands. But because Python `def' and `class'
|
||||
can nest to arbitrary levels, finding the smallest def containing
|
||||
point cannot be done via a simple backward search: the def containing
|
||||
point may not be the closest preceding def, or even the closest
|
||||
preceding def that's indented less. The fancy algorithm required is
|
||||
appropriate for the usual uses of this `mark' command, but not for the
|
||||
`goto' variations.
|
||||
|
||||
So the def marked by this command may not be the one either of the `goto'
|
||||
commands find: If point is on a blank or non-indenting comment line,
|
||||
moves back to start of the closest preceding code statement or indenting
|
||||
comment line. If this is a `def' statement, that's the def we use. Else
|
||||
searches for the smallest enclosing `def' block and uses that. Else
|
||||
signals an error.
|
||||
So the def marked by this command may not be the one either of the
|
||||
`goto' commands find: If point is on a blank or non-indenting comment
|
||||
line, moves back to start of the closest preceding code statement or
|
||||
indenting comment line. If this is a `def' statement, that's the def
|
||||
we use. Else searches for the smallest enclosing `def' block and uses
|
||||
that. Else signals an error.
|
||||
|
||||
When an enclosing def is found: The mark is left immediately beyond the
|
||||
last line of the def block. Point is left at the start of the def,
|
||||
except that: if the def is preceded by a number of comment lines
|
||||
followed by (at most) one optional blank line, point is left at the start
|
||||
of the comments; else if the def is preceded by a blank line, point is
|
||||
left at its start.
|
||||
When an enclosing def is found: The mark is left immediately beyond
|
||||
the last line of the def block. Point is left at the start of the
|
||||
def, except that: if the def is preceded by a number of comment lines
|
||||
followed by (at most) one optional blank line, point is left at the
|
||||
start of the comments; else if the def is preceded by a blank line,
|
||||
point is left at its start.
|
||||
|
||||
The intent is to mark the containing def/class and its associated
|
||||
documentation, to make moving and duplicating functions and classes
|
||||
|
|
@ -1118,9 +1205,9 @@ pleasant."
|
|||
"Comment out region of code; with prefix arg, uncomment region.
|
||||
The lines from the line containing the start of the current region up
|
||||
to (but not including) the line containing the end of the region are
|
||||
commented out, by inserting the string py-block-comment-prefix at the
|
||||
start of each line. With a prefix arg, removes py-block-comment-prefix
|
||||
from the start of each line instead."
|
||||
commented out, by inserting the string `py-block-comment-prefix' at
|
||||
the start of each line. With a prefix arg, removes
|
||||
`py-block-comment-prefix' from the start of each line instead."
|
||||
(interactive "*r\nP") ; region; raw prefix arg
|
||||
(goto-char end) (beginning-of-line) (setq end (point))
|
||||
(goto-char start) (beginning-of-line) (setq start (point))
|
||||
|
|
@ -1137,12 +1224,13 @@ from the start of each line instead."
|
|||
(insert py-block-comment-prefix))
|
||||
(forward-line 1))))))
|
||||
|
||||
;;; Documentation functions
|
||||
|
||||
;; Documentation functions
|
||||
|
||||
;; dump the long form of the mode blurb; does the usual doc escapes,
|
||||
;; plus lines of the form ^[vc]:name$ to suck variable & command
|
||||
;; docs out of the right places, along with the keys they're on &
|
||||
;; current values
|
||||
;; plus lines of the form ^[vc]:name$ to suck variable & command docs
|
||||
;; out of the right places, along with the keys they're on & current
|
||||
;; values
|
||||
(defun py-dump-help-string (str)
|
||||
(with-output-to-temp-buffer "*Help*"
|
||||
(let ((locals (buffer-local-variables))
|
||||
|
|
@ -1226,13 +1314,13 @@ py-beep-if-tab-change\tring the bell if tab-width is changed
|
|||
@KINDS OF LINES
|
||||
|
||||
Each physical line in the file is either a `continuation line' (the
|
||||
preceding line ends with a backslash that's not part of a comment, or the
|
||||
paren/bracket/brace nesting level at the start of the line is non-zero,
|
||||
or both) or an `initial line' (everything else).
|
||||
preceding line ends with a backslash that's not part of a comment, or
|
||||
the paren/bracket/brace nesting level at the start of the line is
|
||||
non-zero, or both) or an `initial line' (everything else).
|
||||
|
||||
An initial line is in turn a `blank line' (contains nothing except
|
||||
possibly blanks or tabs), a `comment line' (leftmost non-blank character
|
||||
is `#'), or a `code line' (everything else).
|
||||
possibly blanks or tabs), a `comment line' (leftmost non-blank
|
||||
character is `#'), or a `code line' (everything else).
|
||||
|
||||
Comment Lines
|
||||
|
||||
|
|
@ -1244,12 +1332,12 @@ nothing after the initial `#'. The indentation commands (see below)
|
|||
treat these exactly as if they were code lines: a line following an
|
||||
indenting comment line will be indented like the comment line. All
|
||||
other comment lines (those with a non-whitespace character immediately
|
||||
following the initial `#') are `non-indenting comment lines', and their
|
||||
indentation is ignored by the indentation commands.
|
||||
following the initial `#') are `non-indenting comment lines', and
|
||||
their indentation is ignored by the indentation commands.
|
||||
|
||||
Indenting comment lines are by far the usual case, and should be used
|
||||
whenever possible. Non-indenting comment lines are useful in cases like
|
||||
these:
|
||||
whenever possible. Non-indenting comment lines are useful in cases
|
||||
like these:
|
||||
|
||||
\ta = b # a very wordy single-line comment that ends up being
|
||||
\t #... continued onto another line
|
||||
|
|
@ -1258,9 +1346,9 @@ these:
|
|||
##\t\tprint 'panic!' # old code we've `commented out'
|
||||
\t\treturn a
|
||||
|
||||
Since the `#...' and `##' comment lines have a non-whitespace character
|
||||
following the initial `#', Python mode ignores them when computing the
|
||||
proper indentation for the next line.
|
||||
Since the `#...' and `##' comment lines have a non-whitespace
|
||||
character following the initial `#', Python mode ignores them when
|
||||
computing the proper indentation for the next line.
|
||||
|
||||
Continuation Lines and Statements
|
||||
|
||||
|
|
@ -1269,8 +1357,8 @@ individual lines, where a `statement' is a comment or blank line, or a
|
|||
code line and all of its following continuation lines (if any)
|
||||
considered as a single logical unit. The commands in this mode
|
||||
generally (when it makes sense) automatically move to the start of the
|
||||
statement containing point, even if point happens to be in the middle of
|
||||
some continuation line.
|
||||
statement containing point, even if point happens to be in the middle
|
||||
of some continuation line.
|
||||
|
||||
|
||||
@INDENTATION
|
||||
|
|
@ -1432,23 +1520,25 @@ Obscure: When python-mode is first loaded, it looks for all bindings
|
|||
to newline-and-indent in the global keymap, and shadows them with
|
||||
local bindings to py-newline-and-indent."))
|
||||
|
||||
;;; Helper functions
|
||||
|
||||
;; Helper functions
|
||||
|
||||
(defvar py-parse-state-re
|
||||
(concat
|
||||
"^[ \t]*\\(if\\|elif\\|else\\|while\\|def\\|class\\)\\>"
|
||||
"\\|"
|
||||
"^[^ #\t\n]"))
|
||||
|
||||
;; returns the parse state at point (see parse-partial-sexp docs)
|
||||
(defun py-parse-state ()
|
||||
(save-excursion
|
||||
(let ((here (point)) )
|
||||
;; back up to the first preceding line (if any; else start of
|
||||
;; buffer) that begins with a popular Python keyword, or a non-
|
||||
;; whitespace and non-comment character. These are good places to
|
||||
;; start parsing to see whether where we started is at a non-zero
|
||||
;; nesting level. It may be slow for people who write huge code
|
||||
;; blocks or huge lists ... tough beans.
|
||||
;; whitespace and non-comment character. These are good places
|
||||
;; to start parsing to see whether where we started is at a
|
||||
;; non-zero nesting level. It may be slow for people who write
|
||||
;; huge code blocks or huge lists ... tough beans.
|
||||
(re-search-backward py-parse-state-re nil 'move)
|
||||
(beginning-of-line)
|
||||
(parse-partial-sexp (point) here))))
|
||||
|
|
@ -1481,13 +1571,15 @@ local bindings to py-newline-and-indent."))
|
|||
(or (py-backslash-continuation-line-p)
|
||||
(py-nesting-level))))
|
||||
|
||||
;; go to initial line of current statement; usually this is the
|
||||
;; line we're on, but if we're on the 2nd or following lines of a
|
||||
;; continuation block, we need to go up to the first line of the block.
|
||||
;; go to initial line of current statement; usually this is the line
|
||||
;; we're on, but if we're on the 2nd or following lines of a
|
||||
;; continuation block, we need to go up to the first line of the
|
||||
;; block.
|
||||
;;
|
||||
;; Tricky: We want to avoid quadratic-time behavior for long continued
|
||||
;; blocks, whether of the backslash or open-bracket varieties, or a mix
|
||||
;; of the two. The following manages to do that in the usual cases.
|
||||
;; blocks, whether of the backslash or open-bracket varieties, or a
|
||||
;; mix of the two. The following manages to do that in the usual
|
||||
;; cases.
|
||||
(defun py-goto-initial-line ()
|
||||
(let ( open-bracket-pos )
|
||||
(while (py-continuation-line-p)
|
||||
|
|
@ -1502,8 +1594,8 @@ local bindings to py-newline-and-indent."))
|
|||
|
||||
;; go to point right beyond final line of current statement; usually
|
||||
;; this is the start of the next line, but if this is a multi-line
|
||||
;; statement we need to skip over the continuation lines.
|
||||
;; Tricky: Again we need to be clever to avoid quadratic time behavior.
|
||||
;; statement we need to skip over the continuation lines. Tricky:
|
||||
;; Again we need to be clever to avoid quadratic time behavior.
|
||||
(defun py-goto-beyond-final-line ()
|
||||
(forward-line 1)
|
||||
(let (state)
|
||||
|
|
@ -1525,8 +1617,7 @@ local bindings to py-newline-and-indent."))
|
|||
(forward-line 1))))))
|
||||
|
||||
;; t iff statement opens a block == iff it ends with a colon that's
|
||||
;; not in a comment
|
||||
;; point should be at the start of a statement
|
||||
;; not in a comment. point should be at the start of a statement
|
||||
(defun py-statement-opens-block-p ()
|
||||
(save-excursion
|
||||
(let ((start (point))
|
||||
|
|
@ -1557,16 +1648,15 @@ local bindings to py-newline-and-indent."))
|
|||
;; go to point right beyond final line of block begun by the current
|
||||
;; line. This is the same as where py-goto-beyond-final-line goes
|
||||
;; unless we're on colon line, in which case we go to the end of the
|
||||
;; block.
|
||||
;; assumes point is at bolp
|
||||
;; block. assumes point is at bolp
|
||||
(defun py-goto-beyond-block ()
|
||||
(if (py-statement-opens-block-p)
|
||||
(py-mark-block nil 'just-move)
|
||||
(py-goto-beyond-final-line)))
|
||||
|
||||
;; go to start of first statement (not blank or comment or continuation
|
||||
;; line) at or preceding point
|
||||
;; returns t if there is one, else nil
|
||||
;; go to start of first statement (not blank or comment or
|
||||
;; continuation line) at or preceding point. returns t if there is
|
||||
;; one, else nil
|
||||
(defun py-goto-statement-at-or-above ()
|
||||
(py-goto-initial-line)
|
||||
(if (looking-at py-blank-or-comment-re)
|
||||
|
|
@ -1578,9 +1668,9 @@ local bindings to py-newline-and-indent."))
|
|||
nil)
|
||||
t))
|
||||
|
||||
;; go to start of first statement (not blank or comment or continuation
|
||||
;; line) following the statement containing point
|
||||
;; returns t if there is one, else nil
|
||||
;; go to start of first statement (not blank or comment or
|
||||
;; continuation line) following the statement containing point returns
|
||||
;; t if there is one, else nil
|
||||
(defun py-goto-statement-below ()
|
||||
(beginning-of-line)
|
||||
(let ((start (point)))
|
||||
|
|
@ -1593,12 +1683,12 @@ local bindings to py-newline-and-indent."))
|
|||
(progn (goto-char start) nil)
|
||||
t)))
|
||||
|
||||
;; go to start of statement, at or preceding point, starting with keyword
|
||||
;; KEY. Skips blank lines and non-indenting comments upward first. If
|
||||
;; that statement starts with KEY, done, else go back to first enclosing
|
||||
;; block starting with KEY.
|
||||
;; If successful, leaves point at the start of the KEY line & returns t.
|
||||
;; Else leaves point at an undefined place & returns nil.
|
||||
;; go to start of statement, at or preceding point, starting with
|
||||
;; keyword KEY. Skips blank lines and non-indenting comments upward
|
||||
;; first. If that statement starts with KEY, done, else go back to
|
||||
;; first enclosing block starting with KEY. If successful, leaves
|
||||
;; point at the start of the KEY line & returns t. Else leaves point
|
||||
;; at an undefined place & returns nil.
|
||||
(defun py-go-up-tree-to-keyword (key)
|
||||
;; skip blanks and non-indenting #
|
||||
(py-goto-initial-line)
|
||||
|
|
@ -1655,9 +1745,10 @@ local bindings to py-newline-and-indent."))
|
|||
(and py-inherited-kill-emacs-hook
|
||||
(funcall py-inherited-kill-emacs-hook))))
|
||||
|
||||
;; make PROCESS's buffer visible, append STRING to it, and force display;
|
||||
;; also make shell-mode believe the user typed this string, so that
|
||||
;; kill-output-from-shell and show-output-from-shell work "right"
|
||||
;; make PROCESS's buffer visible, append STRING to it, and force
|
||||
;; display; also make shell-mode believe the user typed this string,
|
||||
;; so that kill-output-from-shell and show-output-from-shell work
|
||||
;; "right"
|
||||
(defun py-append-to-process-buffer (process string)
|
||||
(let ((cbuf (current-buffer))
|
||||
(pbuf (process-buffer process))
|
||||
|
|
@ -1673,5 +1764,24 @@ local bindings to py-newline-and-indent."))
|
|||
(set-buffer cbuf))
|
||||
(sit-for 0))
|
||||
|
||||
;; To do:
|
||||
;; - support for ptags
|
||||
|
||||
|
||||
;; initializations
|
||||
|
||||
;; arrange to kill temp files when Emacs exists
|
||||
(if (or py-this-is-emacs-19-p py-this-is-lucid-emacs-p)
|
||||
(add-hook 'kill-emacs-hook 'py-kill-emacs-hook)
|
||||
;; have to trust that other people are as respectful of our hook
|
||||
;; fiddling as we are of theirs
|
||||
(if (boundp 'py-inherited-kill-emacs-hook)
|
||||
;; we were loaded before -- trust others not to have screwed us
|
||||
;; in the meantime (no choice, really)
|
||||
nil
|
||||
;; else arrange for our hook to run theirs
|
||||
(setq py-inherited-kill-emacs-hook kill-emacs-hook)
|
||||
(setq kill-emacs-hook 'py-kill-emacs-hook)))
|
||||
|
||||
|
||||
|
||||
(provide 'python-mode)
|
||||
;;; python-mode.el ends here
|
||||
|
|
|
|||
Loading…
Reference in New Issue