* python.el fixes for Emacs 22
@ 2008-02-11 13:34 Richard Stallman
2008-02-11 15:15 ` Stefan Monnier
2008-02-14 0:36 ` Chong Yidong
0 siblings, 2 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-11 13:34 UTC (permalink / raw)
To: emacs-devel
I asked Dave to send a diff and a change log, as a good
contributor should, but he did not respond. I think that the
changes are important enough that we should do the extra
work to install them anyway.
Would someone please volunteer to look at them, write change
log entries for them, and decide whether to install them now?
Please email me if you volunteer, so I don't have to keep asking.
I think this ought to be done for Emacs 22.2, if the changes
are bug fixes.
------- Start of forwarded message -------
To: gnu-emacs-sources@gnu.org
From: Dave Love <fx@gnu.org>
Date: Sun, 20 Jan 2008 23:37:52 +0000
Message-ID: <87bq7g2hm7.fsf@liv.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="bluebird-explosion-Lon-Horiuchi-bootleg-csim"
Subject: fixed python.el
- --bluebird-explosion-Lon-Horiuchi-bootleg-csim
This is a fixed version of my python.el that works correctly in Emacs
22 (as far as I can tell). Please report problems with this to me,
but check for updates at <URL:http://www.loveshack.ukfsn.org/emacs/>,
which also has the equivalent Emacs 21 version.
[The python.el in Emacs 22 has various problems which aren't in the
code that I run under Emacs 21 and which it doesn't seem possible to
get fixed/undone. Previously I hadn't kept up with the things Emacs
22 has broken, to be able to maintain a working version, but I'll try
to keep this going in future.]
You need the three files below. I've kept the abstraction of symbol
completion in sym-comp.el because it's the right thing generally.
emacs.py can either be copied on top of the released one in
`data-directory' or put somewhere outside the Emacs tree referenced by
the normal PYTHONPATH. PYTHONPATH can be set by your shell start-up
and/or `setenv'ed in .emacs. Obviously the compiled Lisp files go on
`load-path' ahead of the python.el distributed with Emacs 22.
- --bluebird-explosion-Lon-Horiuchi-bootleg-csim
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=python.el
Content-Transfer-Encoding: quoted-printable
;;; python.el --- silly walks for Python -*- coding: iso-8859-1 -*-
;; Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundati=
on, Inc.
;; Author: Dave Love <fx@gnu.org>
;; Created: Nov 2003
;; Keywords: languages
;; URL: http://www.loveshack.ukfsn.org/emacs/
;; $Revision: 1.10 $
;; This file 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 3, or (at your option)
;; any later version.
;; This file 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 GNU Emacs; see the file COPYING. If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.
;;; Commentary:
;; Major mode for editing Python, with support for inferior processes.
;; There is another Python mode, python-mode.el, used by XEmacs and
;; maintained with Python. That isn't covered by an FSF copyright
;; assignment, unlike this code, and seems not to be well-maintained
;; for Emacs (though I've submitted fixes). This mode is rather
;; simpler and is better in other ways. In particular, using the
;; syntax functions with text properties maintained by font-lock makes
;; it more correct with arbitrary string and comment contents.
;; This doesn't implement all the facilities of python-mode.el. Some
;; just need doing, e.g. catching exceptions in the inferior Python
;; buffer (but see M-x pdb for debugging). [Actually, the use of
;; `compilation-shell-minor-mode' now is probably enough for that.]
;; Others don't seem appropriate. For instance,
;; `forward-into-nomenclature' should be done separately, since it's
;; not specific to Python, and I've installed a minor mode to do the
;; job properly in Emacs 23. [CC mode 5.31 contains an incompatible
;; feature, `c-subword-mode' which is intended to have a similar
;; effect, but actually only affects word-oriented keybindings.]
;; Other things seem more natural or canonical here, e.g. the
;; {beginning,end}-of-defun implementation dealing with nested
;; definitions, and the inferior mode following `cmuscheme'. (The
;; inferior mode can find the source of errors from
;; `python-send-region' & al via `compilation-shell-minor-mode'.)
;; There is (limited) symbol completion using lookup in Python and
;; Eldoc support also using the inferior process. Successive TABs
;; cycle between possible indentations for the line.
;; Even where it has similar facilities, this mode is incompatible
;; with python-mode.el in some respects. For instance, various key
;; bindings are changed to obey Emacs conventions.
;; TODO: See various Fixmes below.
;; Fixme: This doesn't support (the nascent) Python 3 .
;;; Code:
(eval-when-compile
(require 'compile)
(require 'comint)
(autoload 'info-lookup-maybe-add-help "info-look"))
(require 'sym-comp)
(autoload 'comint-mode "comint")
(defgroup python nil
"Silly walks in the Python language."
:group 'languages
:version "22.1"
:link '(emacs-commentary-link "python"))
\f
;;;###autoload
(add-to-list 'interpreter-mode-alist '("jython" . jython-mode))
;;;###autoload
(add-to-list 'interpreter-mode-alist '("python" . python-mode))
;;;###autoload
(add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode))
(add-to-list 'same-window-buffer-names "*Python*")
\f
;;;; Font lock
(defvar python-font-lock-keywords
`(,(rx symbol-start
;; From v 2.5 reference, =A7 keywords.
;; def and class dealt with separately below
(or "and" "as" "assert" "break" "continue" "del" "elif" "else"
"except" "exec" "finally" "for" "from" "global" "if"
"import" "in" "is" "lambda" "not" "or" "pass" "print"
"raise" "return" "try" "while" "with" "yield")
symbol-end)
(,(rx symbol-start "None" symbol-end) ; see =A7 Keywords in 2.5 manual
. font-lock-constant-face)
;; Definitions
(,(rx symbol-start (group "class") (1+ space) (group (1+ (or word ?_))))
(1 font-lock-keyword-face) (2 font-lock-type-face))
(,(rx symbol-start (group "def") (1+ space) (group (1+ (or word ?_))))
(1 font-lock-keyword-face) (2 font-lock-function-name-face))
;; Top-level assignments are worth highlighting.
(,(rx line-start (group (1+ (or word ?_))) (0+ space) "=3D")
(1 font-lock-variable-name-face))
(,(rx line-start (* (any " \t")) (group "@" (1+ (or word ?_)))) ; decor=
ators
(1 font-lock-type-face))
;; Built-ins. (The next three blocks are from
;; `__builtin__.__dict__.keys()' in Python 2.5.1.) These patterns
;; are debateable, but they at least help to spot possible
;; shadowing of builtins.
(,(rx symbol-start (or
;; exceptions
"ArithmeticError" "AssertionError" "AttributeError"
"BaseException" "DeprecationWarning" "EOFError"
"EnvironmentError" "Exception" "FloatingPointError"
"FutureWarning" "GeneratorExit" "IOError" "ImportError"
"ImportWarning" "IndentationError" "IndexError" "KeyError"
"KeyboardInterrupt" "LookupError" "MemoryError" "NameError"
"NotImplemented" "NotImplementedError" "OSError"
"OverflowError" "PendingDeprecationWarning" "ReferenceError"
"RuntimeError" "RuntimeWarning" "StandardError"
"StopIteration" "SyntaxError" "SyntaxWarning" "SystemError"
"SystemExit" "TabError" "TypeError" "UnboundLocalError"
"UnicodeDecodeError" "UnicodeEncodeError" "UnicodeError"
"UnicodeTranslateError" "UnicodeWarning" "UserWarning"
"ValueError" "Warning" "ZeroDivisionError") symbol-end)
. font-lock-type-face)
(,(rx (or line-start (not (any ". \t"))) (* (any " \t")) symbol-start
(group (or
;; callable built-ins, fontified when not appearing as
;; object attributes
"abs" "all" "any" "apply" "basestring" "bool" "buffer" "callable"
"chr" "classmethod" "cmp" "coerce" "compile" "complex"
"copyright" "credits" "delattr" "dict" "dir" "divmod"
"enumerate" "eval" "execfile" "exit" "file" "filter" "float"
"frozenset" "getattr" "globals" "hasattr" "hash" "help"
"hex" "id" "input" "int" "intern" "isinstance" "issubclass"
"iter" "len" "license" "list" "locals" "long" "map" "max"
"min" "object" "oct" "open" "ord" "pow" "property" "quit"
"range" "raw_input" "reduce" "reload" "repr" "reversed"
"round" "set" "setattr" "slice" "sorted" "staticmethod"
"str" "sum" "super" "tuple" "type" "unichr" "unicode" "vars"
"xrange" "zip")) symbol-end)
(1 font-lock-builtin-face))
(,(rx symbol-start (or
;; other built-ins
"True" "False" "None" "Ellipsis"
"_" "__debug__" "__doc__" "__import__" "__name__") symbol-end)
. font-lock-builtin-face)))
(defconst python-font-lock-syntactic-keywords
;; Make outer chars of matching triple-quote sequences into generic
;; string delimiters. Fixme: Is there a better way?
;; First avoid a sequence preceded by an odd number of backslashes.
`((,(rx (not (any ?\\))
?\\ (* (and ?\\ ?\\))
(group (syntax string-quote))
(backref 1)
(group (backref 1)))
(2 ,(string-to-syntax "\""))) ; dummy
(,(rx (group (optional (any "uUrR"))) ; prefix gets syntax property
(optional (any "rR")) ; possible second prefix
(group (syntax string-quote)) ; maybe gets property
(backref 2) ; per first quote
(group (backref 2))) ; maybe gets property
(1 (python-quote-syntax 1))
(2 (python-quote-syntax 2))
(3 (python-quote-syntax 3)))
;; This doesn't really help.
;;; (,(rx (and ?\\ (group ?\n))) (1 " "))
))
(defun python-quote-syntax (n)
"Put `syntax-table' property correctly on triple quote.
Used for syntactic keywords. N is the match number (1, 2 or 3)."
;; Given a triple quote, we have to check the context to know
;; whether this is an opening or closing triple or whether it's
;; quoted anyhow, and should be ignored. (For that we need to do
;; the same job as `syntax-ppss' to be correct and it seems to be OK
;; to use it here despite initial worries.) We also have to sort
;; out a possible prefix -- well, we don't _have_ to, but I think it
;; should be treated as part of the string.
;; Test cases:
;; ur"""ar""" x=3D'"' # """
;; x =3D ''' """ ' a
;; '''
;; x '"""' x """ \"""" x
(save-excursion
(goto-char (match-beginning 0))
(cond
;; Consider property for the last char if in a fenced string.
((=3D n 3)
(let* ((font-lock-syntactic-keywords nil)
(syntax (syntax-ppss)))
(when (eq t (nth 3 syntax)) ; after unclosed fence
(goto-char (nth 8 syntax)) ; fence position
(skip-chars-forward "uUrR") ; skip any prefix
;; Is it a matching sequence?
(if (eq (char-after) (char-after (match-beginning 2)))
(eval-when-compile (string-to-syntax "|"))))))
;; Consider property for initial char, accounting for prefixes.
((or (and (=3D n 2) ; leading quote (not prefix)
(=3D (match-beginning 1) (match-end 1))) ; prefix is null
(and (=3D n 1) ; prefix
(/=3D (match-beginning 1) (match-end 1)))) ; non-empty
(let ((font-lock-syntactic-keywords nil))
(unless (eq 'string (syntax-ppss-context (syntax-ppss)))
(eval-when-compile (string-to-syntax "|")))))
;; Otherwise (we're in a non-matching string) the property is
;; nil, which is OK.
)))
;; This isn't currently in `font-lock-defaults' as probably not worth
;; it -- we basically only mess with a few normally-symbol characters.
;; (defun python-font-lock-syntactic-face-function (state)
;; "`font-lock-syntactic-face-function' for Python mode.
;; Returns the string or comment face as usual, with side effect of putting
;; a `syntax-table' property on the inside of the string or comment which is
;; the standard syntax table."
;; (if (nth 3 state)
;; (save-excursion
;; (goto-char (nth 8 state))
;; (condition-case nil
;; (forward-sexp)
;; (error nil))
;; (put-text-property (1+ (nth 8 state)) (1- (point))
;; 'syntax-table (standard-syntax-table))
;; 'font-lock-string-face)
;; (put-text-property (1+ (nth 8 state)) (line-end-position)
;; 'syntax-table (standard-syntax-table))
;; 'font-lock-comment-face))
\f
;;;; Keymap and syntax
(defvar python-mode-map
(let ((map (make-sparse-keymap)))
;; Mostly taken from python-mode.el.
(define-key map ":" 'python-electric-colon)
(define-key map "\177" 'python-backspace)
(define-key map "\C-c<" 'python-shift-left)
(define-key map "\C-c>" 'python-shift-right)
(define-key map "\C-c\C-k" 'python-mark-block)
(define-key map "\C-c\C-n" 'python-next-statement)
(define-key map "\C-c\C-p" 'python-previous-statement)
(define-key map "\C-c\C-u" 'python-beginning-of-block)
(define-key map "\C-c\C-f" 'python-describe-symbol)
(define-key map "\C-c\C-w" 'python-check)
(define-key map "\C-c\C-v" 'python-check) ; a la sgml-mode
(define-key map "\C-c\C-s" 'python-send-string)
(define-key map [?\C-\M-x] 'python-send-defun)
(define-key map "\C-c\C-r" 'python-send-region)
(define-key map "\C-c\M-r" 'python-send-region-and-go)
(define-key map "\C-c\C-c" 'python-send-buffer)
(define-key map "\C-c\C-z" 'python-switch-to-python)
(define-key map "\C-c\C-m" 'python-load-file)
(define-key map "\C-c\C-l" 'python-load-file) ; a la cmuscheme
(substitute-key-definition 'complete-symbol 'symbol-complete
map global-map)
(define-key map "\C-c\C-i" 'python-find-imports)
(define-key map "\C-c\C-t" 'python-expand-template)
(easy-menu-define python-menu map "Python Mode menu"
`("Python"
:help "Python-specific Features"
["Shift region left" python-shift-left :active mark-active
:help "Shift by a single indentation step"]
["Shift region right" python-shift-right :active mark-active
:help "Shift by a single indentation step"]
"-"
["Mark block" python-mark-block
:help "Mark innermost block around point"]
["Mark def/class" mark-defun
:help "Mark innermost definition around point"]
"-"
["Start of block" python-beginning-of-block
:help "Go to start of innermost definition around point"]
["End of block" python-end-of-block
:help "Go to end of innermost definition around point"]
["Start of def/class" beginning-of-defun
:help "Go to start of innermost definition around point"]
["End of def/class" end-of-defun
:help "Go to end of innermost definition around point"]
"-"
("Templates..."
:help "Expand templates for compound statements"
:filter (lambda (&rest junk)
(mapcar (lambda (elt)
(vector (car elt) (cdr elt) t))
python-skeletons))) ; defined later
"-"
["Start interpreter" run-python
:help "Run `inferior' Python in separate buffer"]
["Import/reload file" python-load-file
:help "Load into inferior Python session"]
["Eval buffer" python-send-buffer
:help "Evaluate buffer en bloc in inferior Python session"]
["Eval region" python-send-region :active mark-active
:help "Evaluate region en bloc in inferior Python session"]
["Eval def/class" python-send-defun
:help "Evaluate current definition in inferior Python session"]
["Switch to interpreter" python-switch-to-python
:help "Switch to inferior Python buffer"]
["Set default process" python-set-proc
:help "Make buffer's inferior process the default"
:active (buffer-live-p python-buffer)]
["Check file" python-check :help "Run pychecker"]
["Debugger" pdb :help "Run pdb under GUD"]
"-"
["Help on symbol" python-describe-symbol
:help "Use pydoc on symbol at point"]
["Complete symbol" symbol-complete
:help "Complete (qualified) symbol before point"]
["Find function" python-find-function
:help "Try to find source definition of function at point"]
["Update imports" python-find-imports
:help "Update list of top-level imports for completion"]))
map))
;; Fixme: add toolbar stuff for useful things like symbol help, send
;; region, at least. (Shouldn't be specific to Python, obviously.)
;; eric has items including: (un)indent, (un)comment, restart script,
;; run script, debug script; also things for profiling, unit testing.
(defvar python-mode-syntax-table
(let ((table (make-syntax-table)))
;; Give punctuation syntax to ASCII that normally has symbol
;; syntax or has word syntax and isn't a letter.
(let ((symbol (string-to-syntax "_"))
(sst (standard-syntax-table)))
(dotimes (i 128)
(unless (=3D i ?_)
(if (equal symbol (aref sst i))
(modify-syntax-entry i "." table)))))
(modify-syntax-entry ?$ "." table)
(modify-syntax-entry ?% "." table)
;; exceptions
(modify-syntax-entry ?# "<" table)
(modify-syntax-entry ?\n ">" table)
(modify-syntax-entry ?' "\"" table)
(modify-syntax-entry ?` "$" table)
table))
\f
;;;; Utility stuff
(defsubst python-in-string/comment ()
"Return non-nil if point is in a Python literal (a comment or string)."
;; We don't need to save the match data.
(nth 8 (syntax-ppss)))
(defconst python-space-backslash-table
(let ((table (copy-syntax-table python-mode-syntax-table)))
(modify-syntax-entry ?\\ " " table)
table)
"`python-mode-syntax-table' with backslash given whitespace syntax.")
(defun python-skip-comments/blanks (&optional backward)
"Skip comments and blank lines.
BACKWARD non-nil means go backwards, otherwise go forwards.
Backslash is treated as whitespace so that continued blank lines
are skipped. Doesn't move out of comments -- should be outside
or at end of line."
(let ((arg (if backward
;; If we're in a comment (including on the trailing
;; newline), forward-comment doesn't move backwards out
;; of it. Don't set the syntax table round this bit!
(let ((syntax (syntax-ppss)))
(if (nth 4 syntax)
(goto-char (nth 8 syntax)))
(- (point-max)))
(point-max))))
(with-syntax-table python-space-backslash-table
(forward-comment arg))))
(defun python-backslash-continuation-line-p ()
"Non-nil if preceding line ends with backslash that is not in a comment."
(and (eq ?\\ (char-before (line-end-position 0)))
(not (syntax-ppss-context (syntax-ppss)))))
(defun python-continuation-line-p ()
"Return non-nil if current line continues a previous one.
The criteria are that the previous line ends in a backslash outside
comments and strings, or that point is within brackets/parens."
(or (python-backslash-continuation-line-p)
(let ((depth (syntax-ppss-depth
(save-excursion ; syntax-ppss with arg changes point
(syntax-ppss (line-beginning-position))))))
(or (> depth 0)
(if (< depth 0) ; Unbalanced brackets -- act locally
(save-excursion
(condition-case ()
(progn (backward-up-list) t) ; actually within brackets
(error nil))))))))
(defun python-comment-line-p ()
"Return non-nil iff current line has only a comment."
(save-excursion
(end-of-line)
(when (eq 'comment (syntax-ppss-context (syntax-ppss)))
(back-to-indentation)
(looking-at (rx (or (syntax comment-start) line-end))))))
(defun python-blank-line-p ()
"Return non-nil iff current line is blank."
(save-excursion
(beginning-of-line)
(looking-at "\\s-*$")))
(defun python-beginning-of-string ()
"Go to beginning of string around point.
Do nothing if not in string."
(let ((state (syntax-ppss)))
(when (eq 'string (syntax-ppss-context state))
(goto-char (nth 8 state)))))
(defun python-open-block-statement-p (&optional bos)
"Return non-nil if statement at point opens a block.
BOS non-nil means point is known to be at beginning of statement."
(save-excursion
(unless bos (python-beginning-of-statement))
(looking-at (rx (and (or "if" "else" "elif" "while" "for" "def"
"class" "try" "except" "finally" "with")
symbol-end)))))
(defun python-close-block-statement-p (&optional bos)
"Return non-nil if current line is a statement closing a block.
BOS non-nil means point is at beginning of statement.
The criteria are that the line isn't a comment or in string and
starts with keyword `raise', `break', `continue' or `pass'."
(save-excursion
(unless bos (python-beginning-of-statement))
(back-to-indentation)
(looking-at (rx (or "return" "raise" "break" "continue" "pass")
symbol-end))))
(defun python-outdent-p ()
"Return non-nil if current line should outdent a level."
(save-excursion
(back-to-indentation)
(and (looking-at (rx (and (or "else" "finally" "except" "elif")
symbol-end)))
(not (python-in-string/comment))
;; Ensure there's a previous statement and move to it.
(zerop (python-previous-statement))
(not (python-close-block-statement-p t))
;; Fixme: check this
(not (python-open-block-statement-p)))))
\f
;;;; Indentation.
(defcustom python-indent 4
"*Number of columns for a unit of indentation in Python mode.
See also `\\[python-guess-indent]'"
:group 'python
:type 'integer)
(defcustom python-guess-indent t
"*Non-nil means Python mode guesses `python-indent' for the buffer."
:type 'boolean
:group 'python)
(defcustom python-indent-string-contents t
"*Non-nil means indent contents of multi-line strings together.
This means indent them the same as the preceding non-blank line.
Otherwise preserve their indentation.
This only applies to `doc' strings, i.e. those that form statements;
the indentation is preserved in others."
:type '(choice (const :tag "Align with preceding" t)
(const :tag "Preserve indentation" nil))
:group 'python)
(defcustom python-honour-comment-indentation nil
"Non-nil means indent relative to preceding comment line.
Only do this for comments where the leading comment character is
followed by space. This doesn't apply to comment lines, which
are always indented in lines with preceding comments."
:type 'boolean
:group 'python)
(defcustom python-continuation-offset 4
"*Number of columns of additional indentation for continuation lines.
Continuation lines follow a backslash-terminated line starting a
statement."
:group 'python
:type 'integer)
(defun python-guess-indent ()
"Guess step for indentation of current buffer.
Set `python-indent' locally to the value guessed."
(interactive)
(save-excursion
(save-restriction
(widen)
(goto-char (point-min))
(let (done indent)
(while (and (not done) (not (eobp)))
(when (and (re-search-forward (rx ?: (0+ space)
(or (syntax comment-start)
line-end))
nil 'move)
(python-open-block-statement-p))
(save-excursion
(python-beginning-of-statement)
(let ((initial (current-indentation)))
(if (zerop (python-next-statement))
(setq indent (- (current-indentation) initial)))
(if (and indent (>=3D indent 2) (<=3D indent 8)) ; sanity check
(setq done t))))))
(when done
(when (/=3D indent (default-value 'python-indent))
(set (make-local-variable 'python-indent) indent)
(unless (=3D tab-width python-indent)
(setq indent-tabs-mode nil)))
indent)))))
;; Alist of possible indentations and start of statement they would
;; close. Used in indentation cycling (below).
(defvar python-indent-list nil
"Internal use.")
;; Length of the above
(defvar python-indent-list-length nil
"Internal use.")
;; Current index into the alist.
(defvar python-indent-index nil
"Internal use.")
(defun python-calculate-indentation ()
"Calculate Python indentation for line at point."
(setq python-indent-list nil
python-indent-list-length 1)
(save-excursion
(beginning-of-line)
(let ((syntax (syntax-ppss))
start)
(cond
((eq 'string (syntax-ppss-context syntax)) ; multi-line string
(if (not python-indent-string-contents)
(current-indentation)
;; Only respect `python-indent-string-contents' in doc
;; strings (defined as those which form statements).
(if (not (save-excursion
(python-beginning-of-statement)
(looking-at (rx (or (syntax string-delimiter)
(syntax string-quote))))))
(current-indentation)
;; Find indentation of preceding non-blank line within string.
(setq start (nth 8 syntax))
(forward-line -1)
(while (and (< start (point)) (looking-at "\\s-*$"))
(forward-line -1))
(current-indentation))))
((python-continuation-line-p) ; after backslash, or bracketed
(let ((point (point))
(open-start (cadr syntax))
(backslash (python-backslash-continuation-line-p))
(colon (eq ?: (char-before (1- (line-beginning-position))))))
(if open-start
;; Inside bracketed expression.
(progn
(goto-char (1+ open-start))
;; Look for first item in list (preceding point) and
;; align with it, if found.
(if (with-syntax-table python-space-backslash-table
(let ((parse-sexp-ignore-comments t))
(condition-case ()
(progn (forward-sexp)
(backward-sexp)
(< (point) point))
(error nil))))
;; Extra level if we're backslash-continued or
;; following a key.
(if (or backslash colon)
(+ python-indent (current-column))
(current-column))
;; Otherwise indent relative to statement start, one
;; level per bracketing level.
(goto-char (1+ open-start))
(python-beginning-of-statement)
(+ (current-indentation) (* (car syntax) python-indent))))
;; Otherwise backslash-continued.
(forward-line -1)
(if (python-continuation-line-p)
;; We're past first continuation line. Align with
;; previous line.
(current-indentation)
;; First continuation line. Indent one step, with an
;; extra one if statement opens a block.
(python-beginning-of-statement)
(+ (current-indentation) python-continuation-offset
(if (python-open-block-statement-p t)
python-indent
0))))))
((bobp) 0)
;; Fixme: Like python-mode.el; not convinced by this.
((looking-at (rx (0+ space) (syntax comment-start)
(not (any " \t\n")))) ; non-indentable comment
(current-indentation))
((and python-honour-comment-indentation
;; Back over whitespace, newlines, non-indentable comments.
(catch 'done
(while (cond ((bobp) nil)
((not (forward-comment -1))
nil) ; not at comment start
;; Now at start of comment -- trailing one?
((/=3D (current-column) (current-indentation))
nil)
;; Indentable comment, like python-mode.el?
((and (looking-at (rx (syntax comment-start)
(or space line-end)))
(/=3D 0 (current-column)))
(throw 'done (current-column)))
;; Else skip it (loop).
(t))))))
(t
(python-indentation-levels)
;; Prefer to indent comments with an immediately-following
;; statement, e.g.
;; ...
;; # ...
;; def ...
(when (and (> python-indent-list-length 1)
(python-comment-line-p))
(forward-line)
(unless (python-comment-line-p)
(let ((elt (assq (current-indentation) python-indent-list)))
(setq python-indent-list
(nconc (delete elt python-indent-list)
(list elt))))))
(caar (last python-indent-list)))))))
;;;; Cycling through the possible indentations with successive TABs.
;; These don't need to be buffer-local since they're only relevant
;; during a cycle.
(defun python-initial-text ()
"Text of line following indentation and ignoring any trailing comment."
(save-excursion
(buffer-substring (progn
(back-to-indentation)
(point))
(progn
(end-of-line)
(forward-comment -1)
(point)))))
(defconst python-block-pairs
'(("else" "if" "elif" "while" "for" "try" "except")
("elif" "if" "elif")
("except" "try" "except")
("finally" "try"))
"Alist of keyword matches.
The car of an element is a keyword introducing a statement which
can close a block opened by a keyword in the cdr.")
(defun python-first-word ()
"Return first word (actually symbol) on the line."
(save-excursion
(back-to-indentation)
(current-word t)))
(defun python-indentation-levels ()
"Return a list of possible indentations for this line.
It is assumed not to be a continuation line or in a multi-line string.
Includes the default indentation and those which would close all
enclosing blocks. Elements of the list are actually pairs:
\(INDENTATION . TEXT), where TEXT is the initial text of the
corresponding block opening (or nil)."
(save-excursion
(let ((initial "")
levels indent)
;; Only one possibility immediately following a block open
;; statement, assuming it doesn't have a `suite' on the same line.
(cond
((save-excursion (and (python-previous-statement)
(python-open-block-statement-p t)
(setq indent (current-indentation))
;; Check we don't have something like:
;; if ...: ...
(if (progn (python-end-of-statement)
(python-skip-comments/blanks t)
(eq ?: (char-before)))
(setq indent (+ python-indent indent)))))
(push (cons indent initial) levels))
;; Only one possibility for comment line immediately following
;; another.
((save-excursion
(when (python-comment-line-p)
(forward-line -1)
(if (python-comment-line-p)
(push (cons (current-indentation) initial) levels)))))
;; Fixme: Maybe have a case here which indents (only) first
;; line after a lambda.
(t
(let ((start (car (assoc (python-first-word) python-block-pairs))))
(python-previous-statement)
;; Is this a valid indentation for the line of interest?
(unless (or (if start ; potentially only outdentable
;; Check for things like:
;; if ...: ...
;; else ...:
;; where the second line need not be outdented.
(not (member (python-first-word)
(cdr (assoc start
python-block-pairs)))))
;; Not sensible to indent to the same level as
;; previous `return' &c.
(python-close-block-statement-p))
(push (cons (current-indentation) (python-initial-text))
levels))
(while (python-beginning-of-block)
(when (or (not start)
(member (python-first-word)
(cdr (assoc start python-block-pairs))))
(push (cons (current-indentation) (python-initial-text))
levels))))))
(prog1 (or levels (setq levels '((0 . ""))))
(setq python-indent-list levels
python-indent-list-length (length python-indent-list))))))
;; This is basically what `python-indent-line' would be if we didn't
;; do the cycling.
(defun python-indent-line-1 (&optional leave)
"Subroutine of `python-indent-line'.
Does non-repeated indentation. LEAVE non-nil means leave
indentation if it is valid, i.e. one of the positions returned by
`python-calculate-indentation'."
(let ((target (python-calculate-indentation))
(pos (- (point-max) (point))))
(if (or (=3D target (current-indentation))
;; Maybe keep a valid indentation.
(and leave python-indent-list
(assq (current-indentation) python-indent-list)))
(if (< (current-column) (current-indentation))
(back-to-indentation))
(beginning-of-line)
(delete-horizontal-space)
(indent-to target)
(if (> (- (point-max) pos) (point))
(goto-char (- (point-max) pos))))))
(defun python-indent-line ()
"Indent current line as Python code.
When invoked via `indent-for-tab-command', cycle through possible
indentations for current line. The cycle is broken by a command
different from `indent-for-tab-command', i.e. successive TABs do
the cycling."
(interactive)
(if (and (eq this-command 'indent-for-tab-command)
(eq last-command this-command))
(if (=3D 1 python-indent-list-length)
(message "Sole indentation")
(progn (setq python-indent-index
(% (1+ python-indent-index) python-indent-list-length))
(beginning-of-line)
(delete-horizontal-space)
(indent-to (car (nth python-indent-index python-indent-list)))
(if (python-block-end-p)
(let ((text (cdr (nth python-indent-index
python-indent-list))))
(if text
(message "Closes: %s" text))))))
(python-indent-line-1)
(setq python-indent-index (1- python-indent-list-length))))
(defun python-indent-region (start end)
"`indent-region-function' for Python.
Leaves validly-indented lines alone, i.e. doesn't indent to
another valid position."
(save-excursion
(goto-char end)
(setq end (point-marker))
(goto-char start)
(or (bolp) (forward-line 1))
(while (< (point) end)
(or (and (bolp) (eolp))
(python-indent-line-1 t))
(forward-line 1))
(move-marker end nil)))
(defun python-block-end-p ()
"Non-nil if this is a line in a statement closing a block,
or a blank line indented to where it would close a block."
(and (not (python-comment-line-p))
(or (python-close-block-statement-p t)
(< (current-indentation)
(save-excursion
(python-previous-statement)
(current-indentation))))))
\f
;;;; Movement.
;; Fixme: Define {for,back}ward-sexp-function? Maybe skip units like
;; block, statement, depending on context.
(defun python-beginning-of-defun ()
"`beginning-of-defun-function' for Python.
Finds beginning of innermost nested class or method definition.
Returns the name of the definition found at the end, or nil if
reached start of buffer."
(let ((ci (current-indentation))
(def-re (rx line-start (0+ space) (or "def" "class") (1+ space)
(group (1+ (or word (syntax symbol))))))
found lep def-line)
(if (python-comment-line-p)
(setq ci most-positive-fixnum))
(while (and (not (bobp)) (not found))
;; Treat bol at beginning of function as outside function so
;; that successive C-M-a makes progress backwards.
(setq def-line (looking-at def-re))
(unless (bolp) (end-of-line))
(setq lep (line-end-position))
(if (and (re-search-backward def-re nil 'move)
;; Must be less indented or matching top level, or
;; equally indented if we started on a definition line.
(let ((in (current-indentation)))
(or (and (zerop ci) (zerop in))
(=3D lep (line-end-position)) ; on initial line
;; Not sure why it was like this -- fails in case of
;; last internal function followed by first
;; non-def statement of the main body.
;; (and def-line (=3D in ci))
(=3D in ci)
(< in ci)))
(not (python-in-string/comment)))
(setq found t)))
found))
(defun python-end-of-defun ()
"`end-of-defun-function' for Python.
Finds end of innermost nested class or method definition."
(let ((orig (point))
(pattern (rx line-start (0+ space) (or "def" "class") space)))
;; Go to start of current block and check whether it's at top
;; level. If it is, and not a block start, look forward for
;; definition statement.
(when (python-comment-line-p)
(end-of-line)
(forward-comment most-positive-fixnum))
(if (not (python-open-block-statement-p))
(python-beginning-of-block))
(if (zerop (current-indentation))
(unless (python-open-block-statement-p)
(while (and (re-search-forward pattern nil 'move)
(python-in-string/comment))) ; just loop
(unless (eobp)
(beginning-of-line)))
;; Don't move before top-level statement that would end defun.
(end-of-line)
(python-beginning-of-defun))
;; If we got to the start of buffer, look forward for
;; definition statement.
(if (and (bobp) (not (looking-at "def\\|class")))
(while (and (not (eobp))
(re-search-forward pattern nil 'move)
(python-in-string/comment)))) ; just loop
;; We're at a definition statement (or end-of-buffer).
(unless (eobp)
(python-end-of-block)
;; Count trailing space in defun (but not trailing comments).
(skip-syntax-forward " >")
(unless (eobp) ; e.g. missing final newline
(beginning-of-line)))
;; Catch pathological cases like this, where the beginning-of-defun
;; skips to a definition we're not in:
;; if ...:
;; ...
;; else:
;; ... # point here
;; ...
;; def ...
(if (< (point) orig)
(goto-char (point-max)))))
(defun python-beginning-of-statement ()
"Go to start of current statement.
Accounts for continuation lines, multi-line strings, and
multi-line bracketed expressions."
(beginning-of-line)
(python-beginning-of-string)
(let ((point (point)))
(while (and (python-continuation-line-p)
(> point (setq point (point))))
(beginning-of-line)
(if (python-backslash-continuation-line-p)
(progn
(forward-line -1)
(while (python-backslash-continuation-line-p)
(forward-line -1)))
(python-beginning-of-string)
(python-skip-out))))
(back-to-indentation))
(defun python-skip-out (&optional forward syntax)
"Skip out of any nested brackets.
Skip forward if FORWARD is non-nil, else backward.
If SYNTAX is non-nil it is the state returned by `syntax-ppss' at point.
Return non-nil iff skipping was done."
(let ((depth (syntax-ppss-depth (or syntax (syntax-ppss))))
(forward (if forward -1 1)))
(unless (zerop depth)
(if (> depth 0)
;; Skip forward out of nested brackets.
(condition-case () ; beware invalid syntax
(progn (backward-up-list (* forward depth)) t)
(error nil))
;; Invalid syntax (too many closed brackets).
;; Skip out of as many as possible.
(let (done)
(while (condition-case ()
(progn (backward-up-list forward)
(setq done t))
(error nil)))
done)))))
(defun python-end-of-statement ()
"Go to the end of the current statement and return point.
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.
On a comment line, go to end of line."
(end-of-line)
(while (let (comment)
;; Move past any enclosing strings and sexps, or stop if
;; we're in a comment.
(while (let ((s (syntax-ppss)))
(cond ((eq 'comment (syntax-ppss-context s))
(setq comment t)
nil)
((eq 'string (syntax-ppss-context s))
;; Go to start of string and skip it.
(goto-char (nth 8 s))
(condition-case () ; beware unterminated string
(progn (forward-sexp) t)
(error (goto-char (point-max))
nil)))
((python-skip-out t s))))
(end-of-line))
(unless comment
(eq ?\\ (char-before)))) ; Line continued?
(end-of-line 2)) ; Try next line.
(point))
(defun python-previous-statement (&optional count)
"Go to start of previous statement.
With argument COUNT, do it COUNT times. Stop at beginning of buffer.
Return count of statements left to move."
(interactive "p")
(unless count (setq count 1))
(if (< count 0)
(python-next-statement (- count))
(python-beginning-of-statement)
(while (and (> count 0) (not (bobp)))
(python-skip-comments/blanks t)
(python-beginning-of-statement)
(unless (bobp) (setq count (1- count))))
count))
(defun python-next-statement (&optional count)
"Go to start of next statement.
With argument COUNT, do it COUNT times. Stop at end of buffer.
Return count of statements left to move."
(interactive "p")
(unless count (setq count 1))
(if (< count 0)
(python-previous-statement (- count))
(beginning-of-line)
(let (bogus)
(while (and (> count 0) (not (eobp)) (not bogus))
(python-end-of-statement)
(python-skip-comments/blanks)
(if (eq 'string (syntax-ppss-context (syntax-ppss)))
(setq bogus t)
(unless (eobp)
(setq count (1- count))))))
count))
(defun python-beginning-of-block (&optional arg)
"Go to start of current block.
With numeric arg, do it that many times. If ARG is negative, call
`python-end-of-block' instead.
If point is on the first line of a block, use its outer block.
If current statement is in column zero, don't move and return nil.
Otherwise return non-nil."
(interactive "p")
(unless arg (setq arg 1))
(cond
((zerop arg))
((< arg 0) (python-end-of-block (- arg)))
(t
(let ((point (point)))
(if (or (python-comment-line-p)
(python-blank-line-p))
(python-skip-comments/blanks t))
(python-beginning-of-statement)
(let ((ci (current-indentation)))
(if (zerop ci)
(not (goto-char point)) ; return nil
;; Look upwards for less indented statement.
(if (catch 'done
;;; This is slower than the below.
;;; (while (zerop (python-previous-statement))
;;; (when (and (< (current-indentation) ci)
;;; (python-open-block-statement-p t))
;;; (beginning-of-line)
;;; (throw 'done t)))
(while (and (zerop (forward-line -1)))
(when (and (< (current-indentation) ci)
(not (python-comment-line-p))
;; Move to beginning to save effort in case
;; this is in string.
(progn (python-beginning-of-statement) t)
(python-open-block-statement-p t))
(beginning-of-line)
(throw 'done t)))
(not (goto-char point))) ; Failed -- return nil
(python-beginning-of-block (1- arg)))))))))
(defun python-end-of-block (&optional arg)
"Go to end of current block.
With numeric arg, do it that many times. If ARG is negative,
call `python-beginning-of-block' instead.
If current statement is in column zero and doesn't open a block,
don't move and return nil. Otherwise return t."
(interactive "p")
(unless arg (setq arg 1))
(if (< arg 0)
(python-beginning-of-block (- arg))
(while (and (> arg 0)
(let* ((point (point))
(_ (if (python-comment-line-p)
(python-skip-comments/blanks t)))
(ci (current-indentation))
(open (python-open-block-statement-p)))
(if (and (zerop ci) (not open))
(not (goto-char point))
(catch 'done
(while (zerop (python-next-statement))
(when (or (and open (<=3D (current-indentation) ci))
(< (current-indentation) ci))
(python-skip-comments/blanks t)
(beginning-of-line 2)
(throw 'done t)))))))
(setq arg (1- arg)))
(zerop arg)))
\f
;;;; Imenu.
;; For possibily speeding this up, here's the top of the ELP profile
;; for rescanning pydoc.py (2.2k lines, 90kb):
;; Function Name Call Count Elapsed Time Average =
Time
;; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
;; python-imenu-create-index 156 2.430906 0.015582=
7307
;; python-end-of-defun 155 1.2718260000 0.008205=
3290
;; python-end-of-block 155 1.1898689999 0.007676=
5741
;; python-next-statement 2970 1.024717 0.000345=
0225
;; python-end-of-statement 2970 0.4332190000 0.000145=
8649
;; python-beginning-of-defun 265 0.0918479999 0.000346=
5962
;; python-skip-comments/blanks 3125 0.0753319999 2.410...=
e-05
(defvar python-recursing)
(defun python-imenu-create-index ()
"`imenu-create-index-function' for Python.
Makes nested Imenu menus from nested `class' and `def' statements.
The nested menus are headed by an item referencing the outer
definition; it has a space prepended to the name so that it sorts
first with `imenu--sort-by-name' (though, unfortunately, sub-menus
precede it)."
(unless (boundp 'python-recursing) ; dynamically bound below
;; Normal call from Imenu.
(goto-char (point-min))
;; Without this, we can get an infloop if the buffer isn't all
;; fontified. I guess this is really a bug in syntax.el.
(if (eq font-lock-support-mode 'jit-lock-mode)
(unless (get-text-property (1- (point-max)) 'fontified)
(jit-lock-fontify-now))
(font-lock-fontify-buffer)))
(let (index-alist) ; accumulated value to return
(while (re-search-forward
(rx line-start (0+ space) ; leading space
(or (group "def") (group "class")) ; type
(1+ space) (group (1+ (or word ?_)))) ; name
nil t)
(unless (python-in-string/comment)
(let ((pos (match-beginning 0))
(name (match-string-no-properties 3)))
(if (match-beginning 2) ; def or class?
(setq name (concat "class " name)))
(save-restriction
(narrow-to-defun)
(let* ((python-recursing t)
(sublist (python-imenu-create-index)))
(if sublist
(progn (push (cons (concat " " name) pos) sublist)
(push (cons name sublist) index-alist))
(push (cons name pos) index-alist)))))))
(unless (boundp 'python-recursing)
;; Look for module variables.
(let (vars)
(goto-char (point-min))
(while (re-search-forward
(rx line-start (group (1+ (or word ?_))) (0+ space) "=3D")
nil t)
(unless (python-in-string/comment)
(push (cons (match-string 1) (match-beginning 1))
vars)))
(setq index-alist (nreverse index-alist))
(if vars
(push (cons "Module variables"
(nreverse vars))
index-alist))))
index-alist))
\f
;;;; `Electric' commands.
(defun python-electric-colon (arg)
"Insert a colon and maybe outdent the line if it is a statement like `els=
e'.
With numeric ARG, just insert that many colons. With \\[universal-argument=
],
just insert a single colon."
(interactive "*P")
(self-insert-command (if (not (integerp arg)) 1 arg))
(and (not arg)
(eolp)
(python-outdent-p)
(not (python-in-string/comment))
(> (current-indentation) (python-calculate-indentation))
(python-indent-line))) ; OK, do it
(put 'python-electric-colon 'delete-selection t)
(defun python-backspace (arg)
"Maybe delete a level of indentation on the current line.
Do so if point is at the end of the line's indentation outside
strings and comments.
Otherwise just call `backward-delete-char-untabify'.
Repeat ARG times."
(interactive "*p")
(if (or (/=3D (current-indentation) (current-column))
(bolp)
(python-continuation-line-p)
(python-in-string/comment))
(backward-delete-char-untabify arg)
;; Look for the largest valid indentation which is smaller than
;; the current indentation.
(let ((indent 0)
(ci (current-indentation))
(indents (python-indentation-levels))
initial)
(dolist (x indents)
(if (< (car x) ci)
(setq indent (max indent (car x)))))
(setq initial (cdr (assq indent indents)))
(if (> (length initial) 0)
(message "Closes %s" initial))
(delete-horizontal-space)
(indent-to indent))))
(put 'python-backspace 'delete-selection 'supersede)
\f
;;;; pychecker
(defcustom python-check-command "pychecker --stdlib"
"*Command used to check a Python file."
:type 'string
:group 'python)
(defvar python-saved-check-command nil
"Internal use.")
;; After `sgml-validate-command'.
(defun python-check (command)
"Check a Python file (default current buffer's file).
Runs COMMAND, a shell command, as if by `compile'.
See `python-check-command' for the default."
(interactive
(list (read-string "Checker command: "
(or python-saved-check-command
(concat python-check-command " "
(let ((name (buffer-file-name)))
(if name
(file-name-nondirectory name))))))))
(setq python-saved-check-command command)
(require 'compile) ;To define compilation-* variables.
(save-some-buffers (not compilation-ask-about-save) nil)
(let ((compilation-error-regexp-alist
(cons '("(\\([^,]+\\), line \\([0-9]+\\))" 1 2)
compilation-error-regexp-alist)))
(compilation-start command)))
\f
;;;; Inferior mode stuff (following cmuscheme).
;; Fixme: Make sure we can work with IPython.
(defcustom python-python-command "python"
"*Shell command to run Python interpreter.
Any arguments can't contain whitespace.
Note that IPython may not work properly; it must at least be used
with the `-cl' flag, i.e. use `ipython -cl'."
:group 'python
:type 'string)
(defcustom python-jython-command "jython"
"*Shell command to run Jython interpreter.
Any arguments can't contain whitespace."
:group 'python
:type 'string)
(defvar python-command python-python-command
"Actual command used to run Python.
May be `python-python-command' or `python-jython-command', possibly
modified by the user. Additional arguments are added when the command
is used by `run-python' et al.")
(defvar python-buffer nil
"*The current Python process buffer.
Commands that send text from source buffers to Python processes have
to choose a process to send to. This is determined by buffer-local
value of `python-buffer'. If its value in the current buffer,
i.e. both any local value and the default one, is nil, `run-python'
and commands that send to the Python process will start a new process.
Whenever \\[run-python] starts a new process, it resets the default
value of `python-buffer' to be the new process's buffer and sets the
buffer-local value similarly if the current buffer is in Python mode
or Inferior Python mode, so that source buffer stays associated with a
specific sub-process.
Use \\[python-set-proc] to set the default value from a buffer with a
local value.")
(make-variable-buffer-local 'python-buffer)
(defconst python-compilation-regexp-alist
;; FIXME: maybe these should move to compilation-error-regexp-alist-alist.
;; The first already is (for CAML), but the second isn't. Anyhow,
;; these are specific to the inferior buffer. -- fx
`((,(rx line-start (1+ (any " \t")) "File \""
(group (1+ (not (any "\"<")))) ; avoid `<stdin>' &c
"\", line " (group (1+ digit)))
1 2)
(,(rx " in file " (group (1+ not-newline)) " on line "
(group (1+ digit)))
1 2)
;; pdb stack trace
(,(rx line-start "> " (group (1+ (not (any "(\"<"))))
"(" (group (1+ digit)) ")" (1+ (not (any "("))) "()")
1 2))
"`compilation-error-regexp-alist' for inferior Python.")
(defvar inferior-python-mode-map
(let ((map (make-sparse-keymap)))
;; This will inherit from comint-mode-map.
(define-key map "\C-c\C-l" 'python-load-file)
(define-key map "\C-c\C-v" 'python-check)
;; Note that we _can_ still use these commands which send to the
;; Python process even at the prompt iff we have a normal prompt,
;; i.e. '>>> ' and not '... '. See the comment before
;; python-send-region. Fixme: uncomment these if we address that.
;; (define-key map [(meta ?\t)] 'python-complete-symbol)
;; (define-key map "\C-c\C-f" 'python-describe-symbol)
map))
;; Fixme: This should inherit some stuff from `python-mode', but I'm
;; not sure how much: at least some keybindings, like C-c C-f;
;; syntax?; font-locking, e.g. for triple-quoted strings?
(define-derived-mode inferior-python-mode comint-mode "Inferior Python"
"Major mode for interacting with an inferior Python process.
A Python process can be started with \\[run-python].
Hooks `comint-mode-hook' and `inferior-python-mode-hook' are run in
that order.
You can send text to the inferior Python process from other buffers
containing Python source.
* \\[python-switch-to-python] switches the current buffer to the Python
process buffer.
* \\[python-send-region] sends the current region to the Python process.
* \\[python-send-region-and-go] switches to the Python process buffer
after sending the text.
For running multiple processes in multiple buffers, see `run-python' and
`python-buffer'.
\\{inferior-python-mode-map}"
:group 'python
(set-syntax-table python-mode-syntax-table)
(setq mode-line-process '(":%s"))
(set (make-local-variable 'comint-input-filter) 'python-input-filter)
(add-hook 'comint-preoutput-filter-functions #'python-preoutput-filter
nil t)
;; Still required by `comint-redirect-send-command', for instance
;; (and we need to match things like `>>> ... >>> '):
(set (make-local-variable 'comint-prompt-regexp)
(rx line-start (1+ (and (or (repeat 3 (any ">.")) "(Pdb)") " "))))
(set (make-local-variable 'compilation-error-regexp-alist)
python-compilation-regexp-alist)
(compilation-shell-minor-mode 1))
(defcustom inferior-python-filter-regexp "\\`\\s-*\\S-?\\S-?\\s-*\\'"
"*Input matching this regexp is not saved on the history list.
Default ignores all inputs of 0, 1, or 2 non-blank characters."
:type 'regexp
:group 'python)
(defun python-input-filter (str)
"`comint-input-filter' function for inferior Python.
Don't save anything for STR matching `inferior-python-filter-regexp'."
(not (string-match inferior-python-filter-regexp str)))
;; Fixme: Loses with quoted whitespace.
(defun python-args-to-list (string)
(let ((where (string-match "[ \t]" string)))
(cond ((null where) (list string))
((not (=3D where 0))
(cons (substring string 0 where)
(python-args-to-list (substring string (+ 1 where)))))
(t (let ((pos (string-match "[^ \t]" string)))
(if pos (python-args-to-list (substring string pos))))))))
(defvar python-preoutput-result nil
"Data from last `_emacs_out' line seen by the preoutput filter.")
(defvar python-preoutput-continuation nil
"If non-nil, funcall this when `python-preoutput-filter' sees `_emacs_ok'=
.")
(defvar python-preoutput-leftover nil)
;; Using this stops us getting lines in the buffer like
;; >>> ... ... >>>
;; Also look for (and delete) an `_emacs_ok' string and call
;; `python-preoutput-continuation' if we get it.
(defun python-preoutput-filter (s)
"`comint-preoutput-filter-functions' function: ignore prompts not at bol."
(when python-preoutput-leftover
(setq s (concat python-preoutput-leftover s))
(setq python-preoutput-leftover nil))
(cond ((and (string-match (rx string-start (repeat 3 (any ".>"))
" " string-end)
s)
(/=3D (let ((inhibit-field-text-motion t))
(line-beginning-position))
(point)))
;; The need for this seems to be system-dependent:
(if (and (eq ?. (aref s 0)))
(accept-process-output (get-buffer-process (current-buffer)) 1))
"")
((string=3D s "_emacs_ok\n")
(when python-preoutput-continuation
(funcall python-preoutput-continuation)
(setq python-preoutput-continuation nil))
"")
((string-match "_emacs_out \\(.*\\)\n" s)
(setq python-preoutput-result (match-string 1 s))
"")
((string-match ".*\n" s)
s)
((or (eq t (compare-strings s nil nil "_emacs_ok\n" nil (length s)))
(let ((end (min (length "_emacs_out ") (length s))))
(eq t (compare-strings s nil end "_emacs_out " nil end))))
(setq python-preoutput-leftover s)
"")
(t s)))
(autoload 'comint-check-proc "comint")
(defvar python-version-checked nil)
(defun python-check-version (cmd)
"Check that CMD runs a suitable version of Python."
;; Fixme: Check on Jython.
(unless (or python-version-checked
(equal 0 (string-match (regexp-quote python-python-command)
cmd)))
(unless (shell-command-to-string cmd)
(error "Can't run Python command `%s'" cmd))
(let* ((res (shell-command-to-string (concat cmd " --version"))))
(string-match "Python \\([0-9]\\)\\.\\([0-9]\\)" res)
(unless (and (equal "2" (match-string 1 res))
(match-beginning 2)
(>=3D (string-to-number (match-string 2 res)) 2))
(error "Only Python versions >=3D 2.2 and < 3.0 supported")))
(setq python-version-checked t)))
;;;###autoload
(defun run-python (&optional cmd noshow new)
"Run an inferior Python process, input and output via buffer *Python*.
CMD is the Python command to run. NOSHOW non-nil means don't show the
buffer automatically.
Normally, if there is a process already running in `python-buffer',
switch to that buffer. Interactively, a prefix arg allows you to edit
the initial command line (default is `python-command'); `-i' etc. args
will be added to this as appropriate. A new process is started if:
one isn't running attached to `python-buffer', or interactively the
default `python-command', or argument NEW is non-nil. See also the
documentation for `python-buffer'.
Runs the hook `inferior-python-mode-hook' \(after the
`comint-mode-hook' is run). \(Type \\[describe-mode] in the process
buffer for a list of commands.)"
(interactive (if current-prefix-arg
(list (read-string "Run Python: " python-command) nil t)
(list python-command)))
(unless cmd (setq cmd python-command))
(python-check-version cmd)
(setq python-command cmd)
;; Fixme: Consider making `python-buffer' buffer-local as a buffer
;; (not a name) in Python buffers from which `run-python' &c is
;; invoked. Would support multiple processes better.
(when (or new (not (comint-check-proc python-buffer)))
(save-current-buffer
(let* ((cmdlist (append (python-args-to-list cmd) '("-i")))
(path (getenv "PYTHONPATH"))
(process-environment ; to import emacs.py
(cons (concat "PYTHONPATH=3D"
(if path (concat path path-separator))
data-directory)
process-environment))
;; Suppress use of pager for help output:
(process-connection-type nil))
(set-buffer (apply 'make-comint-in-buffer "Python"
(generate-new-buffer "*Python*")
(car cmdlist) nil (cdr cmdlist)))
(setq-default python-buffer (current-buffer))
(setq python-buffer (current-buffer)))
(accept-process-output (get-buffer-process python-buffer) 5)
(inferior-python-mode)))
(if (derived-mode-p 'python-mode)
(setq python-buffer (default-value 'python-buffer))) ; buffer-local
;; Load function definitions we need.
;; Before the preoutput function was used, this was done via -c in
;; cmdlist, but that loses the banner and doesn't run the startup
;; file. The code might be inline here, but there's enough that it
;; seems worth putting in a separate file, and it's probably cleaner
;; to put it in a module.
(python-send-string "import emacs")
;; Ensure we're at a prompt before doing anything else.
(python-send-receive "print '_emacs_out ()'")
;; Without this, help output goes into the inferior python buffer if
;; the process isn't already running.
(sit-for 1 0 t) ; Emacs 22 broke (sit-for 1 nil t)
(unless noshow (pop-to-buffer python-buffer t)))
(defun python-send-command (command)
"Like `python-send-string' but resets `compilation-shell-minor-mode'."
(when (python-check-comint-prompt)
(let ((end (marker-position (process-mark (python-proc)))))
(with-current-buffer python-buffer (goto-char (point-max)))
(compilation-forget-errors)
(python-send-string command))))
(defun python-send-region (start end)
"Send the region to the inferior Python process."
;; The region is evaluated from a temporary file. This avoids
;; problems with blank lines, which have different semantics
;; interactively and in files. It also saves the inferior process
;; buffer filling up with interpreter prompts. We need a Python
;; function to remove the temporary file when it has been evaluated
;; (though we could probably do it in Lisp with a Comint output
;; filter). This function also catches exceptions and truncates
;; tracebacks not to mention the frame of the function itself.
;;
;; The `compilation-shell-minor-mode' parsing takes care of relating
;; the reference to the temporary file to the source.
;;
;; Fixme: Write a `coding' header to the temp file if the region is
;; non-ASCII.
(interactive "r")
(let* ((f (make-temp-file "py"))
(command (format "emacs.eexecfile(%S)" f))
(orig-start (copy-marker start)))
(when (save-excursion
(goto-char start)
(/=3D 0 (current-indentation))) ; need dummy block
(save-excursion
(goto-char orig-start)
;; Wrong if we had indented code at buffer start.
(set-marker orig-start (line-beginning-position 0)))
(write-region "if True:\n" nil f nil 'nomsg))
(write-region start end f t 'nomsg)
(python-send-command command)
(with-current-buffer (process-buffer (python-proc))
;; Tell compile.el to redirect error locations in file `f' to
;; positions past marker `orig-start'. It has to be done *after*
;; `python-send-command''s call to `compilation-forget-errors'.
(compilation-fake-loc orig-start f))))
(defun python-send-string (string)
"Evaluate STRING in inferior Python process."
(interactive "sPython command: ")
(comint-send-string (python-proc) string)
(comint-send-string (python-proc) "\n\n"))
(defun python-send-buffer ()
"Send the current buffer to the inferior Python process."
(interactive)
(python-send-region (point-min) (point-max)))
;; Fixme: Try to define the function or class within the relevant
;; module, not just at top level.
(defun python-send-defun ()
"Send the current defun (class or method) to the inferior Python process."
(interactive)
(save-excursion (python-send-region (progn (beginning-of-defun) (point))
(progn (end-of-defun) (point)))))
(defun python-switch-to-python (eob-p)
"Switch to the Python process buffer, maybe starting new process.
With prefix arg, position cursor at end of buffer."
(interactive "P")
(pop-to-buffer (process-buffer (python-proc)) t) ;Runs python if needed.
(when eob-p
(push-mark)
(goto-char (point-max))))
(defun python-send-region-and-go (start end)
"Send the region to the inferior Python process.
Then switch to the process buffer."
(interactive "r")
(python-send-region start end)
(python-switch-to-python t))
(defcustom python-source-modes '(python-mode jython-mode)
"*Used to determine if a buffer contains Python source code.
If a file is loaded into a buffer that is in one of these major modes,
it is considered Python source by `python-load-file', which uses the
value to determine defaults."
:type '(repeat function)
:group 'python)
(defvar python-prev-dir/file nil
"Caches (directory . file) pair used in the last `python-load-file' comma=
nd.
Used for determining the default in the next one.")
(autoload 'comint-get-source "comint")
(defun python-load-file (file-name)
"Load a Python file FILE-NAME into the inferior Python process.
If the file has extension `.py' import or reload it as a module.
Treating it as a module keeps the global namespace clean, provides
function location information for debugging, and supports users of
module-qualified names."
(interactive (comint-get-source "Load Python file: " python-prev-dir/file
python-source-modes
t)) ; because execfile needs exact name
(comint-check-source file-name) ; Check to see if buffer needs saving.
(setq python-prev-dir/file (cons (file-name-directory file-name)
(file-name-nondirectory file-name)))
(with-current-buffer (process-buffer (python-proc)) ;Runs python if neede=
d.
;; Fixme: I'm not convinced by this logic from python-mode.el.
(python-send-command
(if (string-match "\\.py\\'" file-name)
(let ((module (file-name-sans-extension
(file-name-nondirectory file-name))))
(format "emacs.eimport(%S,%S)"
module (file-name-directory file-name)))
(format "execfile(%S)" file-name)))
(message "%s loaded" file-name)))
(defun python-proc ()
"Return the current Python process.
See variable `python-buffer'. Starts a new process if necessary."
;; Fixme: Maybe should look for another active process if there
;; isn't one for `python-buffer'.
(unless (comint-check-proc python-buffer)
(run-python nil t))
(get-buffer-process (or (if (eq major-mode 'inferior-python-mode)
(current-buffer)
python-buffer))))
(defun python-set-proc ()
"Set the default value of `python-buffer' to correspond to this buffer.
If the current buffer has a local value of `python-buffer', set the
default (global) value to that. The associated Python process is
the one that gets input from \\[python-send-region] et al when used
in a buffer that doesn't have a local value of `python-buffer'."
(interactive)
(if (local-variable-p 'python-buffer)
(setq-default python-buffer python-buffer)
(error "No local value of `python-buffer'")))
\f
;;;; Context-sensitive help.
(defconst python-dotty-syntax-table
(let ((table (copy-syntax-table python-mode-syntax-table)))
(modify-syntax-entry ?. "_" table)
table)
"Syntax table giving `.' symbol syntax.
Otherwise inherits from `python-mode-syntax-table'.")
(defvar view-return-to-alist)
(autoload 'help-buffer "help-mode")
(defvar python-imports) ; forward declaration
;; Fixme: Should this actually be used instead of info-look, i.e. be
;; bound to C-h S? [Probably not, since info-look may work in cases
;; where this doesn't.]
(defun python-describe-symbol (symbol)
"Get help on SYMBOL using `help'.
Interactively, prompt for symbol.
Symbol may be anything recognized by the interpreter's `help'
command -- e.g. `CALLS' -- not just variables in scope in the
interpreter. This only works for Python version 2.2 or newer
since earlier interpreters don't support `help'.
In some cases where this doesn't find documentation, \\[info-lookup-symbol]
will."
;; Note that we do this in the inferior process, not a separate one, to
;; ensure the environment is appropriate.
(interactive
(let ((symbol (with-syntax-table python-dotty-syntax-table
(current-word)))
(enable-recursive-minibuffers t))
(list (read-string (if symbol
(format "Describe symbol (default %s): " symbol)
"Describe symbol: ")
nil nil symbol))))
(if (equal symbol "") (error "No symbol"))
;; Ensure we have a suitable help buffer.
;; Fixme: Maybe process `Related help topics' a la help xrefs and
;; allow C-c C-f in help buffer.
(let ((temp-buffer-show-hook ; avoid xref stuff
(lambda ()
(toggle-read-only 1)
(setq view-return-to-alist
(list (cons (selected-window) help-return-method))))))
(with-output-to-temp-buffer (help-buffer)
(with-current-buffer standard-output
;; Fixme: Is this actually useful?
(help-setup-xref (list 'python-describe-symbol symbol) (interactive-p))
(set (make-local-variable 'comint-redirect-subvert-readonly) t)
(print-help-return-message))))
(comint-redirect-send-command-to-process (format "emacs.ehelp(%S, %s)"
symbol python-imports)
"*Help*" (python-proc) nil nil))
(add-to-list 'debug-ignored-errors "^No symbol")
(defun python-send-receive (string)
"Send STRING to inferior Python (if any) and return result.
The result is what follows `_emacs_out' in the output (or nil).
This is a no-op if `python-check-comint-prompt' returns nil."
(let ((proc (python-proc)))
(when (python-check-comint-prompt proc)
;; We typically lose if the inferior isn't in the normal REPL,
;; e.g. prompt is `help> ' or `(Pdb)'. It actually needs to be
;; `>>> ', not `... ', i.e. we're not inputting a block &c.
;; This may not be the place to check it, e.g. we might actually
;; want to send commands having set up such a state, but
;; currently it's OK for all uses.
(python-send-string string)
(setq python-preoutput-result nil)
(while (progn
(accept-process-output proc 5)
python-preoutput-leftover))
python-preoutput-result)))
(defun python-check-comint-prompt (&optional proc)
"Return non-nil iff there's a normal prompt in the inferior buffer.
If there isn't, it's probably not appropriate to send input to return
Eldoc information etc. If PROC is non-nil, check the buffer for that
process."
(with-current-buffer (process-buffer (or proc (python-proc)))
(save-excursion
(save-match-data (re-search-backward ">>> \\=3D" nil t)))))
;; Fixme: Is there anything reasonable we can do with random methods?
;; (Currently only works with functions.)
(defun python-eldoc-function ()
"`eldoc-print-current-symbol-info' for Python.
Only works when point is in a function name, not its arg list, for
instance. Assumes an inferior Python is running."
(let ((symbol (with-syntax-table python-dotty-syntax-table
(current-word))))
;; First try the symbol we're on.
(or (and symbol
(python-send-receive (format "emacs.eargs(%S, %s)"
symbol python-imports)))
;; Try moving to symbol before enclosing parens.
(let ((s (syntax-ppss)))
(unless (zerop (car s))
(when (eq ?\( (char-after (nth 1 s)))
(save-excursion
(goto-char (nth 1 s))
(skip-syntax-backward "-")
(let ((point (point)))
(skip-chars-backward "a-zA-Z._")
(if (< (point) point)
(python-send-receive
(format "emacs.eargs(%S, %s)"
(buffer-substring-no-properties (point) point)
python-imports)))))))))))
\f
;;;; Info-look functionality.
(autoload 'Info-goto-node "info")
(defun python-after-info-look ()
"Set up info-look for Python.
Used with `eval-after-load'."
(let* ((version (let ((s (shell-command-to-string (concat python-command
" -V"))))
(string-match "^Python \\([0-9]+\\.[0-9]+\\>\\)" s)
(match-string 1 s)))
;; Whether info files have a Python version suffix, e.g. in Debian.
(versioned
(with-temp-buffer
(Info-mode)
(condition-case ()
;; Don't use `info' because it would pop-up a *info* buffer.
(progn (Info-goto-node (format "(python%s-lib)Miscellaneous Index"
version))
t)
(error nil)))))
(info-lookup-maybe-add-help
:mode 'python-mode
:regexp "[[:alnum:]_]+"
:doc-spec
;; Fixme: Can this reasonably be made specific to indices with
;; different rules? Is the order of indices optimal?
;; (Miscellaneous in -ref first prefers lookup of keywords, for
;; instance.)
(if versioned
;; The empty prefix just gets us highlighted terms.
`((,(concat "(python" version "-ref)Miscellaneous Index") nil "")
(,(concat "(python" version "-ref)Module Index" nil ""))
(,(concat "(python" version "-ref)Function-Method-Variable Index"
nil ""))
(,(concat "(python" version "-ref)Class-Exception-Object Index"
nil ""))
(,(concat "(python" version "-lib)Module Index" nil ""))
(,(concat "(python" version "-lib)Class-Exception-Object Index"
nil ""))
(,(concat "(python" version "-lib)Function-Method-Variable Index"
nil ""))
(,(concat "(python" version "-lib)Miscellaneous Index" nil "")))
'(("(python-ref)Miscellaneous Index" nil "")
("(python-ref)Module Index" nil "")
("(python-ref)Function-Method-Variable Index" nil "")
("(python-ref)Class-Exception-Object Index" nil "")
("(python-lib)Module Index" nil "")
("(python-lib)Class-Exception-Object Index" nil "")
("(python-lib)Function-Method-Variable Index" nil "")
("(python-lib)Miscellaneous Index" nil ""))))))
(eval-after-load "info-look" '(python-after-info-look))
\f
;;;; Miscellany.
(defcustom python-jython-packages '("java" "javax" "org" "com")
"Packages implying `jython-mode'.
If these are imported near the beginning of the buffer, `python-mode'
actually punts to `jython-mode'."
:type '(repeat string)
:group 'python)
;; Called from `python-mode', this causes a recursive call of the
;; mode. See logic there to break out of the recursion.
(defun python-maybe-jython ()
"Invoke `jython-mode' if the buffer appears to contain Jython code.
The criterion is either a match for `jython-mode' via
`interpreter-mode-alist' or an import of a module from the list
`python-jython-packages'."
;; The logic is taken from python-mode.el.
(save-excursion
(save-restriction
(widen)
(goto-char (point-min))
(let ((interpreter (if (looking-at auto-mode-interpreter-regexp)
(match-string 2))))
(if (and interpreter (eq 'jython-mode
(cdr (assoc (file-name-nondirectory
interpreter)
interpreter-mode-alist))))
(jython-mode)
(if (catch 'done
(while (re-search-forward
(rx line-start (or "import" "from") (1+ space)
(group (1+ (not (any " \t\n.")))))
(+ (point-min) 10000) ; Probably not worth customizing.
t)
(if (member (match-string 1) python-jython-packages)
(throw 'done t))))
(jython-mode)))))))
(defun python-fill-paragraph (&optional justify)
"`fill-paragraph-function' handling multi-line strings and possibly comme=
nts.
If any of the current line is in or at the end of a multi-line string,
fill the string or the paragraph of it that point is in, preserving
the string's indentation."
(interactive "P")
(or (fill-comment-paragraph justify)
(save-excursion
(end-of-line)
(let* ((syntax (syntax-ppss))
(orig (point))
start end)
(cond ((nth 4 syntax) ; comment. fixme: loses with trailing one
(let (fill-paragraph-function)
(fill-paragraph justify)))
;; The `paragraph-start' and `paragraph-separate'
;; variables don't allow us to delimit the last
;; paragraph in a multi-line string properly, so narrow
;; to the string and then fill around (the end of) the
;; current line.
((eq t (nth 3 syntax)) ; in fenced string
(goto-char (nth 8 syntax)) ; string start
(setq start (line-beginning-position))
(condition-case () ; for unbalanced quotes
(progn (forward-sexp)
(setq end (- (point) 3)))
(error (setq end (point-max)))))
((re-search-backward "\\s|\\s-*\\=3D" nil t) ; end of fenced string
(forward-char)
(setq end (point))
(condition-case ()
(progn (backward-sexp)
(setq start (line-beginning-position)))
(error nil))))
(when end
(save-restriction
(narrow-to-region start end)
(goto-char orig)
;; Avoid losing leading and trailing newlines in doc
;; strings written like:
;; """
;; ...
;; """
(let ((paragraph-separate
;; Note that the string could be part of an
;; expression, so it can have preceding and
;; trailing non-whitespace.
(concat
(rx (or
;; Opening triple quote without following text.
(and (* nonl)
(group (syntax string-delimiter))
(repeat 2 (backref 1))
;; Fixme: Not sure about including
;; trailing whitespace.
(* (any " \t"))
eol)
;; Closing trailing quote without preceding text.
(and (group (any ?\" ?')) (backref 2)
(syntax string-delimiter))))
"\\(?:" paragraph-separate "\\)"))
fill-paragraph-function)
(fill-paragraph justify))))))) t)
(defun python-shift-left (start end &optional count)
"Shift lines in region COUNT (the prefix arg) columns to the left.
COUNT defaults to `python-indent'. If region isn't active, just shift
current line. The region shifted includes the lines in which START and
END lie. It is an error if any lines in the region are indented less than
COUNT columns."
(interactive (if mark-active
(list (region-beginning) (region-end) current-prefix-arg)
(list (point) (point) current-prefix-arg)))
(if count
(setq count (prefix-numeric-value count))
(setq count python-indent))
(when (> count 0)
(save-excursion
(goto-char start)
(while (< (point) end)
(if (and (< (current-indentation) count)
(not (looking-at "[ \t]*$")))
(error "Can't shift all lines enough"))
(forward-line))
(indent-rigidly start end (- count)))))
(add-to-list 'debug-ignored-errors "^Can't shift all lines enough")
(defun python-shift-right (start end &optional count)
"Shift lines in region COUNT (the prefix arg) columns to the right.
COUNT defaults to `python-indent'. If region isn't active, just shift
current line. The region shifted includes the lines in which START and
END lie."
(interactive (if mark-active
(list (region-beginning) (region-end) current-prefix-arg)
(list (point) (point) current-prefix-arg)))
(if count
(setq count (prefix-numeric-value count))
(setq count python-indent))
(indent-rigidly start end count))
(defun python-outline-level ()
"`outline-level' function for Python mode.
The level is the number of `python-indent' steps of indentation
of current line."
(1+ (/ (current-indentation) python-indent)))
;; Fixme: Consider top-level assignments, imports, &c.
(defun python-current-defun ()
"`add-log-current-defun-function' for Python."
(save-excursion
;; Move up the tree of nested `class' and `def' blocks until we
;; get to zero indentation, accumulating the defined names.
(let ((progress t)
accum beg)
(while (and progress (or (not beg) (> (current-indentation) 0)))
(python-beginning-of-block)
(end-of-line)
(beginning-of-defun)
(if beg
(setq progress (< (point) beg)))
(when progress
(if (looking-at (rx (0+ space) (or "def" "class") (1+ space)
(group (1+ (or word (syntax symbol))))))
;; -no-properties not correct (e.g. composition), but
;; consistent with `add-log-current-defun'
(push (match-string-no-properties 1) accum)))
(setq beg (point)))
(if accum (mapconcat 'identity accum ".")))))
(defun python-mark-block ()
"Mark the block around point.
Uses `python-beginning-of-block', `python-end-of-block'."
(interactive)
(push-mark)
(python-beginning-of-block)
(push-mark (point) nil t)
(python-end-of-block)
(exchange-point-and-mark))
;; Fixme: Provide a find-function-like command to find source of a
;; definition (separate from BicycleRepairMan). Complicated by
;; finding the right qualified name.
\f
;;;; Completion.
(defvar python-imports nil
"String of top-level import statements updated by `python-find-imports'.")
(make-variable-buffer-local 'python-imports)
;; Fixme: Should font-lock try to run this when it deals with an import?
;; Maybe not a good idea if it gets run multiple times when the
;; statement is being edited, and is more likely to end up with
;; something syntactically incorrect.
;; However, what we should do is to trundle up the block tree from point
;; to extract imports that appear to be in scope, and add those.
(defun python-find-imports ()
"Find top-level imports, updating `python-imports'."
(interactive)
(save-excursion
(let (lines)
(goto-char (point-min))
(while (re-search-forward "^import\\>\\|^from\\>" nil t)
(unless (syntax-ppss-context (syntax-ppss))
(let ((start (line-beginning-position)))
;; Skip over continued lines.
(while (and (eq ?\\ (char-before (line-end-position)))
(=3D 0 (forward-line 1)))
t)
(push (buffer-substring start (line-beginning-position 2))
lines))))
(setq python-imports
(if lines
(apply #'concat
;; This is probably best left out since you're unlikely to need the
;; doc for a function in the buffer and the import will lose if the
;; Python sub-process' working directory isn't the same as the
;; buffer's.
;; (if buffer-file-name
;; (concat
;; "import "
;; (file-name-sans-extension
;; (file-name-nondirectory buffer-file-name))))
(nreverse lines))
"None"))
(when lines
(set-text-properties 0 (length python-imports) nil python-imports)
;; The output ends up in the wrong place if the string we
;; send contains newlines (from the imports).
(setq python-imports
(replace-regexp-in-string "\n" "\\n"
(format "%S" python-imports) t t))))))
;; Fixme: This fails the first time if the sub-process isn't already
;; running. Presumably a timing issue with i/o to the process.
(defun python-symbol-completions (symbol)
"Return a list of completions of the string SYMBOL from Python process.
The list is sorted.
Uses `python-imports' to load modules against which to complete."
(when symbol
(let ((completions
(condition-case ()
(car (read-from-string
(python-send-receive
(format "emacs.complete(%S,%s)" symbol python-imports))))
(error nil))))
(sort
;; We can get duplicates from the above -- don't know why.
(delete-dups completions)
#'string<))))
(defun python-partial-symbol ()
"Return the partial symbol before point (for completion)."
(let ((end (point))
(start (save-excursion
(and (re-search-backward
(rx (or buffer-start (regexp "[^[:alnum:]._]"))
(group (1+ (regexp "[[:alnum:]._]"))) point)
nil t)
(match-beginning 1)))))
(if start (buffer-substring-no-properties start end))))
\f
;;;; FFAP support
(defun python-module-path (module)
"Function for `ffap-alist' to return path to MODULE."
(python-send-receive (format "emacs.modpath (%S)" module)))
(eval-after-load "ffap"
'(push '(python-mode . python-module-path) ffap-alist))
\f
;;;; Find-function support
;; Fixme: key binding?
(defun python-find-function (name)
"Find source of definition of function NAME.
Interactively, prompt for name."
(interactive
(let ((symbol (with-syntax-table python-dotty-syntax-table
(current-word)))
(enable-recursive-minibuffers t))
(list (read-string (if symbol
(format "Find location of (default %s): " symbol)
"Find location of: ")
nil nil symbol))))
(unless python-imports
(error "Not called from buffer visiting Python file"))
(let* ((loc (python-send-receive (format "emacs.location_of (%S, %s)"
name python-imports)))
(loc (car (read-from-string loc)))
(file (car loc))
(line (cdr loc)))
(unless file (error "Don't know where `%s' is defined" name))
(pop-to-buffer (find-file-noselect file))
(when (integerp line)
(goto-line line))))
\f
;;;; Skeletons
(defvar python-skeletons nil
"Alist of named skeletons for Python mode.
Elements are of the form (NAME . EXPANDER-FUNCTION).")
(defvar python-mode-abbrev-table nil
"Abbrev table for Python mode.
The default contents correspond to the elements of `python-skeletons'.")
(define-abbrev-table 'python-mode-abbrev-table ())
(eval-when-compile
;; Define a user-level skeleton and add it to `python-skeletons' and
;; the abbrev table.
(defmacro def-python-skeleton (name &rest elements)
(let* ((name (symbol-name name))
(function (intern (concat "python-insert-" name))))
`(progn
(add-to-list 'python-skeletons ',(cons name function))
;; Usual technique for inserting a skeleton, but expand
;; to the original abbrev instead if in a comment or string.
(define-abbrev python-mode-abbrev-table ,name ""
;; Quote this to give a readable abbrev table.
'(lambda ()
(if (python-in-string/comment)
(insert ,name)
(,function)))
nil t) ; system abbrev
(define-skeleton ,function
,(format "Insert Python \"%s\" template." name)
,@elements)))))
(put 'def-python-skeleton 'lisp-indent-function 2)
;; From `skeleton-further-elements' set below:
;; `<': outdent a level;
;; `^': delete indentation on current line and also previous newline.
;; Not quite like `delete-indentation'. Assumes point is at
;; beginning of indentation.
(def-python-skeleton if
"Condition: "
"if " str ":" \n
> -1 ; Fixme: I don't understand the spurious space this removes.
_ \n
("other condition, %s: "
< ; Avoid wrong indentation after block opening.
"elif " str ":" \n
> _ \n nil)
'(python-else) | ^)
(define-skeleton python-else
"Auxiliary skeleton."
nil
(unless (eq ?y (read-char "Add `else' clause? (y for yes or RET for no) "=
))
(signal 'quit t))
< "else:" \n
> _ \n)
(def-python-skeleton while
"Condition: "
"while " str ":" \n
> -1 _ \n
'(python-else) | ^)
(def-python-skeleton for
"Target, %s: "
"for " str " in " (skeleton-read "Expression, %s: ") ":" \n
> -1 _ \n
'(python-else) | ^)
(def-python-skeleton try/except
nil
"try:" \n
> -1 _ \n
("Exception, %s: "
< "except " str '(python-target) ":" \n
> _ \n nil)
< "except:" \n
> _ \n
'(python-else) | ^)
(define-skeleton python-target
"Auxiliary skeleton."
"Target, %s: " ", " str | -2)
(def-python-skeleton try/finally
nil
"try:" \n
> -1 _ \n
< "finally:" \n
> _ \n)
(def-python-skeleton def
"Name: "
"def " str " (" ("Parameter, %s: " (unless (equal ?\( (char-before)) ", ")
str) "):" \n
"\"\"\"" - "\"\"\"" \n ; Fixme: extra space inserted -- why?).
> _ \n)
(def-python-skeleton class
"Name: "
"class " str " (" ("Inheritance, %s: "
(unless (equal ?\( (char-before)) ", ")
str)
& ")" | -2 ; close list or remove opening
":" \n
"\"\"\"" - "\"\"\"" \n
> _ \n)
(defvar python-default-template "if"
"Default template to expand by `python-expand-template'.
Updated on each expansion.")
(defun python-expand-template (name)
"Expand template named NAME.
Interactively, prompt for the name with completion."
(interactive
(list (completing-read (format "Template to expand (default %s): "
python-default-template)
python-skeletons nil t)))
(if (equal "" name)
(setq name python-default-template)
(setq python-default-template name))
(let ((func (cdr (assoc name python-skeletons))))
(if func
(funcall func)
(error "Undefined template: %s" name))))
\f
;;;; Bicycle Repair Man support
(autoload 'pymacs-load "pymacs" nil t)
(autoload 'brm-init "bikemacs")
;; I'm not sure how useful BRM really is, and it's certainly dangerous
;; the way it modifies files outside Emacs... Also note that the
;; current BRM loses with tabs used for indentation -- I submitted a
;; fix <URL:http://www.loveshack.ukfsn.org/emacs/bikeemacs.py.diff>.
(defun python-setup-brm ()
"Set up Bicycle Repair Man refactoring tool (if available).
Note that the `refactoring' features change files independently of
Emacs and may modify and save the contents of the current buffer
without confirmation."
(interactive)
(condition-case data
(unless (fboundp 'brm-rename)
(pymacs-load "bikeemacs" "brm-") ; first line of normal recipe
(let ((py-mode-map (make-sparse-keymap)) ; it assumes this
(features (cons 'python-mode features))) ; and requires this
(brm-init) ; second line of normal recipe
(remove-hook 'python-mode-hook ; undo this from `brm-init'
'(lambda () (easy-menu-add brm-menu)))
(easy-menu-define
python-brm-menu python-mode-map
"Bicycle Repair Man"
'("BicycleRepairMan"
:help "Interface to navigation and refactoring tool"
"Queries"
["Find References" brm-find-references
:help "Find references to name at point in compilation buffer"]
["Find Definition" brm-find-definition
:help "Find definition of name at point"]
"-"
"Refactoring"
["Rename" brm-rename
:help "Replace name at point with a new name everywhere"]
["Extract Method" brm-extract-method
:active (and mark-active (not buffer-read-only))
:help "Replace statements in region with a method"]
["Extract Local Variable" brm-extract-local-variable
:active (and mark-active (not buffer-read-only))
:help "Replace expression in region with an assignment"]
["Inline Local Variable" brm-inline-local-variable
:help
"Substitute uses of variable at point with its definition"]
;; Fixme: Should check for anything to revert.
["Undo Last Refactoring" brm-undo :help ""]))))
(error (error "BicycleRepairMan setup failed: %s" data))))
\f
;;;; Modes.
(defvar outline-heading-end-regexp)
(defvar eldoc-documentation-function)
;; Stuff to allow expanding abbrevs with non-word constituents.
(defun python-abbrev-pc-hook ()
"Reset the syntax table after possibly expanding abbrevs."
(remove-hook 'post-command-hook 'python-abbrev-pc-hook t)
(set-syntax-table python-mode-syntax-table))
(defvar python-abbrev-syntax-table
(copy-syntax-table python-mode-syntax-table)
"Syntax table used when expanding abbrevs.")
(defun python-pea-hook ()
"Set the syntax table before possibly expanding abbrevs."
(set-syntax-table python-abbrev-syntax-table)
(add-hook 'post-command-hook 'python-abbrev-pc-hook nil t))
(modify-syntax-entry ?/ "w" python-abbrev-syntax-table)
;;;###autoload
(define-derived-mode python-mode fundamental-mode "Python"
"Major mode for editing Python files.
Turns on Font Lock mode unconditionally since it is currently required
for correct parsing of the source.
See also `jython-mode', which is actually invoked if the buffer appears to
contain Jython code. See also `run-python' and associated Python mode
commands for running Python under Emacs.
The Emacs commands which work with `defun's, e.g. \\[beginning-of-defun], d=
eal
with nested `def' and `class' blocks. They take the innermost one as
current without distinguishing method and class definitions. Used multiple
times, they move over others at the same indentation level until they reach
the end of definitions at that level, when they move up a level.
\\<python-mode-map>
Colon is electric: it outdents the line if appropriate, e.g. for
an else statement. \\[python-backspace] at the beginning of an indented st=
atement
deletes a level of indentation to close the current block; otherwise it
deletes a character backward. TAB indents the current line relative to
the preceding code. Successive TABs, with no intervening command, cycle
through the possibilities for indentation on the basis of enclosing blocks.
\\[fill-paragraph] fills comments and multi-line strings appropriately, but=
has no
effect outside them.
Supports Eldoc mode (only for functions, using a Python process),
Info-Look and Imenu. In Outline minor mode, `class' and `def'
lines count as headers. Symbol completion is available in the
same way as in the Python shell using the `rlcompleter' module
and this is added to the Hippie Expand functions locally if
Hippie Expand mode is turned on. Completion of symbols of the
form x.y only works if the components are literal
module/attribute names, not variables. An abbrev table is set up
with skeleton expansions for compound statement templates.
\\{python-mode-map}"
:group 'python
(set (make-local-variable 'font-lock-defaults)
'(python-font-lock-keywords nil nil nil nil
(font-lock-syntactic-keywords
. python-font-lock-syntactic-keywords)
;; This probably isn't worth it.
;; (font-lock-syntactic-face-function
;; . python-font-lock-syntactic-face-function)
))
(set (make-local-variable 'parse-sexp-lookup-properties) t)
(set (make-local-variable 'comment-start) "# ")
(set (make-local-variable 'indent-line-function) #'python-indent-line)
(set (make-local-variable 'indent-region-function) #'python-indent-region)
(set (make-local-variable 'paragraph-start) "\\s-*$")
(set (make-local-variable 'fill-paragraph-function) 'python-fill-paragrap=
h)
(set (make-local-variable 'require-final-newline) mode-require-final-newl=
ine)
(set (make-local-variable 'add-log-current-defun-function)
#'python-current-defun)
(set (make-local-variable 'outline-regexp)
(rx (* space) (or "class" "def" "elif" "else" "except" "finally"
"for" "if" "try" "while" "with")
symbol-end))
(set (make-local-variable 'outline-heading-end-regexp) ":\\s-*\n")
(set (make-local-variable 'outline-level) #'python-outline-level)
(set (make-local-variable 'open-paren-in-column-0-is-defun-start) nil)
(make-local-variable 'python-saved-check-command)
(set (make-local-variable 'beginning-of-defun-function)
'python-beginning-of-defun)
(set (make-local-variable 'end-of-defun-function) 'python-end-of-defun)
(setq imenu-create-index-function #'python-imenu-create-index)
(set (make-local-variable 'eldoc-documentation-function)
#'python-eldoc-function)
(add-hook 'eldoc-mode-hook
'(lambda () (run-python nil t)) ; need it running
nil t)
(set (make-local-variable 'symbol-completion-symbol-function)
'python-partial-symbol)
(set (make-local-variable 'symbol-completion-completions-function)
'python-symbol-completions)
;; This was added in Emacs, but seems to be of limited use since it
;; isn't (can't be) indentation-based. Also hide-level doesn't seem
;; to work properly.
(add-to-list 'hs-special-modes-alist
`(python-mode "^\\s-*\\(?:def\\|class\\)\\>" nil "#"
,(lambda (arg)
(python-end-of-defun)
(skip-chars-backward " \t\n"))
nil))
(set (make-local-variable 'skeleton-further-elements)
'((< '(backward-delete-char-untabify (min python-indent
(current-column))))
(^ '(- (1+ (current-indentation))))))
(add-hook 'pre-abbrev-expand-hook 'python-pea-hook nil t)
(if (featurep 'hippie-exp)
(set (make-local-variable 'hippie-expand-try-functions-list)
(cons 'symbol-completion-try-complete
hippie-expand-try-functions-list)))
(unless font-lock-mode (font-lock-mode 1))
(when python-guess-indent (python-guess-indent))
(set (make-local-variable 'python-command) python-python-command)
(python-find-imports)
(unless (boundp 'python-mode-running) ; kill the recursion from jython-mo=
de
(let ((python-mode-running t))
(python-maybe-jython))))
;; Not done automatically in Emacs 21 or 22.
(defcustom python-mode-hook nil
"Hook run when entering Python mode."
:group 'python
:type 'hook)
(custom-add-option 'python-mode-hook 'imenu-add-menubar-index)
(custom-add-option 'python-mode-hook
'(lambda ()
"Turn off Indent Tabs mode."
(setq indent-tabs-mode nil)))
(custom-add-option 'python-mode-hook 'turn-on-eldoc-mode)
(custom-add-option 'python-mode-hook 'abbrev-mode)
(custom-add-option 'python-mode-hook 'python-setup-brm)
;;;###autoload
(define-derived-mode jython-mode python-mode "Jython"
"Major mode for editing Jython files.
Like `python-mode', but sets up parameters for Jython subprocesses.
Runs `jython-mode-hook' after `python-mode-hook'."
:group 'python
(set (make-local-variable 'python-command) python-jython-command))
(provide 'python)
(provide 'python-21)
;;; python.el ends here
- --bluebird-explosion-Lon-Horiuchi-bootleg-csim
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=sym-comp.el
Content-Transfer-Encoding: quoted-printable
;;; sym-comp.el --- mode-dependent symbol completion
;; Copyright (C) 2004 Dave Love
;; Author: Dave Love <fx@gnu.org>
;; Keywords: extensions
;; $Revision: 1.2 $
;; URL: http://www.loveshack.ukfsn.org/emacs
;; This file 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, or (at your option)
;; any later version.
;; This file 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 GNU Emacs; see the file COPYING. If not, write to
;; the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
;;; Commentary:
;; This defines `symbol-complete', which is a generalization of the
;; old `lisp-complete-symbol'. It provides the following hooks to
;; allow major modes to set up completion appropriate for the mode:
;; `symbol-completion-symbol-function',
;; `symbol-completion-completions-function',
;; `symbol-completion-predicate-function',
;; `symbol-completion-transform-function'. Typically it is only
;; necessary for a mode to set
;; `symbol-completion-completions-function' locally and to bind
;; `symbol-complete' appropriately.
;; It's unfortunate that there doesn't seem to be a good way of
;; combining this with `complete-symbol'.
;; There is also `symbol-completion-try-complete', for use with
;; Hippie-exp.
;; As an example, `lisp-complete-symbol' is defined below using this
;; infrastructure to replace the old one from lisp.el with the same
;; functionality.
;;; Code:
;;;; Mode-dependent symbol completion.
(defun symbol-completion-symbol ()
"Default `symbol-completion-symbol-function'.
Uses `current-word' with the buffer narrowed to the part before
point."
(save-restriction
;; Narrow in case point is in the middle of a symbol -- we want
;; just the preceeding part.
(narrow-to-region (point-min) (point))
(current-word)))
(defvar symbol-completion-symbol-function 'symbol-completion-symbol
"Function to return a partial symbol before point for completion.
The value it returns should be a string (or nil).
Major modes may set this locally if the default isn't appropriate.")
(defvar symbol-completion-completions-function nil
"Function to return possible symbol completions.
It takes an argument which is the string to be completed and
returns a value suitable for the second argument of
`try-completion'. This value need not use the argument, i.e. it
may be all possible completions, such as `obarray' in the case of
Emacs Lisp.
Major modes may set this locally to allow them to support
`symbol-complete'. See also `symbol-completion-symbol-function',
`symbol-completion-predicate-function' and
`symbol-completion-transform-function'.")
(defvar symbol-completion-predicate-function nil
"If non-nil, function to return a predicate for selecting symbol completi=
ons.
The function gets two args, the positions of the beginning and
end of the symbol to be completed.
Major modes may set this locally if the default isn't
appropriate. This is a function returning a predicate so that
the predicate can be context-dependent, e.g. to select only
function names if point is at a function call position. The
function's args may be useful for determining the context.")
(defvar symbol-completion-transform-function nil
"If non-nil, function to transform symbols in the symbol-completion buffe=
r.
E.g., for Lisp, it may annotate the symbol as being a function,
not a variable.
The function takes the symbol name as argument. If it needs to
annotate this, it should return a value suitable as an element of
the list passed to `display-completion-list'.
The predicate being used for selecting completions (from
`symbol-completion-predicate-function') is available
dynamically-bound as `symbol-completion-predicate' in case the
transform needs it.")
(defvar displayed-completions)
;;;###autoload
(defun symbol-complete (&optional predicate)
"Perform completion of the symbol preceding point.
This is done in a way appropriate to the current major mode,
perhaps by interrogating an inferior interpreter. Compare
`complete-symbol'.
If no characters can be completed, display a list of possible completions.
Repeating the command at that point scrolls the list.
When called from a program, optional arg PREDICATE is a predicate
determining which symbols are considered.
This function requires `symbol-completion-completions-function'
to be set buffer-locally. Variables `symbol-completion-symbol-function',
`symbol-completion-predicate-function' and
`symbol-completion-transform-function' are also consulted."
(interactive)
;; Fixme: Punt to `complete-symbol' in this case?
(unless (functionp symbol-completion-completions-function)
(error "symbol-completion-completions-function not defined"))
(let ((window (get-buffer-window "*Completions*")))
(let* ((pattern (or (funcall symbol-completion-symbol-function)
(error "No preceding symbol to complete")))
(predicate (or predicate
(if symbol-completion-predicate-function
(funcall symbol-completion-predicate-function
(- (point) (length pattern))
(point)))))
(completions (funcall symbol-completion-completions-function
pattern))
(completion (try-completion pattern completions predicate)))
;; If this command was repeated, and there's a fresh completion
;; window with a live buffer and a displayed completion list
;; matching the current completions, then scroll the window.
(unless (and (eq last-command this-command)
window (window-live-p window) (window-buffer window)
(buffer-name (window-buffer window))
(with-current-buffer (window-buffer window)
(if (equal displayed-completions
(all-completions pattern completions predicate))
(progn
(if (pos-visible-in-window-p (point-max) window)
(set-window-start window (point-min))
(save-selected-window
(select-window window)
(scroll-up)))
t))))
;; Otherwise, do completion.
(cond ((eq completion t))
((null completion)
(message "Can't find completion for \"%s\"" pattern)
(ding))
((not (string=3D pattern completion))
(delete-region (- (point) (length pattern)) (point))
(insert completion))
(t
(message "Making completion list...")
(let* ((list (all-completions pattern completions predicate))
;; In case the transform needs to access it.
(symbol-completion-predicate predicate)
;; Copy since list is side-effected by sorting.
(copy (copy-sequence list)))
(setq list (sort list 'string<))
(if (functionp symbol-completion-transform-function)
(setq list
(mapcar (funcall
symbol-completion-transform-function)
list)))
(with-output-to-temp-buffer "*Completions*"
(condition-case ()
(display-completion-list list pattern) ; Emacs 22
(error (display-completion-list list))))
;; Record the list for determining whether to scroll
;; (above).
(with-current-buffer "*Completions*"
(set (make-local-variable 'displayed-completions) copy)))
(message "Making completion list...%s" "done")))))))
\f
(eval-when-compile (require 'hippie-exp))
;;;###autoload
(defun symbol-completion-try-complete (old)
"Completion function for use with `hippie-expand'.
Uses `symbol-completion-symbol-function' and
`symbol-completion-completions-function'. It is intended to be
used something like this in a major mode which provides symbol
completion:
(if (featurep 'hippie-exp)
(set (make-local-variable 'hippie-expand-try-functions-list)
(cons 'symbol-completion-try-complete
hippie-expand-try-functions-list)))"
(when (and symbol-completion-symbol-function
symbol-completion-completions-function)
(unless old
(let ((symbol (funcall symbol-completion-symbol-function)))
(he-init-string (- (point) (length symbol)) (point))
(if (not (he-string-member he-search-string he-tried-table))
(push he-search-string he-tried-table))
(setq he-expand-list
(and symbol
(funcall symbol-completion-completions-function symbol)))))
(while (and he-expand-list
(he-string-member (car he-expand-list) he-tried-table))
(pop he-expand-list))
(if he-expand-list
(progn
(he-substitute-string (pop he-expand-list))
t)
(if old (he-reset-string))
nil)))
\f
;;; Emacs Lisp symbol completion.
(defun lisp-completion-symbol ()
"`symbol-completion-symbol-function' for Lisp."
(let ((end (point))
(beg (with-syntax-table emacs-lisp-mode-syntax-table
(save-excursion
(backward-sexp 1)
(while (=3D (char-syntax (following-char)) ?\')
(forward-char 1))
(point)))))
(buffer-substring-no-properties beg end)))
(defun lisp-completion-predicate (beg end)
"`symbol-completion-predicate-function' for Lisp."
(save-excursion
(goto-char beg)
(if (not (eq (char-before) ?\())
(lambda (sym) ;why not just nil ? -sm
;To avoid interned symbols with
;no slots. -- fx
(or (boundp sym) (fboundp sym)
(symbol-plist sym)))
;; Looks like a funcall position. Let's double check.
(if (condition-case nil
(progn (up-list -2) (forward-char 1)
(eq (char-after) ?\())
(error nil))
;; If the first element of the parent list is an open
;; parenthesis we are probably not in a funcall position.
;; Maybe a `let' varlist or something.
nil
;; Else, we assume that a function name is expected.
'fboundp))))
(defvar symbol-completion-predicate)
(defun lisp-symbol-completion-transform ()
"`symbol-completion-transform-function' for Lisp."
(lambda (elt)
(if (and (not (eq 'fboundp symbol-completion-predicate))
(fboundp (intern elt)))
(list elt " <f>")
elt)))
;; We don't just have the hooks as buffer-local variables in
;; emacs-lisp-mode since the original version of this function worked
;; in all buffers. Thus just bind them locally.
;;;###autoload
(defun lisp-complete-symbol (&optional predicate)
"Perform completion on Lisp symbol preceding point.
Compare that symbol against the known Lisp symbols.
If no characters can be completed, display a list of possible completions.
Repeating the command at that point scrolls the list.
When called from a program, optional arg PREDICATE is a predicate
determining which symbols are considered, e.g. `commandp'.
If PREDICATE is nil, the context determines which symbols are
considered. If the symbol starts just after an open-parenthesis, only
symbols with function definitions are considered. Otherwise, all
symbols with function definitions, values or properties are
considered."
(interactive)
(let ((symbol-completion-symbol-function #'lisp-completion-symbol)
(symbol-completion-completions-function (lambda (sym) obarray))
(symbol-completion-predicate-function #'lisp-completion-predicate)
(symbol-completion-transform-function
#'lisp-symbol-completion-transform))
(symbol-complete predicate)))
(provide 'sym-comp)
;;; sym-comp.el ends here
- --bluebird-explosion-Lon-Horiuchi-bootleg-csim
Content-Type: text/x-python
Content-Disposition: attachment; filename=emacs.py
"""Definitions used by commands sent to inferior Python in python.el."""
# Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
# Author: Dave Love <fx@gnu.org>
# This file is part of GNU Emacs.
# GNU Emacs 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 3, or (at your option)
# any later version.
# GNU Emacs 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 GNU Emacs; see the file COPYING. If not, write to the
# Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
# Boston, MA 02110-1301, USA.
# $Revision: 1.12 $
import os, sys, traceback, inspect
from sets import Set
__all__ = ["eexecfile", "eargs", "complete", "ehelp", "eimport", "modpath"]
def eexecfile (file):
"""Execute FILE and then remove it.
If we get an exception, print a traceback with the top frame
(ourselves) excluded."""
import __main__
try:
try: execfile (file, __main__.__dict__)
except:
(etype, value, tb) = sys.exc_info ()
# Lose the stack frame for this location.
tb = tb.tb_next
if tb is None: # print_exception won't do it
print "Traceback (most recent call last):"
traceback.print_exception (etype, value, tb)
finally:
os.remove (file)
def eargs (name, imports):
"""Get arglist of NAME for Eldoc &c.
Exec IMPORTS first."""
try:
try: # don't give up if the imports fail
if imports: exec imports
parts = name.split ('.')
if len (parts) > 1:
exec 'import ' + parts[0]
except: pass
func = eval (name)
if inspect.isbuiltin (func) or inspect.isclass (func):
doc = func.__doc__
if doc.find (' ->') != -1:
print '_emacs_out', doc.split (' ->')[0]
elif doc.find ('\n') != -1:
print '_emacs_out', doc.split ('\n')[0]
return
if inspect.ismethod (func):
func = func.im_func
if not inspect.isfunction (func): return
(args, varargs, varkw, defaults) = inspect.getargspec (func)
# No space between name and arglist for consistency with builtins.
print '_emacs_out', \
func.__name__ + inspect.formatargspec (args, varargs, varkw,
defaults)
except: pass
def all_names (object):
"""Return (an approximation to) a list of all possible attribute
names reachable via the attributes of OBJECT, i.e. roughly the
leaves of the dictionary tree under it."""
def do_object (object, names):
if inspect.ismodule (object):
do_module (object, names)
elif inspect.isclass (object):
do_class (object, names)
# Might have an object without its class in scope.
elif hasattr (object, '__class__'):
names.add ('__class__')
do_class (object.__class__, names)
# Probably not a good idea to try to enumerate arbitrary
# dictionaries...
return names
def do_module (module, names):
if hasattr (module, '__all__'): # limited export list
names.union_update (module.__all__)
for i in module.__all__:
do_object (getattr (module, i), names)
else: # use all names
names.union_update (dir (module))
for i in dir (module):
do_object (getattr (module, i), names)
return names
def do_class (object, names):
names.union_update (dir (object))
if hasattr (object, '__bases__'): # superclasses
for i in object.__bases__: do_object (i, names)
return names
return do_object (object, Set ([]))
def complete (name, imports):
"""Complete TEXT in NAMESPACE and print a Lisp list of completions.
Exec IMPORTS first."""
import __main__, keyword
def class_members (object):
names = dir (object)
if hasattr (object, '__bases__'):
for superc in object.__bases__:
names = class_members (superc)
return names
names = Set ([])
base = None
try:
dic = __main__.__dict__.copy()
if imports:
try: exec imports in dic
except: pass
l = len (name)
dot = name.rfind ('.')
if dot == -1:
for elts in [dir (__builtins__), keyword.kwlist, dic.keys()]:
for elt in elts:
if elt[:l] == name: names.add (elt)
else:
base = name[:dot]
name = name[dot+1:]
try:
obj = eval (base, dic)
names = Set (dir (obj))
if hasattr (obj, '__class__'):
names.add ('__class__')
names.union_update (class_members (obj))
except: names = all_names (dic)
except: return []
l = len (name)
print '_emacs_out (',
for n in names:
if name == n[:l]:
if base: print '"%s.%s"' % (base, n),
else: print '"%s"' % n,
print ')'
# Fixme: This could try to look up methods/attributes applied to
# variables by generating possibilities like the completion code. The
# trouble is that could be misleading if it gets the wrong one.
def ehelp (name, imports):
"""Get help on string NAME.
First try to eval name for, e.g. user definitions where we need
the object. Otherwise try the string form.
Exec IMPORTS first."""
locls = {}
if imports:
try: exec imports in locls
except: pass
try: help (eval (name, globals (), locls))
except: help (name)
def eimport (mod, dir):
"""Import module MOD with directory DIR at the head of the search path.
NB doesn't load from DIR if MOD shadows a system module."""
from __main__ import __dict__
path0 = sys.path[0]
sys.path[0] = dir
try:
try:
if __dict__.has_key (mod) and inspect.ismodule (__dict__[mod]):
reload (__dict__[mod])
else:
__dict__[mod] = __import__ (mod)
except:
(etype, value, tb) = sys.exc_info ()
print "Traceback (most recent call last):"
traceback.print_exception (etype, value, tb.tb_next)
finally:
sys.path[0] = path0
def modpath (module):
"""Get the source file for the given MODULE (or nil)."""
locls = {}
try:
exec "import " + module
print "_emacs_out", \
inspect.getsourcefile (eval (module, globals (), locls))
except:
print "_emacs_out ()"
def location_of (name, imports):
"""Get location at which NAME is defined (or nil).
Returns a pair (PATH, LINE), where LINE is the start of the definition
in path name PATH.
Exec IMPORTS first."""
locls = {}
if imports:
try: exec imports in locls
except: pass
try:
obj = eval (name, globals (), locls)
# Bug: (in Python 2.5) `getsourcefile' only works with modules,
# hence the `getmodule' here.
srcfile = inspect.getsourcefile (inspect.getmodule (obj))
_, line = inspect.getsourcelines (obj)
print '_emacs_out ("%s" . %d)' % (srcfile, line)
except:
print "_emacs_out ()"
# print '_emacs_ok' # ready for input and can call continuation
# arch-tag: d90408f3-90e2-4de4-99c2-6eb9c7b9ca46
- --bluebird-explosion-Lon-Horiuchi-bootleg-csim
- --
There should be only one way to do it. -- Python
There's more than one way to do it. -- Perl
Do the right thing. -- Lisp
- --bluebird-explosion-Lon-Horiuchi-bootleg-csim
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
gnu-emacs-sources mailing list
gnu-emacs-sources@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
- --bluebird-explosion-Lon-Horiuchi-bootleg-csim--
------- End of forwarded message -------
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-11 13:34 python.el fixes for Emacs 22 Richard Stallman
@ 2008-02-11 15:15 ` Stefan Monnier
2008-02-11 21:10 ` Richard Stallman
2008-02-14 0:36 ` Chong Yidong
1 sibling, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-11 15:15 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> I asked Dave to send a diff and a change log, as a good
> contributor should, but he did not respond. I think that the
> changes are important enough that we should do the extra
> work to install them anyway.
> Would someone please volunteer to look at them, write change
> log entries for them, and decide whether to install them now?
I may be able to look at it at some point. If anybody else does it
before me, please make use of the DAVELOVE "vendor branch" where I've
put the latest version of Dave's code with which I sync'd our code.
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-11 15:15 ` Stefan Monnier
@ 2008-02-11 21:10 ` Richard Stallman
2008-02-12 3:04 ` Stefan Monnier
0 siblings, 1 reply; 81+ messages in thread
From: Richard Stallman @ 2008-02-11 21:10 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
I may be able to look at it at some point. If anybody else does it
before me, please make use of the DAVELOVE "vendor branch" where I've
put the latest version of Dave's code with which I sync'd our code.
That is a good step forward. Do we still need a change log entry for his
changes?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-11 21:10 ` Richard Stallman
@ 2008-02-12 3:04 ` Stefan Monnier
2008-02-12 17:44 ` Richard Stallman
0 siblings, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-12 3:04 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> I may be able to look at it at some point. If anybody else does it
> before me, please make use of the DAVELOVE "vendor branch" where I've
> put the latest version of Dave's code with which I sync'd our code.
> That is a good step forward. Do we still need a change log entry for his
> changes?
You probably misunderstood: I did not do anything, I just described the
setup I have used until now to keep it up-to-date, in the hope that it
will be useful to (and preserved by) whoever does this particular update.
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-12 3:04 ` Stefan Monnier
@ 2008-02-12 17:44 ` Richard Stallman
2008-02-12 21:40 ` Stefan Monnier
0 siblings, 1 reply; 81+ messages in thread
From: Richard Stallman @ 2008-02-12 17:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
You probably misunderstood: I did not do anything, I just described the
setup I have used until now to keep it up-to-date, in the hope that it
will be useful to (and preserved by) whoever does this particular update.
The part that isn't clear to me is whether that branch currently
includes any of his changes that are not in the trunk. Does it?
If it does, should any of those changes be installed?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-12 17:44 ` Richard Stallman
@ 2008-02-12 21:40 ` Stefan Monnier
2008-02-13 16:32 ` Richard Stallman
0 siblings, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-12 21:40 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> You probably misunderstood: I did not do anything, I just described the
> setup I have used until now to keep it up-to-date, in the hope that it
> will be useful to (and preserved by) whoever does this particular update.
> The part that isn't clear to me is whether that branch currently
> includes any of his changes that are not in the trunk. Does it?
> If it does, should any of those changes be installed?
There are some differences between the two, but I believe they're all
changes that we applied and the he preferred not to include in
his version. In any case we should strive to minimize the differences.
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-12 21:40 ` Stefan Monnier
@ 2008-02-13 16:32 ` Richard Stallman
2008-02-13 19:19 ` Stefan Monnier
0 siblings, 1 reply; 81+ messages in thread
From: Richard Stallman @ 2008-02-13 16:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
There are some differences between the two, but I believe they're all
changes that we applied and the he preferred not to include in
his version. In any case we should strive to minimize the differences.
In that case, it makes sense to install his newer changes
into that branch, and also into the trunk -- in parallel.
It would not make sense to install them into the trunk FROM or VIA
that branch, because that way we would revert the changes he did
not accept from us.
Would someone please DTRT and then ack?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-13 16:32 ` Richard Stallman
@ 2008-02-13 19:19 ` Stefan Monnier
0 siblings, 0 replies; 81+ messages in thread
From: Stefan Monnier @ 2008-02-13 19:19 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> There are some differences between the two, but I believe they're all
> changes that we applied and the he preferred not to include in
> his version. In any case we should strive to minimize the differences.
> In that case, it makes sense to install his newer changes
> into that branch, and also into the trunk -- in parallel.
> It would not make sense to install them into the trunk FROM or VIA
> that branch, because that way we would revert the changes he did
> not accept from us.
That branch is there specifically for that purpose. If you want to know
more, read up on "vendor branch" (the original motivation for writing
CVS in the first place). (info "(cvs)Tracking sources")
Basically, you have to commit the new version on that DAVELOVE branch,
and then use "cvs update -j<lastrev> -j<thisrev>" on the trunk (or in
the 22 branch) to bring the changes that need to be merged.
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-11 13:34 python.el fixes for Emacs 22 Richard Stallman
2008-02-11 15:15 ` Stefan Monnier
@ 2008-02-14 0:36 ` Chong Yidong
2008-02-14 0:51 ` Miles Bader
2008-02-14 1:56 ` Leo
1 sibling, 2 replies; 81+ messages in thread
From: Chong Yidong @ 2008-02-14 0:36 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> I think this ought to be done for Emacs 22.2, if the changes
> are bug fixes.
This looks like a code dump, not a set of bug fixes. Given that 22.2
has entered pretesting, I think this should wait for 22.3.
After all, we have not received any significant complaints about
python-mode in emacs-devel, which indicates that the problems aren't
that serious.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-14 0:36 ` Chong Yidong
@ 2008-02-14 0:51 ` Miles Bader
2008-02-14 1:56 ` Leo
1 sibling, 0 replies; 81+ messages in thread
From: Miles Bader @ 2008-02-14 0:51 UTC (permalink / raw)
To: Chong Yidong; +Cc: rms, emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
>> I think this ought to be done for Emacs 22.2, if the changes
>> are bug fixes.
>
> This looks like a code dump, not a set of bug fixes. Given that 22.2
> has entered pretesting, I think this should wait for 22.3.
Agree.
-Miles
--
Accordion, n. An instrument in harmony with the sentiments of an assassin.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-14 0:36 ` Chong Yidong
2008-02-14 0:51 ` Miles Bader
@ 2008-02-14 1:56 ` Leo
2008-02-14 18:11 ` Richard Stallman
1 sibling, 1 reply; 81+ messages in thread
From: Leo @ 2008-02-14 1:56 UTC (permalink / raw)
To: Chong Yidong; +Cc: rms, emacs-devel
On 2008-02-14 00:36 +0000, Chong Yidong wrote:
> After all, we have not received any significant complaints about
> python-mode in emacs-devel, which indicates that the problems aren't
> that serious.
Maybe most users are using the python-mode.el that is not included in
Emacs. It seems to have more features than the default python.el.
--
.: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :.
Use the best OS -- http://www.fedoraproject.org/
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-14 1:56 ` Leo
@ 2008-02-14 18:11 ` Richard Stallman
2008-02-14 23:42 ` Leo
0 siblings, 1 reply; 81+ messages in thread
From: Richard Stallman @ 2008-02-14 18:11 UTC (permalink / raw)
To: Leo; +Cc: cyd, emacs-devel
Maybe most users are using the python-mode.el that is not included in
Emacs. It seems to have more features than the default python.el.
Have we looked at installing python-mode.el in Emacs?
If so, what conclusion did we reach?
If not, let's look at it now (not for 22.2).
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-14 18:11 ` Richard Stallman
@ 2008-02-14 23:42 ` Leo
2008-02-15 0:01 ` Nick Roberts
0 siblings, 1 reply; 81+ messages in thread
From: Leo @ 2008-02-14 23:42 UTC (permalink / raw)
To: rms; +Cc: cyd, emacs-devel
On 2008-02-14 18:11 +0000, Richard Stallman wrote:
> Maybe most users are using the python-mode.el that is not included in
> Emacs. It seems to have more features than the default python.el.
>
> Have we looked at installing python-mode.el in Emacs?
> If so, what conclusion did we reach?
Not in the last 2 years.
>
> If not, let's look at it now (not for 22.2).
>
--
.: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :.
Use the best OS -- http://www.fedoraproject.org/
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-14 23:42 ` Leo
@ 2008-02-15 0:01 ` Nick Roberts
2008-02-15 0:08 ` Leo
2008-02-15 12:59 ` Richard Stallman
0 siblings, 2 replies; 81+ messages in thread
From: Nick Roberts @ 2008-02-15 0:01 UTC (permalink / raw)
To: Leo; +Cc: cyd, rms, emacs-devel
> > Maybe most users are using the python-mode.el that is not included in
> > Emacs. It seems to have more features than the default python.el.
This appears to be just speculation.
> > Have we looked at installing python-mode.el in Emacs?
> > If so, what conclusion did we reach?
>
> Not in the last 2 years.
Assuming we're talking about python-mode.el as used by XEmacs, I don't know how
you reached this conclusion as we tried to get signatures for pdbtrack
under 18 months ago:
http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg01082.html
> >
> > If not, let's look at it now (not for 22.2).
> >
Apart from Ken Manheimer, I have the impression that the developers of
python-mode.el have a preference towards XEmacs and aren't interested in
assigning copyright to FSF.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 0:01 ` Nick Roberts
@ 2008-02-15 0:08 ` Leo
2008-02-15 0:17 ` Miles Bader
` (3 more replies)
2008-02-15 12:59 ` Richard Stallman
1 sibling, 4 replies; 81+ messages in thread
From: Leo @ 2008-02-15 0:08 UTC (permalink / raw)
To: emacs-devel
On 2008-02-15 00:01 +0000, Nick Roberts wrote:
> > > Maybe most users are using the python-mode.el that is not included in
> > > Emacs. It seems to have more features than the default python.el.
>
> This appears to be just speculation.
That's why I started the sentence with 'maybe'.
>
> > > Have we looked at installing python-mode.el in Emacs?
> > > If so, what conclusion did we reach?
> >
> > Not in the last 2 years.
>
> Assuming we're talking about python-mode.el as used by XEmacs, I don't know how
> you reached this conclusion as we tried to get signatures for pdbtrack
> under 18 months ago:
I hope we agree that 'Get signatures and discuss' is not the same thing.
>
> http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg01082.html
>
> > >
> > > If not, let's look at it now (not for 22.2).
> > >
>
> Apart from Ken Manheimer, I have the impression that the developers of
> python-mode.el have a preference towards XEmacs and aren't interested in
> assigning copyright to FSF.
This is true. It is probably not worth the trouble, particularly there
are tons of python editors that are far superior than Emacs. To name
one, SciTE.
--
.: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :.
Use the best OS -- http://www.fedoraproject.org/
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 0:08 ` Leo
@ 2008-02-15 0:17 ` Miles Bader
2008-02-15 2:10 ` Nick Roberts
` (2 subsequent siblings)
3 siblings, 0 replies; 81+ messages in thread
From: Miles Bader @ 2008-02-15 0:17 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
Leo <sdl.web@gmail.com> writes:
> This is true. It is probably not worth the trouble, particularly there
> are tons of python editors that are far superior than Emacs.
You forgot "... for editing python" ...
-Miles
--
Non-combatant, n. A dead Quaker.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 0:08 ` Leo
2008-02-15 0:17 ` Miles Bader
@ 2008-02-15 2:10 ` Nick Roberts
2008-02-15 17:57 ` Ken Manheimer
2008-02-16 5:53 ` Richard Stallman
3 siblings, 0 replies; 81+ messages in thread
From: Nick Roberts @ 2008-02-15 2:10 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
> > This appears to be just speculation.
>
> That's why I started the sentence with 'maybe'.
It doesn't have much value then.
> > > > Have we looked at installing python-mode.el in Emacs?
> > > > If so, what conclusion did we reach?
> > >
> > > Not in the last 2 years.
> >
> > Assuming we're talking about python-mode.el as used by XEmacs, I don't
> > know how you reached this conclusion as we tried to get signatures for
> > pdbtrack under 18 months ago:
>
> I hope we agree that 'Get signatures and discuss' is not the same thing.
The question was about installing python-mode.el in Emacs. Presumably
installing python-mode.el would need the same signatures as those required for
pdbtrack.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 0:01 ` Nick Roberts
2008-02-15 0:08 ` Leo
@ 2008-02-15 12:59 ` Richard Stallman
2008-02-15 13:27 ` David Kastrup
2008-02-15 16:51 ` Chong Yidong
1 sibling, 2 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-15 12:59 UTC (permalink / raw)
To: Nick Roberts; +Cc: cyd, sdl.web, emacs-devel
Apart from Ken Manheimer, I have the impression that the developers of
python-mode.el have a preference towards XEmacs and aren't interested in
assigning copyright to FSF.
That is too bad.
This means we had better install the changes in python mode. Would
someone please do that in the trunk, and ack?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 12:59 ` Richard Stallman
@ 2008-02-15 13:27 ` David Kastrup
2008-02-15 17:43 ` Ken Manheimer
2008-02-15 16:51 ` Chong Yidong
1 sibling, 1 reply; 81+ messages in thread
From: David Kastrup @ 2008-02-15 13:27 UTC (permalink / raw)
To: rms; +Cc: Nick Roberts, emacs-devel, cyd, sdl.web
Richard Stallman <rms@gnu.org> writes:
> Apart from Ken Manheimer, I have the impression that the
> developers of python-mode.el have a preference towards XEmacs and
> aren't interested in assigning copyright to FSF.
>
> That is too bad.
"Not interested" need not be the same as "opposed to". No idea how the
situation is here.
--
David Kastrup
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 12:59 ` Richard Stallman
2008-02-15 13:27 ` David Kastrup
@ 2008-02-15 16:51 ` Chong Yidong
1 sibling, 0 replies; 81+ messages in thread
From: Chong Yidong @ 2008-02-15 16:51 UTC (permalink / raw)
To: rms; +Cc: Nick Roberts, sdl.web, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> Apart from Ken Manheimer, I have the impression that the developers of
> python-mode.el have a preference towards XEmacs and aren't interested in
> assigning copyright to FSF.
>
> That is too bad.
>
> This means we had better install the changes in python mode. Would
> someone please do that in the trunk, and ack?
I'll work on it.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 13:27 ` David Kastrup
@ 2008-02-15 17:43 ` Ken Manheimer
2008-02-15 21:47 ` Nick Roberts
2008-02-17 13:22 ` Richard Stallman
0 siblings, 2 replies; 81+ messages in thread
From: Ken Manheimer @ 2008-02-15 17:43 UTC (permalink / raw)
To: David Kastrup; +Cc: sdl.web, cyd, Nick Roberts, rms, emacs-devel
On Fri, Feb 15, 2008 at 8:27 AM, David Kastrup <dak@gnu.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
> > Apart from Ken Manheimer, I have the impression that the
> > developers of python-mode.el have a preference towards XEmacs and
> > aren't interested in assigning copyright to FSF.
> >
> > That is too bad.
>
> "Not interested" need not be the same as "opposed to". No idea how the
> situation is here.
hi, all. sorry it's taken me a while to join this conversation. i
adamantly want to see the pdbtrack functionality, which was integrated
to python-mode.el, included in the python mode delivered with emacs.
at one point it was integrated with the version of python.el that was
supposed to be included with the release of emacs 22. i was perplexed
and dismayed to discover, however, that somehow changed at the last
moment, and it still hasn't been rectified.
in general, i haven't understood why a version of python mode was
created (python.el) separate from that of python-mode.el.
python-mode.el is a pretty fine mode implementation, and (if i do say
so myself), pdb tracking is worth as much as any mode feature, for
those of us familiar with it.
it looks like the reason for the separate implementation of python.el
had something to do with problems getting copyright assignments. i
think that could be settled, and probably could help with that, but
now we have two separate python mode implementations, and i don't know
how to resolve the choice between them.
in any case, i *do* want to see pdb tracking included in whichever.
as the author of the feature, i should be able to authorize its use
wherever, and am frustrated with the twisty turns of events that have
prevented that. while my time is limited for reimplementing it, i can
probably help with that and/or with seeing about getting license
assignment for python-mode.el.
--
ken manheimer
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 0:08 ` Leo
2008-02-15 0:17 ` Miles Bader
2008-02-15 2:10 ` Nick Roberts
@ 2008-02-15 17:57 ` Ken Manheimer
2008-02-16 5:53 ` Richard Stallman
3 siblings, 0 replies; 81+ messages in thread
From: Ken Manheimer @ 2008-02-15 17:57 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
On Thu, Feb 14, 2008 at 7:08 PM, Leo <sdl.web@gmail.com> wrote:
> On 2008-02-15 00:01 +0000, Nick Roberts wrote:
> > > > Maybe most users are using the python-mode.el that is not included in
> > > > Emacs. It seems to have more features than the default python.el.
> >
> > This appears to be just speculation.
>
> That's why I started the sentence with 'maybe'.
the speculation is accurate in my case, and i know several other
python coders who retain copies of python-mode.el, if only for pdb
tracking. unfortunately, besides this particular feature, i can't
tell you what else i'm missing and getting from python-mode.el versus
python.el.
> [...]
> > > > If not, let's look at it now (not for 22.2).
> >
> > Apart from Ken Manheimer, I have the impression that the developers of
> > python-mode.el have a preference towards XEmacs and aren't interested in
> > assigning copyright to FSF.
>
> This is true. It is probably not worth the trouble, particularly there
> are tons of python editors that are far superior than Emacs. To name
> one, SciTE.
aargh! why would you say that? being someone who likes using emacs
and python coding, i'm hoping that attitude doesn't mean we settle for
less than we ought for coding python with emacs!
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 17:43 ` Ken Manheimer
@ 2008-02-15 21:47 ` Nick Roberts
2008-02-15 22:21 ` Ken Manheimer
2008-02-17 13:22 ` python.el fixes for Emacs 22 Richard Stallman
2008-02-17 13:22 ` Richard Stallman
1 sibling, 2 replies; 81+ messages in thread
From: Nick Roberts @ 2008-02-15 21:47 UTC (permalink / raw)
To: Ken Manheimer; +Cc: sdl.web, cyd, rms, emacs-devel
> hi, all. sorry it's taken me a while to join this conversation. i
> adamantly want to see the pdbtrack functionality, which was integrated
> to python-mode.el, included in the python mode delivered with emacs.
> at one point it was integrated with the version of python.el that was
> supposed to be included with the release of emacs 22. i was perplexed
> and dismayed to discover, however, that somehow changed at the last
> moment, and it still hasn't been rectified.
I never installed that patch because I was uncertain about the authorship
of the parts of python-mode.el that I was taking from.
> it looks like the reason for the separate implementation of python.el
> had something to do with problems getting copyright assignments. i
> think that could be settled, and probably could help with that, but
> now we have two separate python mode implementations, and i don't know
> how to resolve the choice between them.
>
> in any case, i *do* want to see pdb tracking included in whichever.
> as the author of the feature, i should be able to authorize its use
> wherever, and am frustrated with the twisty turns of events that have
> prevented that. while my time is limited for reimplementing it, i can
> probably help with that and/or with seeing about getting license
> assignment for python-mode.el.
I still have a local copy of the patch updated to the trunk and could install
it now if instructed to do so.
There appear to be two options:
1) Install my patch in python.el which may in reality only involve your
contribution to python-mode.el and may not require other signatures.
2) Replace python.el with a modified python-mode.el which would require
more signatures (Barry Warsaw, Skip Montanero?) and more work.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 21:47 ` Nick Roberts
@ 2008-02-15 22:21 ` Ken Manheimer
2008-02-15 23:57 ` Nick Roberts
2008-02-17 13:22 ` python.el fixes for Emacs 22 Richard Stallman
1 sibling, 1 reply; 81+ messages in thread
From: Ken Manheimer @ 2008-02-15 22:21 UTC (permalink / raw)
To: Nick Roberts; +Cc: sdl.web, cyd, rms, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]
On Feb 15, 2008 4:47 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
> hi, all. sorry it's taken me a while to join this conversation. i
> > adamantly want to see the pdbtrack functionality, which was integrated
> > to python-mode.el, included in the python mode delivered with emacs.
> > at one point it was integrated with the version of python.el that was
> > supposed to be included with the release of emacs 22. i was perplexed
> > and dismayed to discover, however, that somehow changed at the last
> > moment, and it still hasn't been rectified.
>
> I never installed that patch because I was uncertain about the authorship
> of the parts of python-mode.el that I was taking from.
i believe that any changes to the code for pdb tracking functionality were
trivial, and that my copyright assignment would be sufficient for that part
of it. i can check with barry, who incorporated the stand-alone code i had
written (as "pdbtrack.el") into python-mode.el
> > it looks like the reason for the separate implementation of python.el
> > had something to do with problems getting copyright assignments. i
> > think that could be settled, and probably could help with that, but
> > now we have two separate python mode implementations, and i don't know
> > how to resolve the choice between them.
> >
> > in any case, i *do* want to see pdb tracking included in whichever.
> > as the author of the feature, i should be able to authorize its use
> > wherever, and am frustrated with the twisty turns of events that have
> > prevented that. while my time is limited for reimplementing it, i can
> > probably help with that and/or with seeing about getting license
> > assignment for python-mode.el.
>
> I still have a local copy of the patch updated to the trunk and could
> install
> it now if instructed to do so.
>
> There appear to be two options:
>
> 1) Install my patch in python.el which may in reality only involve your
> contribution to python-mode.el and may not require other signatures.
>
> 2) Replace python.el with a modified python-mode.el which would require
> more signatures (Barry Warsaw, Skip Montanero?) and more work.
it sounds like you have done some substantial comparison between the two
implementations of python-mode, at least when you were working on the
patches. can you characterize the differences between the two? i never
tried python.el very far, because it lacked pdb tracking - but i've always
been favorably impressed with python-mode.el, and would be expect it to
offer a good basis to work from.
i'm planning to contact barry and skip to see about copyright assignments -
would that help? would you be willing to revisit your patches and bring
them up to date, if clearance for python-mode.el became possible?
> --
> Nick
> http://www.inet.net.nz/~nickrob <http://www.inet.net.nz/%7Enickrob>
>
--
ken
http://myriadicity.net
[-- Attachment #2: Type: text/html, Size: 4042 bytes --]
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 22:21 ` Ken Manheimer
@ 2008-02-15 23:57 ` Nick Roberts
2008-02-16 0:22 ` Ken Manheimer
0 siblings, 1 reply; 81+ messages in thread
From: Nick Roberts @ 2008-02-15 23:57 UTC (permalink / raw)
To: Ken Manheimer; +Cc: cyd, emacs-devel, sdl.web, rms
> > I never installed that patch because I was uncertain about the authorship
> > of the parts of python-mode.el that I was taking from.
>
>
> i believe that any changes to the code for pdb tracking functionality were
> trivial, and that my copyright assignment would be sufficient for that part
> of it. i can check with barry, who incorporated the stand-alone code i had
> written (as "pdbtrack.el") into python-mode.el
About 90% of the patch is for pdbtrack, mostly taken verbatim after the line:
;; pdbtrack features
The other 10% is generally defining defcustoms that pdbtrack uses.
>...
> > I still have a local copy of the patch updated to the trunk and could
> > install
> > it now if instructed to do so.
> >
> > There appear to be two options:
> >
> > 1) Install my patch in python.el which may in reality only involve your
> > contribution to python-mode.el and may not require other signatures.
> >
> > 2) Replace python.el with a modified python-mode.el which would require
> > more signatures (Barry Warsaw, Skip Montanero?) and more work.
>
>
> it sounds like you have done some substantial comparison between the two
> implementations of python-mode, at least when you were working on the
> patches. can you characterize the differences between the two? i never
> tried python.el very far, because it lacked pdb tracking - but i've always
> been favorably impressed with python-mode.el, and would be expect it to
> offer a good basis to work from.
Firstly, as a disclaimer, I'm not a Python programmer. My curiosity came from
working on gud.el and M-x pdb. So I can't characterise the differences between
the two but I'm sure someone else on the list can.
> i'm planning to contact barry and skip to see about copyright assignments -
> would that help? would you be willing to revisit your patches and bring
> them up to date, if clearance for python-mode.el became possible?
I think they are up to date. I've just tried to take pdbtrack from
python-mode.el and adapt it for python.el. I can't remember the details
but I think I made minor changes like making the hooks added to
comint-output-filter-functions local.
My intention was just to get pdbtrack into python.el and leave it to those
who use Python to make improvements.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 23:57 ` Nick Roberts
@ 2008-02-16 0:22 ` Ken Manheimer
2008-02-16 0:39 ` python.el versus python-mode.el [was Re: python.el fixes for Emacs 22] Glenn Morris
0 siblings, 1 reply; 81+ messages in thread
From: Ken Manheimer @ 2008-02-16 0:22 UTC (permalink / raw)
To: Nick Roberts; +Cc: cyd, emacs-devel, sdl.web, rms
On Feb 15, 2008 6:57 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
> > > I never installed that patch because I was uncertain about the authorship
> > > of the parts of python-mode.el that I was taking from.
> >
> > i believe that any changes to the code for pdb tracking functionality were
> > trivial, and that my copyright assignment would be sufficient for that part
> > of it. i can check with barry, who incorporated the stand-alone code i had
> > written (as "pdbtrack.el") into python-mode.el
>
> About 90% of the patch is for pdbtrack, mostly taken verbatim after the line:
>
> ;; pdbtrack features
>
> The other 10% is generally defining defcustoms that pdbtrack uses.
i think it's a pretty safe bet that i could claim responsibility for
that code - and i've contacted barry just to be sure it's ok with him,
since he did the retrofitting to python-mode.el
> > > I still have a local copy of the patch updated to the trunk and could
> > > install it now if instructed to do so.
> > >
> > > There appear to be two options:
> > >
> > > 1) Install my patch in python.el which may in reality only involve your
> > > contribution to python-mode.el and may not require other signatures.
> > >
> > > 2) Replace python.el with a modified python-mode.el which would require
> > > more signatures (Barry Warsaw, Skip Montanero?) and more work.
> >
> >
> > it sounds like you have done some substantial comparison between the two
> > implementations of python-mode, at least when you were working on the
> > patches. can you characterize the differences between the two? i never
> > tried python.el very far, because it lacked pdb tracking - but i've always
> > been favorably impressed with python-mode.el, and would be expect it to
> > offer a good basis to work from.
>
> Firstly, as a disclaimer, I'm not a Python programmer. My curiosity came from
> working on gud.el and M-x pdb. So I can't characterise the differences between
> the two but I'm sure someone else on the list can.
i do hope someone could describe the differences. i'm curious why
something besides python-mode.el was even necessary in the first
place. just copyright assignment obstacles?
python-mode.el has been around almost as long as python has been
available on the internet. though he might be horrified by the
gushing praise, tim peters, the original author, is one of the single
most skilled programmers around. he no longer uses emacs, but his
python-mode has always worked outstandingly well. barry warsaw, who
took up maintenance after tim, is no slouch as well, and has been
diligent. other skilled, central python folk have been involved, and
i suspect python-mode.el offers a trove of good code, worth examining
for some kind of consolidation with python.el. i don't have time,
myself, or i'd stop trying to sell the idea and just do it...
> > i'm planning to contact barry and skip to see about copyright assignments -
> > would that help? would you be willing to revisit your patches and bring
> > them up to date, if clearance for python-mode.el became possible?
>
> I think they are up to date. I've just tried to take pdbtrack from
> python-mode.el and adapt it for python.el. I can't remember the details
> but I think I made minor changes like making the hooks added to
> comint-output-filter-functions local.
>
> My intention was just to get pdbtrack into python.el and leave it to those
> who use Python to make improvements.
thanks much for doing that. i hope the patch can land, now.
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* python.el versus python-mode.el [was Re: python.el fixes for Emacs 22]
2008-02-16 0:22 ` Ken Manheimer
@ 2008-02-16 0:39 ` Glenn Morris
0 siblings, 0 replies; 81+ messages in thread
From: Glenn Morris @ 2008-02-16 0:39 UTC (permalink / raw)
To: Ken Manheimer; +Cc: sdl.web, Nick Roberts, cyd, rms, emacs-devel
"Ken Manheimer" wrote:
> i do hope someone could describe the differences. i'm curious why
> something besides python-mode.el was even necessary in the first
> place. just copyright assignment obstacles?
I know nothing about either mode, but the author of python.el has a ~
1000 line patch for python-mode.
http://www.loveshack.ukfsn.org/emacs/python-mode.el.diff
See also the comments at the start of python.el:
http://www.loveshack.ukfsn.org/emacs/python.el
;; There is another Python mode, python-mode.el, used by XEmacs and
;; maintained with Python. That isn't covered by an FSF copyright
;; assignment, unlike this code, and seems not to be well-maintained
;; for Emacs (though I've submitted fixes). This mode is rather
;; simpler and is better in other ways. In particular, using the
;; syntax functions with text properties maintained by font-lock makes
;; it more correct with arbitrary string and comment contents.
;; This doesn't implement all the facilities of python-mode.el. Some
;; just need doing, e.g. catching exceptions in the inferior Python
;; buffer (but see M-x pdb for debugging). [Actually, the use of
;; `compilation-shell-minor-mode' now is probably enough for that.]
;; Others don't seem appropriate. For instance,
;; `forward-into-nomenclature' should be done separately, since it's
;; not specific to Python, and I've installed a minor mode to do the
;; job properly in Emacs 23. [CC mode 5.31 contains an incompatible
;; feature, `c-subword-mode' which is intended to have a similar
;; effect, but actually only affects word-oriented keybindings.]
;; Other things seem more natural or canonical here, e.g. the
;; {beginning,end}-of-defun implementation dealing with nested
;; definitions, and the inferior mode following `cmuscheme'. (The
;; inferior mode can find the source of errors from
;; `python-send-region' & al via `compilation-shell-minor-mode'.)
;; There is (limited) symbol completion using lookup in Python and
;; Eldoc support also using the inferior process. Successive TABs
;; cycle between possible indentations for the line.
;; Even where it has similar facilities, this mode is incompatible
;; with python-mode.el in some respects. For instance, various key
;; bindings are changed to obey Emacs conventions.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 0:08 ` Leo
` (2 preceding siblings ...)
2008-02-15 17:57 ` Ken Manheimer
@ 2008-02-16 5:53 ` Richard Stallman
2008-02-16 8:18 ` Leo
3 siblings, 1 reply; 81+ messages in thread
From: Richard Stallman @ 2008-02-16 5:53 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
This is true. It is probably not worth the trouble, particularly there
are tons of python editors that are far superior than Emacs. To name
one, SciTE.
What is superior about it?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-16 5:53 ` Richard Stallman
@ 2008-02-16 8:18 ` Leo
2008-02-16 8:35 ` Miles Bader
` (3 more replies)
0 siblings, 4 replies; 81+ messages in thread
From: Leo @ 2008-02-16 8:18 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
On 2008-02-16 05:53 +0000, Richard Stallman wrote:
> This is true. It is probably not worth the trouble, particularly there
> are tons of python editors that are far superior than Emacs. To name
> one, SciTE.
>
> What is superior about it?
* Unlimited number of editors
* Configurable window layout
* Configurable syntax hilighting
* Sourcecode autocompletion
* Sourcecode calltips
* Sourcecode folding
* Brace matching
* Error highlighting
* Advanced search functionality including project wide search and replace
* Integrated class browser
* Makro recordings
* Integrated version control interface for Cvs and
Subversion repositories (as plugins)
* Integrated sourcecode documentation system
* Integrated python debugger including support to debug multithreaded applications
* Integrated, full featured Ruby debugger
* Integrated profiling and code coverage support
* Integrated task (todo items) management
* Advanced project management facilities
* Interactive Python shell including syntax hilighting and autocompletion
* Interactive Ruby shell including syntax hilighting and autocompletion
* Integrated Bicycle Repair Man (refactoring tool) (as plugin)
* Application diagrams
* running external applications from within the IDE
* integrated unittest support
* Cyclops cycles finder support
* Integrated CORBA support based on omniORB
* Integrated interface to cx_freeze (as plugin)
* Integrated interface to PyLint (as plugin)
* Many integrated wizzards for regex and Qt dialogs (as plugins)
* Localizations. Currently Eric is available in English, German, French, Russian and Czech.
* ...many, many more not mentioned here
Best,
--
.: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :.
Use the best OS -- http://www.fedoraproject.org/
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-16 8:18 ` Leo
@ 2008-02-16 8:35 ` Miles Bader
2008-02-16 14:45 ` Stefan Monnier
` (2 subsequent siblings)
3 siblings, 0 replies; 81+ messages in thread
From: Miles Bader @ 2008-02-16 8:35 UTC (permalink / raw)
To: Leo; +Cc: rms, emacs-devel
Leo <sdl.web@gmail.com> writes:
>> This is true. It is probably not worth the trouble, particularly there
>> are tons of python editors that are far superior than Emacs. To name
>> one, SciTE.
>>
>> What is superior about it?
>
> ... long list snipped...
Surely not all of those things is superior to Emacs, as most them are
also features supported by Emacs. Probably SciTE has a better
implementation of some of those features, but then again, probably Emacs
has a better implementation of other things.
What is _superior_?
[Here's a start: "integrated class browser" (I presume of python
classes). Emacs does not have this to my knowledge.]
-Miles
--
Abstainer, n. A weak person who yields to the temptation of denying himself a
pleasure. A total abstainer is one who abstains from everything but
abstention, and especially from inactivity in the affairs of others.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-16 8:18 ` Leo
2008-02-16 8:35 ` Miles Bader
@ 2008-02-16 14:45 ` Stefan Monnier
2008-02-16 14:51 ` Miles Bader
2008-02-17 13:22 ` Richard Stallman
2008-02-17 13:26 ` Piet van Oostrum
3 siblings, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-16 14:45 UTC (permalink / raw)
To: Leo; +Cc: rms, emacs-devel
>> This is true. It is probably not worth the trouble, particularly
>> there are tons of python editors that are far superior than Emacs.
>> To name one, SciTE.
>>
>> What is superior about it?
[ List of features superior to what `ed' provides. ]
The context wanted to say "what is superior *to Emacs* about SciTE".
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-16 14:45 ` Stefan Monnier
@ 2008-02-16 14:51 ` Miles Bader
2008-02-17 3:44 ` Stephen J. Turnbull
0 siblings, 1 reply; 81+ messages in thread
From: Miles Bader @ 2008-02-16 14:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Leo, rms
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> [ List of features superior to what `ed' provides. ]
Hey now, ed's the standard!
-Miles
--
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-16 14:51 ` Miles Bader
@ 2008-02-17 3:44 ` Stephen J. Turnbull
0 siblings, 0 replies; 81+ messages in thread
From: Stephen J. Turnbull @ 2008-02-17 3:44 UTC (permalink / raw)
To: Miles Bader; +Cc: Leo, Stefan Monnier, rms, emacs-devel
Miles Bader writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > [ List of features superior to what `ed' provides. ]
>
> Hey now, ed's the standard!
Whatever happened to cut'n'cat?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 21:47 ` Nick Roberts
2008-02-15 22:21 ` Ken Manheimer
@ 2008-02-17 13:22 ` Richard Stallman
1 sibling, 0 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-17 13:22 UTC (permalink / raw)
To: Nick Roberts; +Cc: sdl.web, ken.manheimer, cyd, emacs-devel
2) Replace python.el with a modified python-mode.el which would require
more signatures (Barry Warsaw, Skip Montanero?) and more work.
I expect Barry Warsaw would sign. But the first step is making sure
we have the full list of people we need to ask to sign.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-15 17:43 ` Ken Manheimer
2008-02-15 21:47 ` Nick Roberts
@ 2008-02-17 13:22 ` Richard Stallman
2008-02-20 0:30 ` Nick Roberts
1 sibling, 1 reply; 81+ messages in thread
From: Richard Stallman @ 2008-02-17 13:22 UTC (permalink / raw)
To: Ken Manheimer; +Cc: sdl.web, nickrob, cyd, emacs-devel
it looks like the reason for the separate implementation of python.el
had something to do with problems getting copyright assignments.
It is possible that our python.el is also older.
(I am not sure, just speculating.) On the other hand, we might have
replaced it with python-mode.el by now if we could get papers for it.
in any case, i *do* want to see pdb tracking included in whichever.
as the author of the feature, i should be able to authorize its use
wherever, and am frustrated with the twisty turns of events that have
prevented that.
If you wrote the original version, we can install that
with papers from you alone. (Just say that you consider
it a change to Emacs and your assignment will cover it.)
You could also give us any of your own subsequent changes.
Then others (or you) could implement replacements for subsequent
improvements.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-16 8:18 ` Leo
2008-02-16 8:35 ` Miles Bader
2008-02-16 14:45 ` Stefan Monnier
@ 2008-02-17 13:22 ` Richard Stallman
2008-02-17 13:26 ` Piet van Oostrum
3 siblings, 0 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-17 13:22 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
> What is superior about it?
The list is too long for me to grasp, especially since most of the
items are not clear in themselves.
* Unlimited number of editors
What does that mean?
* Configurable window layout
Doesn't Emacs have that?
* Configurable syntax hilighting
Surely Font Lock mode has that.
* Sourcecode autocompletion
I think Emacs has that.
* Sourcecode calltips
I don't know what that means.
* Sourcecode folding
Emacs has that.
* Brace matching
Emacs has automatic paren matching, and it applies to braces too.
I won't keep commenting on them. I can only say that you have not
given a useful answer. It is possible that some actual advantages of
SciTE are hidden behind some of those cryptic items. But hiding the
answers isn't a useful response.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-16 8:18 ` Leo
` (2 preceding siblings ...)
2008-02-17 13:22 ` Richard Stallman
@ 2008-02-17 13:26 ` Piet van Oostrum
3 siblings, 0 replies; 81+ messages in thread
From: Piet van Oostrum @ 2008-02-17 13:26 UTC (permalink / raw)
To: emacs-devel
>>>>> Leo <sdl.web@gmail.com> (L) wrote:
>L> * Localizations. Currently Eric is available in English, German,
>L> French, Russian and Czech.
Eric?? I thought it was about SciTe?
--
Piet van Oostrum <piet@cs.uu.nl>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-17 13:22 ` Richard Stallman
@ 2008-02-20 0:30 ` Nick Roberts
2008-02-20 2:24 ` pdbtrack [was Re: python.el fixes for Emacs 22] Glenn Morris
2008-02-21 0:20 ` python.el fixes for Emacs 22 Ken Manheimer
0 siblings, 2 replies; 81+ messages in thread
From: Nick Roberts @ 2008-02-20 0:30 UTC (permalink / raw)
To: rms; +Cc: sdl.web, Ken Manheimer, cyd, emacs-devel
> in any case, i *do* want to see pdb tracking included in whichever.
> as the author of the feature, i should be able to authorize its use
> wherever, and am frustrated with the twisty turns of events that have
> prevented that.
>
> If you wrote the original version, we can install that
> with papers from you alone. (Just say that you consider
> it a change to Emacs and your assignment will cover it.)
>
> You could also give us any of your own subsequent changes.
>
> Then others (or you) could implement replacements for subsequent
> improvements.
As Ken is the author of these changes, has an assignment for Emacs and is keen
to see them installed, to move things along I have installed them.
My understanding is that the advantage of Pdbtrack is that you can start to
debug on the fly. There's a small example attached below using a file called
fibo.py (which I probably pinched from somewhere, but I can't remember where).
However, as I've said before I'm not a Python programmer and Ken can probably
explain better.
Note that python-shell is similar to run-python and one should probably
eventually subsume the other.
So, all credit to Ken, complaints to me... no, what the heck, give Ken your
grief too!
More seriously, this is only on the trunk and I can always revert these changes
if there are problems.
Enjoy!
Ken,
Have you got write access yet?
--
Nick http://www.inet.net.nz/~nickrob
---------------------------------------
# Fibonacci numbers module (fibo.py)
def fib (n): # write Fibonacci series up to n
a, b = 0, 1
while b < n:
print b,
a, b = b, a+b
def fib2 (n): # return Fibonacci series up to n
result = []
a, b = 0, 1
while b < n:
result.append (b)
a, b = b, a+b
return result
---------------------------------------
Pdbtrack:
M-x python-shell (note doesn't use run-python)
Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb
>>> import fibo
>>> pdb.run ("fibo.fib(1000)")
> <string>(1)<module>()
(Pdb) b fibo.py:5
Breakpoint 1 at /home/nickrob/python/fibo.py:5
(Pdb) c
> /home/nickrob/python/fibo.py(5)fib()
-> while b < n:
(Pdb)
Source should appear in buffer with overlay arrow.
^ permalink raw reply [flat|nested] 81+ messages in thread
* pdbtrack [was Re: python.el fixes for Emacs 22]
2008-02-20 0:30 ` Nick Roberts
@ 2008-02-20 2:24 ` Glenn Morris
2008-02-20 2:34 ` Nick Roberts
2008-02-21 0:20 ` python.el fixes for Emacs 22 Ken Manheimer
1 sibling, 1 reply; 81+ messages in thread
From: Glenn Morris @ 2008-02-20 2:24 UTC (permalink / raw)
To: Nick Roberts; +Cc: Ken Manheimer, emacs-devel
Nick Roberts wrote:
> So, all credit to Ken, complaints to me... no, what the heck, give Ken your
> grief too!
It uses four undefined functions:
python-goto-beyond-block, python-nesting-level, python-safe,
python-execute-file
Can I ask people to check for byte-compiler warnings when they install
things? Almost all are either genuine errors or are trivially
suppressible these days.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack [was Re: python.el fixes for Emacs 22]
2008-02-20 2:24 ` pdbtrack [was Re: python.el fixes for Emacs 22] Glenn Morris
@ 2008-02-20 2:34 ` Nick Roberts
2008-02-20 2:56 ` pdbtrack Glenn Morris
2008-02-21 22:40 ` pdbtrack [was Re: python.el fixes for Emacs 22] Ken Manheimer
0 siblings, 2 replies; 81+ messages in thread
From: Nick Roberts @ 2008-02-20 2:34 UTC (permalink / raw)
To: Glenn Morris; +Cc: Ken Manheimer, emacs-devel
> It uses four undefined functions:
>
> python-goto-beyond-block, python-nesting-level, python-safe,
> python-execute-file
>
> Can I ask people to check for byte-compiler warnings when they install
> things? Almost all are either genuine errors or are trivially
> suppressible these days.
I don't know what to do about these: remove references to them or install the
functions from python-mode.el of which I no longer have a copy, but I'm sure
Ken will.
Let's not forget the bigger picture too. Byte-compiler warnings on the trunk
at this stage aren't the end of the world.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-20 2:34 ` Nick Roberts
@ 2008-02-20 2:56 ` Glenn Morris
2008-02-21 22:40 ` pdbtrack [was Re: python.el fixes for Emacs 22] Ken Manheimer
1 sibling, 0 replies; 81+ messages in thread
From: Glenn Morris @ 2008-02-20 2:56 UTC (permalink / raw)
To: Nick Roberts; +Cc: Ken Manheimer, emacs-devel
Nick Roberts wrote:
> Let's not forget the bigger picture too. Byte-compiler warnings on the trunk
> at this stage aren't the end of the world.
I don't recall prophesying doom. I'm just pointing out some errors.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-20 0:30 ` Nick Roberts
2008-02-20 2:24 ` pdbtrack [was Re: python.el fixes for Emacs 22] Glenn Morris
@ 2008-02-21 0:20 ` Ken Manheimer
2008-02-21 4:02 ` Stefan Monnier
` (2 more replies)
1 sibling, 3 replies; 81+ messages in thread
From: Ken Manheimer @ 2008-02-21 0:20 UTC (permalink / raw)
To: Nick Roberts; +Cc: skip montanaro, rms, cyd, Barry Warsaw, emacs-devel, sdl.web
On Feb 19, 2008 7:30 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
> > in any case, i *do* want to see pdb tracking included in whichever.
> > as the author of the feature, i should be able to authorize its use
> > wherever, and am frustrated with the twisty turns of events that have
> > prevented that.
> >
> > If you wrote the original version, we can install that
> > with papers from you alone. (Just say that you consider
> > it a change to Emacs and your assignment will cover it.)
> [...]
> As Ken is the author of these changes, has an assignment for Emacs and is keen
> to see them installed, to move things along I have installed them.
yay! thanks!
> My understanding is that the advantage of Pdbtrack is that you can start to
> debug on the fly. There's a small example attached below using a file called
> fibo.py (which I probably pinched from somewhere, but I can't remember where).
> However, as I've said before I'm not a Python programmer and Ken can probably
> explain better.
the crucial thing is that, with an interactive language, you're much
more able, and more likely, to trigger debugging whenever you need to
do so. the idea of having to switch to a special debugging
environment (like gdb/gud) is a holdover from dealing with compiled
code, and means you have to restart your program and resurrect the
context where the problem happened. that often is a terrible hassle
and loss of context. (imagine if you had to restart emacs to debug
elisp. pdb tracking is the minimalist equivalent of edebug.)
instead, pdb tracking makes debugger sensitivity available at every moment.
the way you've implemented it, you put the comint hook only in the
python-shell. the thing is, python programs aren't only run from
python-shell. in fact, many python programs and servers are usually
launched as regular commands, from bash shells. in python-mode.el,
pdb tracking is hooked into all comint shells, and i would like to see
that same thing in the python.el version.
the way i most commonly use it, nowadays, is with python-based
servers, like zope, which i launch as bash shell commands in
non-forking "development" mode. the server runs normally until i
arrange for a pdb.set_trace() to be hit, or i have it rigged to go to
pdb for uncaught exceptions. in many cases i can edit code to add the
set_trace() on the fly, in the filesystem or in application-resident
storage. the debugging traces show up in the shell where i launched
the server, and pdb tracking kicks in.
there's a provision, not yet ported to the python.el version, which
handles the case where the traced script doesn't actually live in the
local filesystem. in this case, when pdb tracking is unable to find
the script according to indicated path, it looks for a python-mode
buffer with the same file name as the target, and uses that. this is
a very general approach that works with stored or remote procedures in
any application, not just zope.
there's one further, much smaller tweak to add. more recent versions
of python-mode (than the one you evidently were using) provide for
recursive debugging, where you can delve into an arbitrary statement
in the midst of debugging something else, and return to where you
started. the regular expressions need to be adjusted to account for
that situation
(i have wanted to mention this approach to instrumenting emacs as a
debugging environment for a long time, particularly at times when
rejiggering of gud was being discussed. pdb tracking features are
pretty minimal - it's just maintenance of the arrow overlay in the
target file, as you step through - but the original implementation was
just 150 lines of code, and over half of those were comments. gud
does a lot more - but it's many orders of magnitude larger. i think
this more loosely coupled approach may be a lot more useful and
efficient particularly for interpreted languages.)
> Note that python-shell is similar to run-python and one should probably
> eventually subsume the other.
>
> So, all credit to Ken, complaints to me... no, what the heck, give Ken your
> grief too!
>
> More seriously, this is only on the trunk and I can always revert these changes
> if there are problems.
>
> Enjoy!
>
> Ken,
>
> Have you got write access yet?
yes.
i'm hoping to have time to work on this more, hopefully tomorrow or
friday. i'd like to put in all the features i've described (though i
certainly wouldn't mind someone else beating me to it, if anyone is so
inclined), and check them in to the trunk. let me know if you there
are any objections.
also, i've also been talking with barry and skip, who would also be
interested in seeing the python mode versions converge. i do see that
python-mode.el is actively maintained - it's current with the
pre-release python 3.0, and it looks like a much more complete
language mode than python.el. would there be interest in helping to
get this convergence? is python.el actively maintained, and if so,
would the maintainers be interested in helping consolidate the
versions?
ken
> --
> Nick http://www.inet.net.nz/~nickrob
> ---------------------------------------
>
> # Fibonacci numbers module (fibo.py)
>
> def fib (n): # write Fibonacci series up to n
> a, b = 0, 1
> while b < n:
> print b,
> a, b = b, a+b
>
> def fib2 (n): # return Fibonacci series up to n
> result = []
> a, b = 0, 1
> while b < n:
> result.append (b)
> a, b = b, a+b
> return result
>
> ---------------------------------------
>
> Pdbtrack:
>
> M-x python-shell (note doesn't use run-python)
>
> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pdb
> >>> import fibo
> >>> pdb.run ("fibo.fib(1000)")
> > <string>(1)<module>()
> (Pdb) b fibo.py:5
> Breakpoint 1 at /home/nickrob/python/fibo.py:5
> (Pdb) c
> > /home/nickrob/python/fibo.py(5)fib()
> -> while b < n:
> (Pdb)
>
> Source should appear in buffer with overlay arrow.
>
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 0:20 ` python.el fixes for Emacs 22 Ken Manheimer
@ 2008-02-21 4:02 ` Stefan Monnier
2008-02-21 5:12 ` Barry Warsaw
2008-02-21 5:09 ` Barry Warsaw
2008-02-21 5:22 ` Nick Roberts
2 siblings, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-21 4:02 UTC (permalink / raw)
To: Ken Manheimer
Cc: skip montanaro, rms, cyd, Barry Warsaw, emacs-devel, sdl.web,
Nick Roberts
> i'm hoping to have time to work on this more, hopefully tomorrow or
> Friday.
That would be great.
> also, i've also been talking with barry and skip, who would also be
> interested in seeing the python mode versions converge. i do see that
> python-mode.el is actively maintained - it's current with the
> pre-release python 3.0, and it looks like a much more complete
> language mode than python.el. would there be interest in helping to
> get this convergence? is python.el actively maintained, and if so,
> would the maintainers be interested in helping consolidate the
> versions?
python.el is developed and maintained (outside of the Emacs repository!)
by Dave Love. The presence of those 2 versions is undesirable and only
caused by the fact that we didn't have the required legal paperwork for
python-mode. So anything that can bring the two modes closer is good,
as long as we can keep it in the Emacs repository (i.e. as long as those
changes come with appropriate copyright paperwork).
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 0:20 ` python.el fixes for Emacs 22 Ken Manheimer
2008-02-21 4:02 ` Stefan Monnier
@ 2008-02-21 5:09 ` Barry Warsaw
2008-02-21 5:22 ` Nick Roberts
2 siblings, 0 replies; 81+ messages in thread
From: Barry Warsaw @ 2008-02-21 5:09 UTC (permalink / raw)
To: Ken Manheimer
Cc: skip montanaro, Nick Roberts, cyd, emacs-devel, sdl.web, rms
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Let me just say that of all the cool Ken hacks that I've become
addicted to over the years, probably the most useful to my daily life
is pdbtrack. To me, it's an absolutely essential tool for a Python
programmer, and it makes all my vim-loving colleagues positively
drool. :) (BTW, why do all the kids love vim these days?)
On Feb 20, 2008, at 7:20 PM, Ken Manheimer wrote:
>
> the way you've implemented it, you put the comint hook only in the
> python-shell. the thing is, python programs aren't only run from
> python-shell.
In fact, I'd say almost never in my experience. I use pyshell for
some simple experimentation, but 99% of the time run my programs from
the shell, with a strategically placed "import pdb; pdb.set_trace()"
line in the problematic code. pdbtrack makes debugging this way
efficient and fun.
> in fact, many python programs and servers are usually
> launched as regular commands, from bash shells. in python-mode.el,
> pdb tracking is hooked into all comint shells, and i would like to see
> that same thing in the python.el version.
Yes, absolutely a must.
> also, i've also been talking with barry and skip, who would also be
> interested in seeing the python mode versions converge. i do see that
> python-mode.el is actively maintained - it's current with the
> pre-release python 3.0, and it looks like a much more complete
> language mode than python.el. would there be interest in helping to
> get this convergence? is python.el actively maintained, and if so,
> would the maintainers be interested in helping consolidate the
> versions?
I think Skip just recently added some support to python-mode.el for
Python 3.0 syntax, and between the two of us, we do try to keep the
mode up-to-date with the language. I think there will be an
interesting discussion about how to, or even if we should, try to
support both Python 2.6 and 3.0 in the same mode.
Skip and I are both very interested in converging the modes. It's
silly and confusing to our users for there to be more than one Python
mode. However, Skip and I are primarily XEmacs users so we need to
work together to make sure the code is portable between the two Emacsen.
I would like to move python-mode.el out of the Python tree, and
actually off of Subversion and SourceForge, and onto Bazaar and
Launchpad. Would the python.el folks be up for converging on that?
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR70HiXEjvBPtnXfVAQLZ2AQAlftWSJicMCcsMIVDzaVi10JMiy4gPaxn
A4iwAkl2WDPaZY3wcgeWLH7ewSwwaZk6XF2b8aWzmrdndGRKhd9GxHYRmu//zApy
H/ebj3wvCKMlAOmZ52IpEnJc4tAq513y5raABWfJ0yBEQEHnlU7b+uUjk6QcFpQq
U8Yj5R33reI=
=A186
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 4:02 ` Stefan Monnier
@ 2008-02-21 5:12 ` Barry Warsaw
2008-02-21 22:28 ` Richard Stallman
0 siblings, 1 reply; 81+ messages in thread
From: Barry Warsaw @ 2008-02-21 5:12 UTC (permalink / raw)
To: Stefan Monnier
Cc: skip montanaro, rms, cyd, emacs-devel, Ken Manheimer, sdl.web,
Nick Roberts
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 20, 2008, at 11:02 PM, Stefan Monnier wrote:
> python.el is developed and maintained (outside of the Emacs
> repository!)
> by Dave Love. The presence of those 2 versions is undesirable and
> only
> caused by the fact that we didn't have the required legal paperwork
> for
> python-mode. So anything that can bring the two modes closer is good,
> as long as we can keep it in the Emacs repository (i.e. as long as
> those
> changes come with appropriate copyright paperwork).
It's not worth harping on, but I'm pretty sure that the FSF has had
copyright assignments for python-mode.el from all the main developers
for some time now. OTOH, as Skip points out, python-mode.el can't be
GPL'd as long as it lives inside the Python tree. If the rest of the
Python community is okay with moving python-mode.el out of the Python
Subversion repository, I'd have no problem GPL'ing it and hosting its
development on e.g. Launchpad. Then there should be no reason why the
two modes can't be converged.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR70IU3EjvBPtnXfVAQK/lwP/aakBuUDq6W4KQEfH3a6whmQ3zPp36sOQ
s/uq7wS937xT12Dx2SzQpElxl7Wgjo2+U6UH2BGF8GS5are1YJyd60Qe1hIia7NZ
X4ShZLsf9TuqGWo01jrroWthmvbJ1B77iiTtRmhR61w1VCWDlbwQf8ljT4zlq4ji
GiD0OcsbKTE=
=A8OI
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 0:20 ` python.el fixes for Emacs 22 Ken Manheimer
2008-02-21 4:02 ` Stefan Monnier
2008-02-21 5:09 ` Barry Warsaw
@ 2008-02-21 5:22 ` Nick Roberts
2 siblings, 0 replies; 81+ messages in thread
From: Nick Roberts @ 2008-02-21 5:22 UTC (permalink / raw)
To: Ken Manheimer
Cc: skip montanaro, rms, cyd, Barry Warsaw, emacs-devel, sdl.web
> the way you've implemented it, you put the comint hook only in the
> python-shell. the thing is, python programs aren't only run from
> python-shell. in fact, many python programs and servers are usually
> launched as regular commands, from bash shells. in python-mode.el,
> pdb tracking is hooked into all comint shells, and i would like to see
> that same thing in the python.el version.
Sure. The implementation probably just reveals my ignorance. It was a while
ago and I can't even really remember what I did. I just wanted to get things
moving then and it looks like there's more momentum now.
It's probably best for you to make changes now. You might even prefer to start
over and use python-mode.el as a starting point.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 5:12 ` Barry Warsaw
@ 2008-02-21 22:28 ` Richard Stallman
2008-02-21 23:00 ` Barry Warsaw
2008-02-22 3:23 ` Stephen J. Turnbull
0 siblings, 2 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-21 22:28 UTC (permalink / raw)
To: Barry Warsaw
Cc: skip, sdl.web, nickrob, emacs-devel, ken.manheimer, monnier, cyd
It's not worth harping on, but I'm pretty sure that the FSF has had
copyright assignments for python-mode.el from all the main developers
for some time now.
Someone said Kyle Jones was a developer of it, and we don't have papers
from him for this. If you tell us the list of developers
we can see who we do or don't have papers from.
If the rest of the
Python community is okay with moving python-mode.el out of the Python
Subversion repository, I'd have no problem GPL'ing it and hosting its
development on e.g. Launchpad.
If we can get the necessary papers, let's put it in Emacs and
develop it there.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack [was Re: python.el fixes for Emacs 22]
2008-02-20 2:34 ` Nick Roberts
2008-02-20 2:56 ` pdbtrack Glenn Morris
@ 2008-02-21 22:40 ` Ken Manheimer
2008-02-21 23:35 ` pdbtrack Glenn Morris
1 sibling, 1 reply; 81+ messages in thread
From: Ken Manheimer @ 2008-02-21 22:40 UTC (permalink / raw)
To: Nick Roberts; +Cc: Glenn Morris, emacs-devel
On Tue, Feb 19, 2008 at 9:34 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
> > It uses four undefined functions:
> >
> > python-goto-beyond-block, python-nesting-level, python-safe,
> > python-execute-file
> >
> > Can I ask people to check for byte-compiler warnings when they install
> > things? Almost all are either genuine errors or are trivially
> > suppressible these days.
none of these functions have anything to do with the pdbtrack changes
that nick made. they all appear to be preexisting artifacts of an
incomplete adoption of code from python-mode.el. (if so, the
python.el file commentary ought to acknowledge that.) i just checked
in some refinements of the pdbtrack provisions without settling these
dangling functions. i'm about to spend some more time seeing about
settling them. from a quick glance, though, the changes are not
trivial.
in general, i don't think it's reasonable to expect everyone who
touches a file to settle all preexisting issues.
> I don't know what to do about these: remove references to them or install the
> functions from python-mode.el of which I no longer have a copy, but I'm sure
> Ken will.
i do have a copy, and will look at copying over more code, or
inhibiting the dangling references. this obviously is delicate
attribution territory, mitigated somewhat by the fact that (1) the
python-mode authors are interested in pursuing a consolidation, and
(2) some code was probably copied, already, if the matches against
routines in python-mode.el is any evidence.
> Let's not forget the bigger picture too. Byte-compiler warnings on the trunk
> at this stage aren't the end of the world.
i can understand the desire to minimize all incidental warnings, so
new warnings are visible. still, i think this is a less trivial
situation than was being supposed.
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 22:28 ` Richard Stallman
@ 2008-02-21 23:00 ` Barry Warsaw
2008-02-21 23:08 ` Ken Manheimer
` (2 more replies)
2008-02-22 3:23 ` Stephen J. Turnbull
1 sibling, 3 replies; 81+ messages in thread
From: Barry Warsaw @ 2008-02-21 23:00 UTC (permalink / raw)
To: rms; +Cc: skip, sdl.web, nickrob, emacs-devel, ken.manheimer, monnier, cyd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 21, 2008, at 5:28 PM, Richard Stallman wrote:
> It's not worth harping on, but I'm pretty sure that the FSF has had
> copyright assignments for python-mode.el from all the main
> developers
> for some time now.
>
> Someone said Kyle Jones was a developer of it, and we don't have
> papers
> from him for this. If you tell us the list of developers
> we can see who we do or don't have papers from.
I don't remember Kyle ever having touched it. Tim Peters was the
original author of python-mode.el. Other than that, I know Ken, Skip,
and myself have hacked on it. Grep'ing on the Subversion history, it
looks like Ed Loper also checked stuff in. I'm sure there's history
that predates the svn logs, but I can't think of who else touched the
file.
> If the rest of the
> Python community is okay with moving python-mode.el out of the
> Python
> Subversion repository, I'd have no problem GPL'ing it and hosting
> its
> development on e.g. Launchpad.
>
> If we can get the necessary papers, let's put it in Emacs and
> develop it there.
Two problems with that: I'd really like to develop the code with
Bazaar, and I want to make sure that we can still support XEmacs.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR74CenEjvBPtnXfVAQINewQAloWhjaGGgOuYvwJH2JpQyxdimooOEl1j
zDN0tKxZ9mEIu0xK9mtYRuYxCxZ7QNdUDmgdnEK1PUxTRiAU6ImsuEGpmIMIzv5k
p7G6AoKCO2T17fdExgn4/hPGx8TrDgXvFo8M+N1MFrcvcPIC5STNOsbuema0zeUj
4PuR9Jp51u4=
=oECH
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 23:00 ` Barry Warsaw
@ 2008-02-21 23:08 ` Ken Manheimer
2008-02-21 23:12 ` Barry Warsaw
2008-02-22 22:57 ` Richard Stallman
2008-02-22 22:57 ` Richard Stallman
2 siblings, 1 reply; 81+ messages in thread
From: Ken Manheimer @ 2008-02-21 23:08 UTC (permalink / raw)
To: Barry Warsaw; +Cc: skip, rms, cyd, emacs-devel, monnier, sdl.web, nickrob
On Thu, Feb 21, 2008 at 6:00 PM, Barry Warsaw <barry@python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Feb 21, 2008, at 5:28 PM, Richard Stallman wrote:
>
> > It's not worth harping on, but I'm pretty sure that the FSF has had
> > copyright assignments for python-mode.el from all the main
> > developers
> > for some time now.
> >
> > Someone said Kyle Jones was a developer of it, and we don't have
> > papers
> > from him for this. If you tell us the list of developers
> > we can see who we do or don't have papers from.
>
> > If the rest of the
> > Python community is okay with moving python-mode.el out of the
> > Python
> > Subversion repository, I'd have no problem GPL'ing it and hosting
> > its
> > development on e.g. Launchpad.
> >
> > If we can get the necessary papers, let's put it in Emacs and
> > develop it there.
>
> Two problems with that: I'd really like to develop the code with
> Bazaar, and I want to make sure that we can still support XEmacs.
for allout and other emacs-repository things that i maintain, i have
my own repositories where i do my development - i can be more casual
about commitments there - and on suitable occasions i apply the
changes to the emacs repository version. i haven't noticed problems
keeping xemacs compatability for code that lives in the fsf
repository. i don't mind the extra step in exchange for the broader
availability of the code gained by inclusion in emacs, proper, and
easier access for others wanting to apply fixes. in general, the
quality of the developers with emacs repository access is high enough
that it's a net win.
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 23:08 ` Ken Manheimer
@ 2008-02-21 23:12 ` Barry Warsaw
2008-02-22 1:49 ` Stefan Monnier
0 siblings, 1 reply; 81+ messages in thread
From: Barry Warsaw @ 2008-02-21 23:12 UTC (permalink / raw)
To: Ken Manheimer; +Cc: skip, rms, cyd, emacs-devel, monnier, sdl.web, nickrob
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 21, 2008, at 6:08 PM, Ken Manheimer wrote:
> for allout and other emacs-repository things that i maintain, i have
> my own repositories where i do my development - i can be more casual
> about commitments there - and on suitable occasions i apply the
> changes to the emacs repository version. i haven't noticed problems
> keeping xemacs compatability for code that lives in the fsf
> repository. i don't mind the extra step in exchange for the broader
> availability of the code gained by inclusion in emacs, proper, and
> easier access for others wanting to apply fixes. in general, the
> quality of the developers with emacs repository access is high enough
> that it's a net win.
What vcs is Emacs using these days? Looks like Arch and/or CVS?
Maybe we should try to do the same thing you're doing with allout, et
all. Maintain it separately and sync it to the Emacs repo occasionally?
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR74FY3EjvBPtnXfVAQI+bgQAroD9RIes/zuTB03526Iu0Sm7hHMTd5qw
LSeySE5u81s/KvnOhVUoEX+Wpg4uu8bnd3nKGZdgCpLXT1x7NtPG0ykNLDgD0ypa
fkTiehTYuMF/DeXTUhgTovTqcuK3T2yDFQ/ie5Vw+mZhZs2us9fIK3bWdtRTMTf9
n3lumwq7eac=
=fg8j
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-21 22:40 ` pdbtrack [was Re: python.el fixes for Emacs 22] Ken Manheimer
@ 2008-02-21 23:35 ` Glenn Morris
2008-02-22 18:00 ` pdbtrack Ken Manheimer
0 siblings, 1 reply; 81+ messages in thread
From: Glenn Morris @ 2008-02-21 23:35 UTC (permalink / raw)
To: Ken Manheimer; +Cc: Nick Roberts, emacs-devel
"Ken Manheimer" wrote:
> none of these functions have anything to do with the pdbtrack changes
> that nick made. they all appear to be preexisting artifacts of an
> incomplete adoption of code from python-mode.el.
You seem to misunderstand. None of these function references were
there until Nick checked in his pdbtrack changes in rev 1.81. It's not
a "pre-existing" condition. The code that calls these functions has
been attributed to you in the ChangeLog (2008-02-19).
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 23:12 ` Barry Warsaw
@ 2008-02-22 1:49 ` Stefan Monnier
2008-02-22 13:44 ` Barry Warsaw
0 siblings, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-22 1:49 UTC (permalink / raw)
To: Barry Warsaw; +Cc: skip, rms, nickrob, emacs-devel, Ken Manheimer, sdl.web, cyd
> Maybe we should try to do the same thing you're doing with allout, et all.
> Maintain it separately and sync it to the Emacs repo occasionally?
Having it outside Emacs's own repository is fine. The only thing that
matters is that the 2 branches stay in close sync: some people may
commit changes directly to the Emacs repository, so you have to watch
out for it, make sure that those changes don't get lost (or do get
properly rejected/rewritten/fixed if there's a problem with it).
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 22:28 ` Richard Stallman
2008-02-21 23:00 ` Barry Warsaw
@ 2008-02-22 3:23 ` Stephen J. Turnbull
2008-02-22 13:45 ` Barry Warsaw
1 sibling, 1 reply; 81+ messages in thread
From: Stephen J. Turnbull @ 2008-02-22 3:23 UTC (permalink / raw)
To: rms
Cc: cyd, skip, nickrob, sdl.web, ken.manheimer, monnier, emacs-devel,
Barry Warsaw
Richard Stallman writes:
> It's not worth harping on, but I'm pretty sure that the FSF has had
> copyright assignments for python-mode.el from all the main developers
> for some time now.
>
> Someone said Kyle Jones was a developer of it,
I wonder if you're recalling that I said that Kyle had a hand in
XEmacs's portable dumper? I know of no connection between Kyle and
python-mode.el.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 1:49 ` Stefan Monnier
@ 2008-02-22 13:44 ` Barry Warsaw
2008-02-22 15:13 ` skip
0 siblings, 1 reply; 81+ messages in thread
From: Barry Warsaw @ 2008-02-22 13:44 UTC (permalink / raw)
To: Stefan Monnier
Cc: skip, rms, nickrob, emacs-devel, Ken Manheimer, sdl.web, cyd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 21, 2008, at 8:49 PM, Stefan Monnier wrote:
>> Maybe we should try to do the same thing you're doing with allout,
>> et all.
>> Maintain it separately and sync it to the Emacs repo occasionally?
>
> Having it outside Emacs's own repository is fine. The only thing that
> matters is that the 2 branches stay in close sync: some people may
> commit changes directly to the Emacs repository, so you have to watch
> out for it, make sure that those changes don't get lost (or do get
> properly rejected/rewritten/fixed if there's a problem with it).
Cool. I think with Ken's help, we can easily do this. Let's keep it
in a separate repository.
I've created the project on Launchpad:
https://launchpad.net/python-mode/
I haven't yet done an import from SF, but I'll do that once we all
agree that this is the right way to go (I think Ken and Skip are on
board). I'll get the svn imported into bzr and suck over any SF
tracker issues.
Right now, I've marked the license as the Python license. If y'all
tell me we can legally GPL it, I'll double check with the Python
community, and if everyone there is cool with it, we'll make the
switch. Then folks can start planning the integration work.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR77RrXEjvBPtnXfVAQI6owP+NnjebGnq1uwwC/Zbls6Yim+2Ee1P709X
f7nyeJF9//p5fph2ZKFdaa7U54w0iVU2n+gQzwgRKuAK7OwKOYcWyuZU2w/hSBeq
9SVsXRAJ1Nk50jmX5Hvg7ET2EbnFbasPLGaXCYCCgpnPW8FLRDeDWcWUxngu2G0Q
ZLIxynts52c=
=v8/+
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 3:23 ` Stephen J. Turnbull
@ 2008-02-22 13:45 ` Barry Warsaw
2008-02-22 16:28 ` Stefan Monnier
2008-02-22 22:57 ` Richard Stallman
0 siblings, 2 replies; 81+ messages in thread
From: Barry Warsaw @ 2008-02-22 13:45 UTC (permalink / raw)
To: Stephen J. Turnbull
Cc: cyd, skip, rms, nickrob, emacs-devel, ken.manheimer, monnier,
sdl.web
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 21, 2008, at 10:23 PM, Stephen J. Turnbull wrote:
> Richard Stallman writes:
>
>> It's not worth harping on, but I'm pretty sure that the FSF has
>> had
>> copyright assignments for python-mode.el from all the main
>> developers
>> for some time now.
>>
>> Someone said Kyle Jones was a developer of it,
>
> I wonder if you're recalling that I said that Kyle had a hand in
> XEmacs's portable dumper? I know of no connection between Kyle and
> python-mode.el.
Ken mentioned that perhaps Richard was thinking of Tim Peters, the
original author of python-mode.el. Tim, to the best of my knowledge,
is certain that he's signed papers for his original work.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR77R+HEjvBPtnXfVAQLz0AP/a1cKFYejRY0eI1yc/Ac0wSNSoBtQRgvt
qibVy+p3Coyw/KZVtjy6pXWifrqhltLlE/9pr9AUn/gnL8BXKo16hMANMsP3IHcQ
HsJyzxTWCAfr+MZmLk5+G+a2KTIGcMvsRuAs8GWpe9wqIvhyZXMMzDx8xncj5zyH
1shGGiIVVOU=
=g7Uz
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 13:44 ` Barry Warsaw
@ 2008-02-22 15:13 ` skip
2008-02-22 15:30 ` Barry Warsaw
0 siblings, 1 reply; 81+ messages in thread
From: skip @ 2008-02-22 15:13 UTC (permalink / raw)
To: Barry Warsaw
Cc: rms, nickrob, emacs-devel, Ken Manheimer, Stefan Monnier, sdl.web,
cyd
Barry> Right now, I've marked the license as the Python license. If
Barry> y'all tell me we can legally GPL it, I'll double check with the
Barry> Python community, and if everyone there is cool with it, we'll
Barry> make the switch. Then folks can start planning the integration
Barry> work.
At which point it will need to be removed from the Python core, right?
Skip
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 15:13 ` skip
@ 2008-02-22 15:30 ` Barry Warsaw
0 siblings, 0 replies; 81+ messages in thread
From: Barry Warsaw @ 2008-02-22 15:30 UTC (permalink / raw)
To: skip; +Cc: rms, nickrob, emacs-devel, Ken Manheimer, Stefan Monnier, sdl.web,
cyd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 22, 2008, at 10:13 AM, skip@pobox.com wrote:
>
> Barry> Right now, I've marked the license as the Python license.
> If
> Barry> y'all tell me we can legally GPL it, I'll double check
> with the
> Barry> Python community, and if everyone there is cool with it,
> we'll
> Barry> make the switch. Then folks can start planning the
> integration
> Barry> work.
>
> At which point it will need to be removed from the Python core, right?
Right.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR77qk3EjvBPtnXfVAQJO1gP+IqgaJ8C9VeYPdrSx+Dk5XhqcmY7TlD0I
MZ6XVtZE+eSaK+AZG2dms0kt9zzvRKBUwu9gCtwRZx5BRMBfHNcG1tvN6vVFXBVY
jDW+8J4B5nXb6vFOiwl+zbLKiNm8xyy+cGEO1cS06U/LtcIMsb5Lmn0KVYkl5qnX
X5zNP8gi82o=
=HaFL
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 13:45 ` Barry Warsaw
@ 2008-02-22 16:28 ` Stefan Monnier
2008-02-22 17:05 ` Barry Warsaw
2008-02-22 22:57 ` Richard Stallman
1 sibling, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-22 16:28 UTC (permalink / raw)
To: Barry Warsaw
Cc: cyd, skip, rms, nickrob, emacs-devel, ken.manheimer,
Stephen J. Turnbull, sdl.web
> Ken mentioned that perhaps Richard was thinking of Tim Peters, the original
> author of python-mode.el. Tim, to the best of my knowledge, is certain
> that he's signed papers for his original work.
Indeed we have an assignment from Tim Peters for python-mode.el.
OTOH we don't have an assignment from you AFAICT (well, we have many
assignments from you, but none that seems to cover python-mode).
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 16:28 ` Stefan Monnier
@ 2008-02-22 17:05 ` Barry Warsaw
2008-02-22 17:13 ` Ken Manheimer
2008-02-22 18:27 ` Stefan Monnier
0 siblings, 2 replies; 81+ messages in thread
From: Barry Warsaw @ 2008-02-22 17:05 UTC (permalink / raw)
To: Stefan Monnier
Cc: cyd, skip, rms, nickrob, emacs-devel, ken.manheimer,
Stephen J. Turnbull, sdl.web
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 22, 2008, at 11:28 AM, Stefan Monnier wrote:
>> Ken mentioned that perhaps Richard was thinking of Tim Peters, the
>> original
>> author of python-mode.el. Tim, to the best of my knowledge, is
>> certain
>> that he's signed papers for his original work.
>
> Indeed we have an assignment from Tim Peters for python-mode.el.
> OTOH we don't have an assignment from you AFAICT (well, we have many
> assignments from you, but none that seems to cover python-mode).
Dang. I'm sure I signed one, but I certainly don't mind signing it
again. Send me the forms and I'll turn it around quickly.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR78AxnEjvBPtnXfVAQKEeQQArD1RnTwqMzGQBc95ZCX2+CpA1koUAmt+
+BLTWSKfKT74pcsFSFFTdi3r6yquQ6mxxFxbYMgmHwTwb7q5Myvc4qoIA94gwlMP
8kHmPBMbwZVHrE3HtTDf1EpFb6pkkrhkMEn8b48uUpVdgoBiXGEt2RIQk4Ok9dto
xgIfw103qS4=
=ud5M
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 17:05 ` Barry Warsaw
@ 2008-02-22 17:13 ` Ken Manheimer
2008-02-22 18:27 ` Stefan Monnier
1 sibling, 0 replies; 81+ messages in thread
From: Ken Manheimer @ 2008-02-22 17:13 UTC (permalink / raw)
To: Barry Warsaw
Cc: cyd, skip, rms, nickrob, emacs-devel, Stefan Monnier,
Stephen J. Turnbull, sdl.web
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
i must say, "yay!"
(it's not apparent to me how a consolidation is actually going to proceed -
we haven't heard from dave love, it may be that python-mode.el will offer a
better starting point once the changes that dave initially submitted in his
neglected patch - updated with later python.el developments - is applied? i
don't know who among the people who have maintained one or the other will
have time. i'm finishing up the pdbtrack port and cleanup, even though
eventual consolidation may make that moot - still not bad to have it in
place, modulo any mistakes i may have made...)
ken
On Fri, Feb 22, 2008 at 12:05 PM, Barry Warsaw <barry@python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Feb 22, 2008, at 11:28 AM, Stefan Monnier wrote:
>
> >> Ken mentioned that perhaps Richard was thinking of Tim Peters, the
> >> original
> >> author of python-mode.el. Tim, to the best of my knowledge, is
> >> certain
> >> that he's signed papers for his original work.
> >
> > Indeed we have an assignment from Tim Peters for python-mode.el.
> > OTOH we don't have an assignment from you AFAICT (well, we have many
> > assignments from you, but none that seems to cover python-mode).
>
> Dang. I'm sure I signed one, but I certainly don't mind signing it
> again. Send me the forms and I'll turn it around quickly.
>
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iQCVAwUBR78AxnEjvBPtnXfVAQKEeQQArD1RnTwqMzGQBc95ZCX2+CpA1koUAmt+
> +BLTWSKfKT74pcsFSFFTdi3r6yquQ6mxxFxbYMgmHwTwb7q5Myvc4qoIA94gwlMP
> 8kHmPBMbwZVHrE3HtTDf1EpFb6pkkrhkMEn8b48uUpVdgoBiXGEt2RIQk4Ok9dto
> xgIfw103qS4=
> =ud5M
> -----END PGP SIGNATURE-----
>
--
ken
http://myriadicity.net
[-- Attachment #2: Type: text/html, Size: 2302 bytes --]
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-21 23:35 ` pdbtrack Glenn Morris
@ 2008-02-22 18:00 ` Ken Manheimer
2008-02-22 18:35 ` pdbtrack Stefan Monnier
2008-02-22 20:08 ` pdbtrack Nick Roberts
0 siblings, 2 replies; 81+ messages in thread
From: Ken Manheimer @ 2008-02-22 18:00 UTC (permalink / raw)
To: Glenn Morris; +Cc: Nick Roberts, emacs-devel
On Thu, Feb 21, 2008 at 6:35 PM, Glenn Morris <rgm@gnu.org> wrote:
> "Ken Manheimer" wrote:
>
> > none of these functions have anything to do with the pdbtrack changes
> > that nick made. they all appear to be preexisting artifacts of an
> > incomplete adoption of code from python-mode.el.
>
> You seem to misunderstand. None of these function references were
> there until Nick checked in his pdbtrack changes in rev 1.81. It's not
> a "pre-existing" condition. The code that calls these functions has
> been attributed to you in the ChangeLog (2008-02-19).
oops - you're right, my mistake. i'm sorry to i mistakenly suggested
that python.el fails to make proper attributions! (i didn't remember
putting the code into python.el because i didn't actually do it - nick
copied it from an old version of python-mode.el, and generously
attributed the changes to me.)
i've committed changes which settle the compiler warnings by removing
the python-mode.el ingredients unnecessary for pdbtracking,. i left
in python-shell, however, in case that might be useful. hopefully
there'll be a more complete reconciliation of the two python mode
implementations soon, but until then this should cleanly convey
pdbtracking to python.el users.
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 17:05 ` Barry Warsaw
2008-02-22 17:13 ` Ken Manheimer
@ 2008-02-22 18:27 ` Stefan Monnier
2008-02-22 19:38 ` Barry Warsaw
1 sibling, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-22 18:27 UTC (permalink / raw)
To: Barry Warsaw
Cc: cyd, skip, rms, nickrob, emacs-devel, ken.manheimer,
Stephen J. Turnbull, sdl.web
>>> Ken mentioned that perhaps Richard was thinking of Tim Peters, the
>>> original
>>> author of python-mode.el. Tim, to the best of my knowledge, is certain
>>> that he's signed papers for his original work.
>>
>> Indeed we have an assignment from Tim Peters for python-mode.el.
>> OTOH we don't have an assignment from you AFAICT (well, we have many
>> assignments from you, but none that seems to cover python-mode).
> Dang. I'm sure I signed one, but I certainly don't mind signing it again.
> Send me the forms and I'll turn it around quickly.
You've signed many assignments for specific parts of Emacs, but I can't
find (in that long list) one that cover all Emacs changes (which is the
usual assignment for people who contribute more than a single package to
Emacs).
So maybe you want to sign an assignment for all changes to Emacs, this
way any future package/patch you want to submit for inclusion can be
accepted without any extra paperwork (just a clear email statement that
you consider it as covered by that prior assignment is sufficient).
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-22 18:00 ` pdbtrack Ken Manheimer
@ 2008-02-22 18:35 ` Stefan Monnier
2008-02-23 23:09 ` pdbtrack Ken Manheimer
2008-02-22 20:08 ` pdbtrack Nick Roberts
1 sibling, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-22 18:35 UTC (permalink / raw)
To: Ken Manheimer; +Cc: Glenn Morris, Nick Roberts, emacs-devel
> copied it from an old version of python-mode.el, and generously
> attributed the changes to me.)
Actually, it's not generosity. but simply the need for the attribution
to faithfully reflect the original author of the code, i.e. the person
who can claim copyright.
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 18:27 ` Stefan Monnier
@ 2008-02-22 19:38 ` Barry Warsaw
2008-02-23 19:28 ` Richard Stallman
0 siblings, 1 reply; 81+ messages in thread
From: Barry Warsaw @ 2008-02-22 19:38 UTC (permalink / raw)
To: Stefan Monnier
Cc: cyd, skip, rms, nickrob, emacs-devel, ken.manheimer,
Stephen J. Turnbull, sdl.web
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 22, 2008, at 1:27 PM, Stefan Monnier wrote:
> So maybe you want to sign an assignment for all changes to Emacs, this
> way any future package/patch you want to submit for inclusion can be
> accepted without any extra paperwork (just a clear email statement
> that
> you consider it as covered by that prior assignment is sufficient).
I consider all my past and future changes to Emacs to be covered by my
prior assignments.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR78krXEjvBPtnXfVAQL0zgP+I9dLQ4Vq0Jh2YCzeR+BoHG2gI8CTQKmS
2ctq2OItPZA1lGYEqUPQOUloxfQmZj1qkJLdk+Qb9CC9MOpX6ohWPZmISsEANgAd
7aeaQ/2Fx7mei4WVytsqWqVncvY2vXMuutOWgvYMrdDK3//4CpEEiunyyujF8cXa
qPl6FW/+5wA=
=GfNc
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-22 18:00 ` pdbtrack Ken Manheimer
2008-02-22 18:35 ` pdbtrack Stefan Monnier
@ 2008-02-22 20:08 ` Nick Roberts
2008-02-23 23:16 ` pdbtrack Ken Manheimer
1 sibling, 1 reply; 81+ messages in thread
From: Nick Roberts @ 2008-02-22 20:08 UTC (permalink / raw)
To: Ken Manheimer; +Cc: Glenn Morris, emacs-devel
> i've committed changes which settle the compiler warnings by removing
> the python-mode.el ingredients unnecessary for pdbtracking,. i left
> in python-shell, however, in case that might be useful. hopefully
> there'll be a more complete reconciliation of the two python mode
> implementations soon, but until then this should cleanly convey
> pdbtracking to python.el users.
I think it would be a good idea to put something in the manual about
pdbtrack to help users will find out about. Perhaps a node listed after
"GDB Grapical Interface" in the "Debuggers" node and a reference from the
description of M-x pdb in the "Starting GUD" node. It needn't be long. You
could base it on the description you've recently posted to this list
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 23:00 ` Barry Warsaw
2008-02-21 23:08 ` Ken Manheimer
@ 2008-02-22 22:57 ` Richard Stallman
2008-02-22 22:57 ` Richard Stallman
2 siblings, 0 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-22 22:57 UTC (permalink / raw)
To: Barry Warsaw
Cc: skip, sdl.web, nickrob, emacs-devel, ken.manheimer, monnier, cyd
I don't remember Kyle ever having touched it. Tim Peters was the
original author of python-mode.el. Other than that, I know Ken, Skip,
and myself have hacked on it. Grep'ing on the Subversion history, it
looks like Ed Loper also checked stuff in.
To arrange to install this, the first step is to get a complete list
of contributors.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-21 23:00 ` Barry Warsaw
2008-02-21 23:08 ` Ken Manheimer
2008-02-22 22:57 ` Richard Stallman
@ 2008-02-22 22:57 ` Richard Stallman
2 siblings, 0 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-22 22:57 UTC (permalink / raw)
To: Barry Warsaw
Cc: skip, sdl.web, nickrob, emacs-devel, ken.manheimer, monnier, cyd
Two problems with that: I'd really like to develop the code with
Bazaar, and I want to make sure that we can still support XEmacs.
We are hoping to move Emacs to Bzr, and it is ok to have XEmacs
compatibility code.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 13:45 ` Barry Warsaw
2008-02-22 16:28 ` Stefan Monnier
@ 2008-02-22 22:57 ` Richard Stallman
2008-02-22 23:33 ` Barry Warsaw
2008-02-23 0:09 ` skip
1 sibling, 2 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-22 22:57 UTC (permalink / raw)
To: Barry Warsaw
Cc: cyd, skip, nickrob, emacs-devel, ken.manheimer, monnier, stephen,
sdl.web
Ken mentioned that perhaps Richard was thinking of Tim Peters, the
original author of python-mode.el.
I don't think I was thinking specifically of Tim Peters,
but he may be part of the group I was thinking about.
Can you make a list of the contributors, so we can consider this issue
systematically?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 22:57 ` Richard Stallman
@ 2008-02-22 23:33 ` Barry Warsaw
2008-02-23 19:29 ` Richard Stallman
2008-02-23 0:09 ` skip
1 sibling, 1 reply; 81+ messages in thread
From: Barry Warsaw @ 2008-02-22 23:33 UTC (permalink / raw)
To: rms
Cc: cyd, skip, nickrob, emacs-devel, ken.manheimer, monnier, stephen,
sdl.web
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 22, 2008, at 5:57 PM, Richard Stallman wrote:
> Ken mentioned that perhaps Richard was thinking of Tim Peters, the
> original author of python-mode.el.
>
> I don't think I was thinking specifically of Tim Peters,
> but he may be part of the group I was thinking about.
>
> Can you make a list of the contributors, so we can consider this issue
> systematically?
We know about Tim, Ken, Skip, Ed and myself. Doing a quick scan
through the svn logs, I also see these other names mentioned: Carl
Banks, Gary Feldman, Thomas Heller, Thomas Guettler, Charles Waldman,
Ted Whalen, Bernard Herzog, Kevin J. Butler, Alexander Schmolck,
Francois Pinard, Hunter Kelly, Daniel Calvelo, Christian Tanzer,
Michael Ernst, Harri Pasanen, Torsten Hilbrich, Sjoerd Mullender, Per
Cederqvist.
I have no idea how to get in touch with these folks. Some of those
attributions are more than a decade old. The svn revision history
goes back to 1994.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR79byXEjvBPtnXfVAQKhBQP/abzzAspAC9oaIEHnx3rcVYrg1xF/AxMv
kZoQcwREE6l8DNVlnZi+maH8EgC9QixAW1xfl2TrfrdttA4XsGfufJ2fdnoBtARF
xGW1YAcrEGmZmLA/ooe8pP0g/umof6VdZxTvxwxjmSWlGIU0GGLyN8XGU+lFA/Up
c4pJgRZza2M=
=S8Q5
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 22:57 ` Richard Stallman
2008-02-22 23:33 ` Barry Warsaw
@ 2008-02-23 0:09 ` skip
2008-02-25 13:53 ` Bernhard Herzog
1 sibling, 1 reply; 81+ messages in thread
From: skip @ 2008-02-23 0:09 UTC (permalink / raw)
To: rms
Cc: cyd, sdl.web, nickrob, emacs-devel, ken.manheimer, monnier,
stephen, Barry Warsaw
Richard> Can you make a list of the contributors, so we can consider
Richard> this issue systematically?
Based on checkin user names and comments, here's what I've come up with:
SF python-mode project:
Tim Peters
Barry Warsaw
Ken Manheimer
Skip Montanaro
Gary Feldman (r410, 2005-06-04, patch #875046)
Thomas Heller (r407, 2004-12-08)
Thomas Guettler (ditto)
Charles Waldman (r405, 2004-10-23)
Ted Whalen (r404, 2004-10-23)
Ed Loper (r403, 2004-10-23)
Per Cederqvist (r381, 2003-12-09)
Bernhard Herzog (r377, 2003-12-19, patch #862952)
Kevin J. Butler (r330, 2002-04-25, patch #510288)
Alexander Schmolck (r325, 2002-04-22)
Christian Stork (r310, 2002-03-15, patch #523825)
Hunter Kelly (r205, 1998-11-17)
Christian Tanzer (r186, 1998-08-10)
Michael Ernst (r183, 1998-08-10)
Sjoerd Mullender (r160, 1998-03-20)
Harri Pasanen (r137, 1997-12-05)
Christian Egli (r126, 1997-11-26)
Torsten Hilbrich (r124, 1997-11-25)
For minor contributors who were mentioned in checkins, I've included
information relevant to where I first noticed their name (though not
repeats). Where there is no patch # indicated I suppose we'll have to
determine if they just submitted a bug report or if we forgot to mention a
patch in the checkin message. I make no judgement on the complexity or size
of the patches, just what was mentioned.
--
Skip Montanaro - skip@pobox.com - http://www.webfast.com/~skip/
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 19:38 ` Barry Warsaw
@ 2008-02-23 19:28 ` Richard Stallman
2008-02-23 20:16 ` skip
0 siblings, 1 reply; 81+ messages in thread
From: Richard Stallman @ 2008-02-23 19:28 UTC (permalink / raw)
To: Barry Warsaw
Cc: cyd, skip, nickrob, emacs-devel, ken.manheimer, monnier, stephen,
sdl.web
I consider all my past and future changes to Emacs to be covered by my
prior assignments.
Each of your past assignments covers a specifically named new package,
so we cannot stretch them to cover other Emacs changes. However, if
you sign a general assignment for Emacs changes, that will take care
of it.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-22 23:33 ` Barry Warsaw
@ 2008-02-23 19:29 ` Richard Stallman
0 siblings, 0 replies; 81+ messages in thread
From: Richard Stallman @ 2008-02-23 19:29 UTC (permalink / raw)
To: Barry Warsaw
Cc: cyd, skip, nickrob, emacs-devel, ken.manheimer, monnier, stephen,
sdl.web
We know about Tim, Ken, Skip, Ed and myself. Doing a quick scan
through the svn logs, I also see these other names mentioned: Carl
Banks, Gary Feldman, Thomas Heller, Thomas Guettler, Charles Waldman,
Ted Whalen, Bernard Herzog, Kevin J. Butler, Alexander Schmolck,
Francois Pinard, Hunter Kelly, Daniel Calvelo, Christian Tanzer,
Michael Ernst, Harri Pasanen, Torsten Hilbrich, Sjoerd Mullender, Per
Cederqvist.
I have no idea how to get in touch with these folks. Some of those
attributions are more than a decade old.
The next step is to find out how muc hcode each of those minor
contributors wrote. Probably several of them wrote under 15 lines and
we can eliminate their names from the list we are concerned about.
Who is left?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-23 19:28 ` Richard Stallman
@ 2008-02-23 20:16 ` skip
0 siblings, 0 replies; 81+ messages in thread
From: skip @ 2008-02-23 20:16 UTC (permalink / raw)
To: rms
Cc: cyd, sdl.web, nickrob, emacs-devel, ken.manheimer, monnier,
stephen, Barry Warsaw
Richard> Each of your past assignments covers a specifically named new
Richard> package, so we cannot stretch them to cover other Emacs
Richard> changes. However, if you sign a general assignment for Emacs
Richard> changes, that will take care of it.
I googled around a bit yesterday but couldn't find anything that said,
"print this, sign it and send it to ...". Do you have a URL?
--
Skip Montanaro - skip@pobox.com - http://www.webfast.com/~skip/
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-22 18:35 ` pdbtrack Stefan Monnier
@ 2008-02-23 23:09 ` Ken Manheimer
0 siblings, 0 replies; 81+ messages in thread
From: Ken Manheimer @ 2008-02-23 23:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Glenn Morris, Nick Roberts, emacs-devel
On Fri, Feb 22, 2008 at 1:35 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > copied it from an old version of python-mode.el, and generously
> > attributed the changes to me.)
>
> Actually, it's not generosity. but simply the need for the attribution
> to faithfully reflect the original author of the code, i.e. the person
> who can claim copyright.
i kinda figured, but also wanted to clarify why i didn't "remember"
putting those bits into python.el. "generosity" was a grace note,
maybe a bit excessive but i was feeling like i had been particularly
graceless in mistakenly blaming python.el for neglecting some
attribution.
python.el authors for neglecting to attribute use of python-mode.el code.
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-22 20:08 ` pdbtrack Nick Roberts
@ 2008-02-23 23:16 ` Ken Manheimer
2008-02-24 4:49 ` pdbtrack Nick Roberts
0 siblings, 1 reply; 81+ messages in thread
From: Ken Manheimer @ 2008-02-23 23:16 UTC (permalink / raw)
To: Nick Roberts; +Cc: Glenn Morris, emacs-devel
On 2/22/08, Nick Roberts <nickrob@snap.net.nz> wrote:
> > i've committed changes which settle the compiler warnings by removing
> > the python-mode.el ingredients unnecessary for pdbtracking,. i left
> > in python-shell, however, in case that might be useful. hopefully
> > there'll be a more complete reconciliation of the two python mode
> > implementations soon, but until then this should cleanly convey
> > pdbtracking to python.el users.
> I think it would be a good idea to put something in the manual about
> pdbtrack to help users will find out about. Perhaps a node listed after
> "GDB Grapical Interface" in the "Debuggers" node and a reference from the
> description of M-x pdb in the "Starting GUD" node. It needn't be long. You
> could base it on the description you've recently posted to this list
that is a good idea - both adding a manual entry for it and getting a
jump start by adopting material from what i already wrote. i'll try
to get to it soon - is there a particular date impending for the next
emacs minor release?
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-23 23:16 ` pdbtrack Ken Manheimer
@ 2008-02-24 4:49 ` Nick Roberts
2008-02-24 15:40 ` pdbtrack Stefan Monnier
0 siblings, 1 reply; 81+ messages in thread
From: Nick Roberts @ 2008-02-24 4:49 UTC (permalink / raw)
To: Ken Manheimer; +Cc: Glenn Morris, emacs-devel
> that is a good idea - both adding a manual entry for it and getting a
> jump start by adopting material from what i already wrote. i'll try
> to get to it soon - is there a particular date impending for the next
> emacs minor release?
The next minor release (Emacs 22.2) will be made shortly from the branch
EMACS_22_BASE but I installed the changes for pdbtrack on the trunk from where
the next _major_ release will be made (Emacs 23.1?). I don't want to
disappoint you but the release period between Emacs 21.1 and Emacs 22.1 was
five and a half years. The release of 23.1 might be quicker, now that RMS is
stepping down as maintainer, but I would still be surprised if it was under two
years given that emacs-unicode-2 has recently been merged to the trunk.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-24 4:49 ` pdbtrack Nick Roberts
@ 2008-02-24 15:40 ` Stefan Monnier
2008-02-24 17:00 ` pdbtrack Ken Manheimer
0 siblings, 1 reply; 81+ messages in thread
From: Stefan Monnier @ 2008-02-24 15:40 UTC (permalink / raw)
To: Nick Roberts; +Cc: Glenn Morris, Ken Manheimer, emacs-devel
>> that is a good idea - both adding a manual entry for it and getting a
>> jump start by adopting material from what i already wrote. i'll try
>> to get to it soon - is there a particular date impending for the next
>> emacs minor release?
> The next minor release (Emacs 22.2) will be made shortly from the
> branch EMACS_22_BASE but I installed the changes for pdbtrack on the
> trunk from where the next _major_ release will be made (Emacs 23.1?).
> I don't want to disappoint you but the release period between Emacs
> 21.1 and Emacs 22.1 was five and a half years. The release of 23.1
> might be quicker, now that RMS is stepping down as maintainer, but
> I would still be surprised if it was under two years given that
> emacs-unicode-2 has recently been merged to the trunk.
We could add it for Emacs-22.3, if Ken wants to go through the
extra trouble.
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-24 15:40 ` pdbtrack Stefan Monnier
@ 2008-02-24 17:00 ` Ken Manheimer
2008-02-24 20:44 ` pdbtrack Stefan Monnier
0 siblings, 1 reply; 81+ messages in thread
From: Ken Manheimer @ 2008-02-24 17:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Glenn Morris, Nick Roberts, emacs-devel
On Sun, Feb 24, 2008 at 10:40 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> >> that is a good idea - both adding a manual entry for it and getting a
> >> jump start by adopting material from what i already wrote. i'll try
> >> to get to it soon - is there a particular date impending for the next
> >> emacs minor release?
>
> > The next minor release (Emacs 22.2) will be made shortly from the
> > branch EMACS_22_BASE but I installed the changes for pdbtrack on the
> > trunk from where the next _major_ release will be made (Emacs 23.1?).
> > I don't want to disappoint you but the release period between Emacs
> > 21.1 and Emacs 22.1 was five and a half years. The release of 23.1
> > might be quicker, now that RMS is stepping down as maintainer, but
> > I would still be surprised if it was under two years given that
> > emacs-unicode-2 has recently been merged to the trunk.
>
> We could add it for Emacs-22.3, if Ken wants to go through the
> extra trouble.
i would like to see the changes released. what's the "extra trouble"?
--
ken
http://myriadicity.net
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: pdbtrack
2008-02-24 17:00 ` pdbtrack Ken Manheimer
@ 2008-02-24 20:44 ` Stefan Monnier
0 siblings, 0 replies; 81+ messages in thread
From: Stefan Monnier @ 2008-02-24 20:44 UTC (permalink / raw)
To: Ken Manheimer; +Cc: Glenn Morris, Nick Roberts, emacs-devel
>> >> that is a good idea - both adding a manual entry for it and getting a
>> >> jump start by adopting material from what i already wrote. i'll try
>> >> to get to it soon - is there a particular date impending for the next
>> >> emacs minor release?
>>
>> > The next minor release (Emacs 22.2) will be made shortly from the
>> > branch EMACS_22_BASE but I installed the changes for pdbtrack on the
>> > trunk from where the next _major_ release will be made (Emacs 23.1?).
>> > I don't want to disappoint you but the release period between Emacs
>> > 21.1 and Emacs 22.1 was five and a half years. The release of 23.1
>> > might be quicker, now that RMS is stepping down as maintainer, but
>> > I would still be surprised if it was under two years given that
>> > emacs-unicode-2 has recently been merged to the trunk.
>>
>> We could add it for Emacs-22.3, if Ken wants to go through the
>> extra trouble.
> i would like to see the changes released. what's the "extra trouble"?
Back port the changes on the 22 branch (after 22.2 is released) and then
keep debugging it there, while keeping the changes syncs on the trunk
even if the trunk's version changes differently.
Of course, we don't actually know yet whether there will be
a 22.3 release.
Stefan
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: python.el fixes for Emacs 22
2008-02-23 0:09 ` skip
@ 2008-02-25 13:53 ` Bernhard Herzog
0 siblings, 0 replies; 81+ messages in thread
From: Bernhard Herzog @ 2008-02-25 13:53 UTC (permalink / raw)
To: skip
Cc: rms, nickrob, emacs-devel, ken.manheimer, Barry Warsaw, monnier,
sdl.web, stephen, cyd
skip@pobox.com writes:
> Richard> Can you make a list of the contributors, so we can consider
> Richard> this issue systematically?
>
> Based on checkin user names and comments, here's what I've come up with:
>
> SF python-mode project:
[...]
> Bernhard Herzog (r377, 2003-12-19, patch #862952)
There are also these:
r378, 2003-12-19, patch #862954
r371, 2003-07-31, patch #779830
r343, 2002-12-31, http://mail.python.org/pipermail/python-list/2002-May/144236.html
Except for the last one, all patche are very minor, only modifying a few
lines each. Some of the code in the last one is actually derived from
Emacs lisp-mode code.
Bernhard
--
Bernhard Herzog Intevation GmbH, Osnabrück
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
^ permalink raw reply [flat|nested] 81+ messages in thread
end of thread, other threads:[~2008-02-25 13:53 UTC | newest]
Thread overview: 81+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-11 13:34 python.el fixes for Emacs 22 Richard Stallman
2008-02-11 15:15 ` Stefan Monnier
2008-02-11 21:10 ` Richard Stallman
2008-02-12 3:04 ` Stefan Monnier
2008-02-12 17:44 ` Richard Stallman
2008-02-12 21:40 ` Stefan Monnier
2008-02-13 16:32 ` Richard Stallman
2008-02-13 19:19 ` Stefan Monnier
2008-02-14 0:36 ` Chong Yidong
2008-02-14 0:51 ` Miles Bader
2008-02-14 1:56 ` Leo
2008-02-14 18:11 ` Richard Stallman
2008-02-14 23:42 ` Leo
2008-02-15 0:01 ` Nick Roberts
2008-02-15 0:08 ` Leo
2008-02-15 0:17 ` Miles Bader
2008-02-15 2:10 ` Nick Roberts
2008-02-15 17:57 ` Ken Manheimer
2008-02-16 5:53 ` Richard Stallman
2008-02-16 8:18 ` Leo
2008-02-16 8:35 ` Miles Bader
2008-02-16 14:45 ` Stefan Monnier
2008-02-16 14:51 ` Miles Bader
2008-02-17 3:44 ` Stephen J. Turnbull
2008-02-17 13:22 ` Richard Stallman
2008-02-17 13:26 ` Piet van Oostrum
2008-02-15 12:59 ` Richard Stallman
2008-02-15 13:27 ` David Kastrup
2008-02-15 17:43 ` Ken Manheimer
2008-02-15 21:47 ` Nick Roberts
2008-02-15 22:21 ` Ken Manheimer
2008-02-15 23:57 ` Nick Roberts
2008-02-16 0:22 ` Ken Manheimer
2008-02-16 0:39 ` python.el versus python-mode.el [was Re: python.el fixes for Emacs 22] Glenn Morris
2008-02-17 13:22 ` python.el fixes for Emacs 22 Richard Stallman
2008-02-17 13:22 ` Richard Stallman
2008-02-20 0:30 ` Nick Roberts
2008-02-20 2:24 ` pdbtrack [was Re: python.el fixes for Emacs 22] Glenn Morris
2008-02-20 2:34 ` Nick Roberts
2008-02-20 2:56 ` pdbtrack Glenn Morris
2008-02-21 22:40 ` pdbtrack [was Re: python.el fixes for Emacs 22] Ken Manheimer
2008-02-21 23:35 ` pdbtrack Glenn Morris
2008-02-22 18:00 ` pdbtrack Ken Manheimer
2008-02-22 18:35 ` pdbtrack Stefan Monnier
2008-02-23 23:09 ` pdbtrack Ken Manheimer
2008-02-22 20:08 ` pdbtrack Nick Roberts
2008-02-23 23:16 ` pdbtrack Ken Manheimer
2008-02-24 4:49 ` pdbtrack Nick Roberts
2008-02-24 15:40 ` pdbtrack Stefan Monnier
2008-02-24 17:00 ` pdbtrack Ken Manheimer
2008-02-24 20:44 ` pdbtrack Stefan Monnier
2008-02-21 0:20 ` python.el fixes for Emacs 22 Ken Manheimer
2008-02-21 4:02 ` Stefan Monnier
2008-02-21 5:12 ` Barry Warsaw
2008-02-21 22:28 ` Richard Stallman
2008-02-21 23:00 ` Barry Warsaw
2008-02-21 23:08 ` Ken Manheimer
2008-02-21 23:12 ` Barry Warsaw
2008-02-22 1:49 ` Stefan Monnier
2008-02-22 13:44 ` Barry Warsaw
2008-02-22 15:13 ` skip
2008-02-22 15:30 ` Barry Warsaw
2008-02-22 22:57 ` Richard Stallman
2008-02-22 22:57 ` Richard Stallman
2008-02-22 3:23 ` Stephen J. Turnbull
2008-02-22 13:45 ` Barry Warsaw
2008-02-22 16:28 ` Stefan Monnier
2008-02-22 17:05 ` Barry Warsaw
2008-02-22 17:13 ` Ken Manheimer
2008-02-22 18:27 ` Stefan Monnier
2008-02-22 19:38 ` Barry Warsaw
2008-02-23 19:28 ` Richard Stallman
2008-02-23 20:16 ` skip
2008-02-22 22:57 ` Richard Stallman
2008-02-22 23:33 ` Barry Warsaw
2008-02-23 19:29 ` Richard Stallman
2008-02-23 0:09 ` skip
2008-02-25 13:53 ` Bernhard Herzog
2008-02-21 5:09 ` Barry Warsaw
2008-02-21 5:22 ` Nick Roberts
2008-02-15 16:51 ` Chong Yidong
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).