summaryrefslogtreecommitdiff
path: root/COPYING
diff options
context:
space:
mode:
authorTaylor R Campbell <campbell@mumble.net>2008-09-28 13:44:00 +0000
committerTaylor R Campbell <campbell@mumble.net>2008-09-28 13:44:00 +0000
commit342fee5dfeeff59f94875639b3daa9383ba856a0 (patch)
tree21f2d592a40f6d38ab00d02fff6241c8807dd9c2 /COPYING
parent94645884ce0ee1e797dbf54f3fedcd72ed9ce7a7 (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 'COPYING')
0 files changed, 0 insertions, 0 deletions