diff options
author | Taylor R Campbell <campbell@mumble.net> | 2008-09-28 13:44:00 +0000 |
---|---|---|
committer | Taylor R Campbell <campbell@mumble.net> | 2008-09-28 13:44:00 +0000 |
commit | 342fee5dfeeff59f94875639b3daa9383ba856a0 (patch) | |
tree | 21f2d592a40f6d38ab00d02fff6241c8807dd9c2 /CREDITS | |
parent | 94645884ce0ee1e797dbf54f3fedcd72ed9ce7a7 (diff) |
Changes for version 21.v21
Paredit 21 no longer has a message releasing it into the public domain.
Instead it is copyright (C) 2008, Taylor R. Campbell, and available
under the terms of the 3-clause BSD licence. See the paredit.el file
for details.
*** Style and Bugs
- Use of the terms `parenthesis', `bracket', and `delimiter' has been
clarified throughout the file:
. /Parentheses/ are nestable objects indicated by matching delimiter
pairs. For example, the text `(foo (bar baz) quux)' has two
parentheses, `(foo ... quux)' and `(bar baz)'; each is delimited
by matching round delimiters.
. /Delimiters/ are the actual atomic objects that delimit
parentheses. They may be shaped differently; for example, `[' is
an opening square delimiter, and `{' is an opening curly
delimiter.
. The terms `bracket', `brace', and `brocket' (the latter a
misspelling of `broket', for `broken bracket') are eschewed.
The names `paredit-open-parenthesis' &c. have been changed to
`paredit-open-round' &c., and likewise with `bracket' -> `square',
`brace' -> `curly', and `brocket' -> `angled'. The old names with
the morphemes `parenthesis' and `bracket' have been preserved so that
users need not update initialization files immediately, but will
instead be confused when a subsequent minor update breaks all their
initialization files for no good reason.
- Some commands now check their context more strictly, so that they
won't try to do anything in comments or strings. Whether this is the
right thing, I don't know.
- Several small elements of style were adjusted. This should make no
functional difference on the code. (If it does, then I have made a
mistake.)
- paredit.el no longer defines `kill-region-new'; the function is
instead called `paredit-hack-kill-region', to reflect its hackish
nature and to avoid name clashes. I believe that the only name
remaining defined by paredit.el without `paredit-' prefixed is
`backward-down-list', whose definition is so obvious that it would be
silly to define it any other way, so that any name conflict does not
worry me. (I suppose `kill-region-new' is obvious, too -- it is to
`kill-region' as `kill-new' is to `kill'. But the omission from a
pattern isn't as clear as with `backward-down-list'.)
- `paredit-comment-dwim' should work in GNU Emacs 21 now, whose
newcomment.el defines no `comment-or-uncomment-region'. More and
more ugly compatibility hacks are accruing in paredit.el as a
consequence, to my dismay. Oh well.
- The release notes are now formatted more legibly, paginated nicely,
and organized with Outline Mode. The gross discrepancy in writing
style over the years has not changed.
- The introductory comments in the file are more clearly written now.
- Fixed a bug in S-expression slurpage with mixed delimiters.
*** Altered Behaviour
- The bindings for `)' and `M-)' have been exchanged: `)' is bound to
`paredit-close-round' and `M-)' to `paredit-close-round-and-newline',
so that you can now without any glaring exceptions type new code
using the same keystrokes with and without Paredit Mode. You can
also now paste into Emacs through a terminal without leaving spurious
blank lines in the buffer. You are, of course, free to revert to the
old behaviour in your .emacs file.
- `paredit-semicolon' is no more. Now you may insert semicolons as
you please without the infuriating escape of the following text on
the line.
- `paredit-move-past-close-and-newline' will now leave comments on the
same line only if they are margin comments and no S-expressions are
intervening between the point and the comment; that is, only if it
looks like the margin comment really pertains to the expression being
closed will paredit leave it on the same line.
- `paredit-backward-delete', `paredit-forward-delete', and
`paredit-kill' formerly accepted prefix arguments to run the basic
`backward-delete-char', `delete-char', and `kill-line' commands
instead, without regard for the value of the prefix argument. Now
`C-u' will run the basic commands, but
. `paredit-kill' will pass a numeric argument on to `kill-line', and
. `paredit-backward-delete' and `paredit-forward-delete' will both
delete N characters if given a numeric prefix argument N.
(`paredit-kill' should probably do the same, but repeating the
command N times is probably not what you want -- what you probably
want is to kill at most N *lines*, but `paredit-kill' N times might
kill many more lines than that. I don't know what the right thing is
here, but I welcome feedback from users who want to do something like
this.)
- With a `C-u' prefix argument, `paredit-wrap-sexp' now wraps all
S-expressions following the point until the end of the buffer or a
closing delimiter.
- `paredit-splice-sexp' with a `C-u' prefix argument (also known as
`paredit-splice-sexp-killing-backward') will now kill from the point,
rather than from the beginning of the next S-expression (or, with
`C-u C-u', from the end of the previous S-expression). This means
that it is more likely to do what you mean with
(let ((a b) (c d))
|;; I want to preserve this comment after `C-u M-s'.
(foo bar baz))
- `paredit-splice-sexp' now splices strings, by removing backslash
escapes, or signals an error if doing so would destroy the structure
of the buffer.
- I have finally introduced the first bit of code to try to deal
sensibly with broken buffers. It will probably go only downhill from
here, and continue in an interminable series of kludges to handle
every possible way in which the buffer can go *wrong* (it's bad
enough how many ways it can be *right*). If you try type a closing
delimiter from within a partial S-expression that has an opening
delimiter but no closing delimiter, then it will honk at you and
insert the closing delimiter -- or if what you typed doesn't match
the opening delimiter, it will just honk and refuse to do anything.
Also, `DEL' and `C-d' will delete spurious (but not [yet] mismatched)
opening and closing delimiters, respectively. (Thanks to John
Wiegley for inspiring me to do these dreary deeds.)
*** New Commands
- New command `paredit-yank-pop' cooperates with `paredit-wrap-sexp' by
behaving either like `yank' or like `yank-pop' if the previous
command was `paredit-wrap-sexp' or `paredit-yank-pop', and with the
added bonus of reindenting the newly wrapped form. It is in need of
a key to be bound to it; since it is different from both `yank' and
`yank-pop', I decided not to override `C-y' or `M-y', and I
considered `C-c C-y', but I imagine that many major modes want to
take that.
- New command `paredit-focus-on-defun' moves display to the top of the
definition at the point.
- New command `paredit-reindent-defun', which `M-q' is bound to in
Paredit Mode, indents the definition the point is on, or, if the
point is in a string or comment, fills the paragraph instead.
(Thanks to John Wiegley for the idea.)
- New variations on slurpage, barfage, and joinage. I'm still looking
for keys to bind to these commands. Find them with the strings
`add-to-{previous,next}-list' and `join-with-{previous,next}-list' in
their names. (Again, thanks to John Wiegley for the idea.)
- New command `paredit-convolute-sexp' performs the combined function
of `paredit-splice-sexp-killing-backward', `paredit-wrap-sexp', and
`yank'. Example:
(let ((foo bar))
(let ((baz quux))
|(zot mumble)
(frotz))
(gargle mumph))
->
(let ((baz quux))
(let ((foo bar))
(zot mumble)
(frotz)
(gargle mumph)))
This would otherwise have been done with the key sequence `C-u M-s
C-M-u M-( C-y C-M-u C-M-q'. `C-u M-s' could be `M-up', and `C-y
C-M-u C-M-q' could be `C-c C-y' if that key is chosen for
`paredit-yank-pop', making the sequence `M-up C-M-u M-( C-c C-y'. If
there is a good key for `paredit-convolute-sexp', it could be a nice
improvement over even that terser sequence. (Once again, this was
inspired by John Wiegley's idea (and name).)
[Observe, though, that the form (FROTZ) stuck with (ZOT MUMBLE) the
whole time, and was not carried along as the `end' of the (LET ((BAZ
QUUX)) ...) form. Hence this is *not* the idea mentioned below by
the name `paredit-interchange-sexps', but a simpler approximation of
the idea.]
- `define-paredit-pair' now defines commands `paredit-wrap-...' for
wrapping S-expressions with different delimiters, like
`paredit-wrap-sexp'. The function `paredit-wrap-sexp' now accepts
optional arguments for the delimiters to insert; the new commands are
defined in terms of the modified `paredit-wrap-sexp'. `M-[' is now
bound to `paredit-wrap-square'.
darcs-hash:20080928134400-00fcc-618d1b2da41f6a67aaef69d72d89ce15379372cc
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions