> ... I would find it pleasing to have a 'DEDENT here' hint for emacs to
> use ... can not trust 'TAB' to do the right thing on the first
> DEDENTed line.
Right. There are warnings about this in the long form of the py-mode
docs (do `C-c ?' while visiting a .py file).
> This could be implemented trivially with only elisp changes to
> recognize #<- or #END or some such nonsense.
You don't need to change py-mode for just that; see the "Comment Lines"
subsection of the "@KINDS OF LINES" section of the long form of the
py-mode docs.
py-mode, unlike Python, distinguishes between "indenting" and "non-
indenting" comment lines, and respects the indentation of the former when
figuring out what indentation TAB should suggest. So, e.g., "# END" is
already an indenting comment line and will already do what you want from
it (although "#END" will not).
More commonly I've seen comments of this form (matching the following
regexp) used for this purpose:
^[ \t]*#[ \t]*$
py-mode considers those to be indenting comment lines too. I _usually_
see this only after "def" blocks, though:
class Act:
def a(self):
i = 0
if something:
i = 1 # rarely see the trick after the `if' block
return i # TAB copies the "i = 1" indent here
#
def b(self): # TAB copies the "#" indent here
I personally never use this, because I dislike its looks. But py-mode's
support for it is intentional and eternal <wink>.
> Arranging for DELs that delete INDENTS to instead (optionally) insert
> #END and skip to the next line would save all the typing as well.
If this proves a popular idea, I'd have no problem with adding a new mode
flag to support it conditionally. The end-of-block marker would be
defined as the value of a user-overridable string variable, and the
various "mark a block" functions would need to be fiddled to consider the
end marker to be part of the block (all comment lines today are treated
as if they were part of the following block, since that's most common
(comment lines usually talk about what follows them)).
So, do people want this?
> ... I also mangled the bindings to overlay 'py-newline-and-indent on
> just 'newline as well, since I find that much more useful.
Between you & Guido, py-mode would remap every key on the board ... Some
key sequences were intended to be remapped by language modes, but most
weren't. Specifically, the built-in Emacs documention for the out-of-
the-box LFD and TAB bindings says they're mode-specific, but RET means
plain "newline" in all language modes.
There's nothing wrong with binding any key to any function you want, but
rebinding traditionally mode-invariant keys belongs in an individual's
.emacs file. E.g., to bind RET to py-newline-and-indent in Python
buffers, you can just stick this in your .emacs file:
(setq py-mode-hook
'(lambda ()
(define-key py-mode-map "\r" 'py-newline-and-indent)))
Language modes support xxx-mode-hook variables so you can do "surprising"
customizations like this without altering the mode source.
defending-the-status-quo-entirely-too-often-these-days-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp