kovisoft/paredit

Official mirror of Paredit versions released on vim.org

paredit's Issues

Motions [[, ]], ( and ) are not populating the jumplist

Motions [[, ]], ( and ) are not populating the jumplist.

In a non-paredit mode, these 4 motion commands populate the jumplist and allow the user to press CTRL-O and go back to the previous position.
This is a default behavior of vim.

Deleting unbalanced parentheses

Hi, first of all, thank you very much for paredit.

Although paredit tries to prevent unbalanced parentheses being written, it is still possible that we end up having unbalanced ones in a number of scenarios. (e.g. opening a file written without paredit, using :move command, etc.)

For example, given the following code,

(a (b)
   (c))

:move 2 on the first line will yield

   (c))
(a (b)

And in this case, paredit does not allow me to delete the extra parentheses on the first line, so I have to do some tricks like <CTRL-V>x to bypass paredit. I think it would be better if paredit allows such deletion. What do you think?

Attempting to slurp a string on the last line barfs instead

To reproduce:

1. Open a Scheme file (myprogram.scm), and insert the following on the last line:

   (define s) "hello"

2. Position the cursor on the closing parenthesis, and try to slurp the string (<Leader>>).
3. Observation: paredit barfs the identifier instead.

   (define) s "hello"

This behavior only seems to occur when the string is the very last item on the last line of the buffer.

Strange behavior in Janet files

I noticed some strange behavior in Janet files.

Example 1:

(defmacro $<
  [& args]
  (def specs (collect-proc-specs args))
  (tuple $<* ;specs)
  # ~(upscope
  #   (pp ,specs)
  #   (tuple ,$<* ,;specs))
  )

When I select the comment lines (linewise visual mode) and delete them with d, I end up with this:

(defmacro $<
  [& args]
  (def specs (collect-proc-specs args))
  (tuple $<* ;specs)
  ((
  )

These two opening parentheses are unexpected.

Example 2a:

(defn- escape [str]
  (->> str
    (string/replace-all " " "\\ ")
    (string/replace-all `"` `\"`)
    ))

When I put the cursor in line 4 of this snippet and delete/cut the line with dd, I end up with:

(defn- escape [str]
  (->> str
    (string/replace-all " " "\\ ")
    ("
    ))

The (" is not expected.

Example 2b:

When I put the cursor again in line 4 in example 2a and try to copy the line with yyp (instead of deleting it), I end up with:

(defn- escape [str]
  (->> str
    (string/replace-all " " "\\ ")
    (string/replace-all `"` `\"`)
     string/replace-all ` ` `\"`)
    ))

The opening parenthesis in the new line 5 is missing.

Error in SetKeyword when ft=racket

1. vi test.rkt
2. i(<ESC>
3. ,W

Expected result: (())
Actual result:

Error detected while processing function PareditWrap[1]..<SNR>23_SetKeyword:
line    3:
E474: Invalid argument: iskeyword+=+,-,*,/,%,<,=,>,:,$,?,!,@-@,94,~,#,|,&
Press ENTER or type command to continue

This seems to be caused by repeated values, the racket plugin seems to set iskeyword=@,48-57,_,192-255,#,%,^.

Commenting out an s-exp breaks paredit

(abc
  #;(def (ghi
    (jkl)))
  (mno (pqr)))

Consider this code in a scheme file. 2Gdj results in

(abc
  ))
  (mno (pqr)))

while I would expect

(abc
  (mno (pqr)))

paredit: Custom keybinding for wrap in parens + add space after `(` + insert mode

Almost every time I use paredit_leader + W, I press a afterwards, enter a function name plus a space.

This is why it would like to create a keybinding (p.e. paredit_leader + s) for paredit_leader + W + a + space + left.

I guess I need something like this but it does not work:

call RepeatableNNoRemap(g:paredit_leader . 's', ':<C-U>call PareditWrap("(",")")a<space><left>')

Can you tell me how to do this correctly?

`x` on Chinese character only removes the first byte

Related to #13.

Example code:

;; 華文。
(display "一二三。")

In normal mode, positioning the cursor above the 文 character and pressing x results in this:

;; 華<96><87>。
(display "一二三。")

Same thing happens when deleting the full stop or the Chinese characters in the string.

Surprisingly, deleting the Chinese character here works perfectly:

(印 "Dire bonjour à la dame.")  ; After pressing `x`: ( "Dire bonjour à la dame.")

I asked about this on the vim StackExchange site (link). One of the comments there says:

... Actually using norm! x instead of lines 1123-1130 should fix it.

Support for JSON filetypes?

I was wondering if you would be open to having support for JSON?

I don't mind taking a shot at it and opening up a PR, but I wanted to see if there was any feedback you might have about supporting JSON filetypes for paredit.

Slurping a multibyte character on the last column destroys the character

If a multibyte character is on the last column of a line, slurping it would destroy it.

Steps to reproduce:

1. Open a Scheme file, and insert this:

   (f) λ

2. Position the cursor on the closing parenthesis, and slurp the lambda (<Leader>>).

3. Result:

   

Electric return removes all indentation

When I type (foo<CR>(bar)), I get

(foo
(bar))

instead of

(foo
  (bar))

It seems that this is because vim removes the trailing indent once the second <CR> of the electric return is issued. I have found this workaround:

diff --git a/plugin/paredit.vim b/plugin/paredit.vim
index 06fb9c8..76efd46 100644
--- a/plugin/paredit.vim
+++ b/plugin/paredit.vim
@@ -1032,7 +1032,7 @@ function! PareditEnter()
         let pos = col( '.' ) - 1
         if g:paredit_electric_return && pos > 0 && line[pos] =~ b:any_closing_char && !s:InsideString() && s:IsBalanced()
             " Electric Return
-            return "\<CR>\<CR>\<Up>"
+            return "\<CR> \<Backspace>\<CR>\<Up>"
         else
             " Regular Return
             return "\<CR>"

However it is imperfect, as pressing enter twice will leave trailing whitespace on the 'empty' line.

Incorrect splicing in a Common Lisp #'(lambda (...) ...)

1. #'(lambda (x) (+ x 1))
   

   If I position the cursor on the opening bracket of (+ x 1) and press <Leader>S (splice):

   • Observed result: nothing happens
   • Expected result: #'(lambda (x) + x 1)

2. (f #'(lambda (x) (+ x 1)))
   

   If I position the cursor on the opening bracket of (+ x 1) and press <Leader>S (splice):

   • Observed result: f #'(lambda (x) (+ x 1))
   • Expected result: (f #'(lambda (x) + x 1))

3. (g (f #'(lambda (x) (+ x 1))))
   

   If I position the cursor on the opening bracket of (+ x 1) and press <Leader>S (splice):

   • Observed result: (g f #'(lambda (x) (+ x 1)))
   • Expected result: (g (f #'(lambda (x) + x 1)))

Burf bypassing strings

It looks like that the burf (for both directions) feature is not working when there are strings as elements of a expression:

Expected:

(aaa bbb ccc|)    --->    (aaa  bbb|)  ccc
(aaa "bbb" ccc|)    --->    (aaa  "bbb"|)  ccc

Current behavior:

(aaa bbb ccc|)    --->    (aaa  bbb|)  ccc
(aaa "bbb" ccc|)    --->    (aaa|) "bbb" ccc

... while it is slurping correctly on the given examples.

Parentheses balancing breaks after ~100 lines in large s-expression

Hi, I've run into some problems working on some "eggs" (a module) for chicken scheme, where paredit's parentheses balancing stops working at some point. It seems that after around 100 lines, opening a parentheses does not balance it. This seems to be because a module is one large s-expression. Here's an example:

(module
  foo

  (import chicken scheme)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (foo bar)
    bar)

  (define (works)
    (print "works"))

  ;; New s-expressions will not have balanced parens
  ;; because the new one will match against the last one
)

Let me know if you need any more details.

Paredit interferes with pasting when disabled

Steps to reproduce:

1. vim test.scm
2. :call PareditToggle() to disable paredit
3. i(abc<ESC>
4. yyp

Expected result:

(abc
(abc

Actual result:

(abc
 abc

Splice does not work for forms not encased with parens

Hi there, I've noticed that paredit doesn't splice in my EDN (Clojure) files when there isn't a pair of parens somewhere around the form I'm trying to splice. This might affect other commands but I've just noticed splicing. The workaround is to wrap with parens before splicing. The parens don't have to be directly around the form: even a paren wrapping 10 levels up will enable splicing. I tried to take a look at the code but I can't tease out where the issue may lie or if this is maybe a fundamental incompatibility with Paredit's system.

Minimal Reproduction:
example.edn:

{:test ["test"]}

• try to splice the ["test"] vector away

Parens are very uncommon in EDN so I usually just wrap the top form in parens whenever I want to edit it as a workaround.

Paredit: 97d51d0 April 5 2021
Neovim: v0.7.0

`x` on a multibyte utf-8 char destroys the underlying char by removing only the first byte

when you enter

(def ∞ :inf)

then move the cursor over the ∞ symbol and press x once. only the first byte of that symbol gets deleted and broken symbols remain

(def <88><9e> :inf)

(note that the <##> are copied verbatim and are actually single chars, vim detects problems with)

removing the paredit bundle allows proper deleting of the ∞. this char was picked for testing, but it's not special to this one (e.g. german umlauts show the same behaviour)

Link to Cheat Sheet Gone

The reference to the cheat sheet is gone and really not necessary as the docs are more than suffficient:

paredit/doc/paredit.txt

Line 371 in d99905a

Davide Taviani made a cheetsheet for Paredit, which can be accessed here:

Vimdiff 'dp' and 'do' keybindings broken

Paredit interferes with the dp and do keybindings in Vimdiff. Contrary to expectations, nothing observable happens when dp and do are used in Vimdiff when Paredit is enabled.

<Leader>W and <Leader>w( not working

I'm trying to wrap my forms with curly braces using W and w(, but currently this is not working. My leader is set to . and pressing \ and w seems to be simply moving the cursor forward by a token. How to fix this?

Idea to relax the "balanced" rule

This is not a bug report, but, rather, a suggestion.

There are lots of other useful features in Paredit that I rely on (automatically closing of opened parentheses, moving of parentheses with automatic indentation, joining and splitting s-expressions, etc.). I like to think of those features/commands as non-intrusive, meaning, they don't interfere with the normal editing.

However, from what I experienced, there seem to be a lot of "unexpected" behaviors when doing normal editing (x, X, D, ce, Backspace, etc.). Just to point out, I'm not referring to bugs here, but of the main feature of Paredit: keeping the parentheses balanced at all cost.
My suggestion, is to add a flag, let's call it g:paredit_strictmode, which controls whether or not Paredit is activated when doing normal editing.
So, with the following combination:

let g:paredit_mode = 1
let g:paredit_strictmode = 0

I can do the usual stuff like:

• insert a opening parenthesis, and Paredit automatically adds the closing one;
• jump to start of defun with [[;
• move parenthesis with Leader>;

but, I can also do:

• delete closing parenthesis with Backspace, D, etc.;
• move opening parenthesis manually;

Please let me know what you think, or if this is in the scope of the project.

Return key inserts line above current line after autocompletion using down arrow key

How to reproduce:

1. Create a new lisp file: vim test.lisp
2. Insert (print) in the first line.
3. Go to the second line and insert (pr.
4. Now (still in insert mode) start completion with Ctrl-x Ctrl-n (or just Ctrl-n).
5. Select print using the down key.
6. Press enter.

Then you get:

(print)

(print)

An empty line was inserted above the second (print) form (and you are still in insert mode with the cursor in the second line).

This does not happen when I select the completion (print) using Ctrl-n or when I ignore the completion and press enter right away.

Same problem with commit 3609c63 (=before my last pull request), master and my branch backtick-strings.

At first I thought it was a problem with Janet files. But then I removed janet.vim, conjure, equalprg=janet-format, vim-mucomplete. All this made no difference. But now I know that this happens with .lisp files as well.

Any idea why this happens?

paredit conflicts with leader when leader set to space

When you set your leader to space, paredit gets confused and key mappings don't work correctly.

I have this line of code at the top of my vimrc to set my leader to space:

:let mapleader = " "

This is a problem for paredit, because when I add the plugin it has trouble mapping its keys. I first thought it was a problem with the g:paredit_shortmaps because it remapped my O key.

As it turns out, setting mapleader to space results in the following line of code inserting a space into the string, which doesn't work:

call RepeatableNNoRemap(g:paredit_leader . 'O', ':<C-U>call PareditSplit()') 

https://github.com/kovisoft/paredit/blob/0.9.11/plugin/paredit.vim#L185

To work around this issue I set the g:paredit_leader variable explicitly to <leader> so it doesn't try its own leader logic:

let g:paredit_leader = '<leader>'

This causes paredit to skip its own leader logic, because the variable is already set.
https://github.com/kovisoft/paredit/blob/0.9.11/plugin/paredit.vim#L48-L55

This works, but it required me to read through a bunch of code to figure out what was going on. I think this could be made easier, maybe by detecting that mapleader is set to " " or using <leader> instead of the string in mapleader in the key binding.

Raising a string literal.

Hi @kovisoft,

It would be nice if you can add support for raising a string literal. e.g. raising at |

(f (g "..|...."))

should become

(f "......")

Command for switching off paredit?

Is there a way to switch paredit on and off when editing a file? e.g. Something similar to :PareditOn, :PareditOff, :PareditToggle.

Why does PareditInsertClosing return "\<C-Y>"?

Referring to these lines in PareditInsertClosing:

paredit/plugin/paredit.vim

Lines 935 to 937 in 76c1fb8

	if pumvisible()
	let retval = "\<C-Y>"
	endif

What is the purpose of these lines?

These lines cause a bug. Steps to reproduce:

1. Open a Common Lisp file (e.g. myprog.lisp).
2. Type (deb.
3. Omnicomplete: CtrlxCtrlo (observe that the first completion candidate is debug). Do not select any completion candidates.
4. Continue typing: ug).

Observation: when the user types the closing parenthesis (e.g. in step 4 above), the closing parenthesis disappears! This is clearly a mistake.

Inserting extraneous closing bracket

Looks like the previous commit (a7f3dff) introduced a bug.

If I type in

(defn a [b])

I end up with

(defn a [b]])

and paredit does not allow me to delete the extraneous closing bracket.

Somehow this code breaks paredit

I'm trying to learn some Scheme for myself. And i've wrote some trashy (partially intentionally) code. And this code breaks paredit: it works fine when writing before this code, and works incorrectly when writing after after. The code itself seems correct. Guile and Chicken Scheme execute it as expected.

Snippet: https://gist.github.com/mbakhterev/8cb09f4d427c9ead7f5e279626ebebc3

Auto-indent issue/question

Apologies if this is not the right place to be asking this, but I'm seeing a bit of odd behavior in my Clojure files regarding auto-indenting. I have tabstop=2, shiftwidth=2, and softtabstop=2 in my .vimrc file. When editing the following Clojure function, I can't seem to get indentation to work correctly for multiple-arity definitions.

(defn respond
  ([exchange body]
  ¦(respond identity exchange body))  ; <--- This should be one more space
  ([around exchange body]
  ¦(.sendResponseHeaders exchange OK 0)  ; <--- This should be one more space
  ¦(with-open [resp (around (.getResponseBody exchange))]
  ¦ ¦(.write resp (.getBytes body)))))

I've included the | characters to more easily show spacing. Notice how after the ([exchange body]\n, auto-indent is only placing a single space on the next line before the opening parenthesis, when it should actually be placing 2 spaces. Interestingly, this only seems to happen beneath the multi-arity definitions; everywhere else in my source is working correctly.

Any thoughts?

Fails to pair parentheses on larger files

Apologies if this is the wrong place to post this. First of all, I love paredit. I'm really glad somebody took the time to provide it for Vim, so I don't have to bounce between Emacs and Vim as I work on Lisp/everything else.

I've noticed an issue I keep running into, however. It seems like once a file gets to a certain number of parentheses, or maybe just a certain length, paredit incorrectly matches parentheses and causes an inbalance of parens. I have to disable paredit at this point to get around the issue. I'm not really sure where to begin looking to give you more information, but it seems to happen almost exclusively in my Clojure test files, which have quite a lot of nesting going on and can get fairly long (maybe 200 lines, nothing insane).

Is this a known issue and is there a known workaround? Vim correctly highlights the matching parens once I type them in, but paredit will decide it doesn't need to insert a closing paren, instead moving my cursor to an outer, existing closing paren if I try to type it.

An example where I'm seeing this right now is in this file: https://github.com/d11wtq/cuckoo/blob/master/test/cuckoo/cron/parse_test.clj

If you put your cursor the line above the last (testing " ... ") section, then try to enter a new (testing " ... ") you get as far as (, but don't see the closing paren inserted. When you type it, your cursor moves to the very end of the file. Vim highlights the final closing paren as matching the one earlier inserted, but this now leaves the overall file unbalanced.

Using the latest version from github.com/vim-scripts/paredit.vim under Vim 7.3 on OS X 10.9.1.

EDIT | Apologies for the comment noise. Ok, I couldn't test paredit without any other clojure plugins installed, but verified the issue exists with just paredit and vim-clojure-static installed, and with just paredit and fireplace installed, so paredit does seem to be the common element here 😄

paredit breaks "." repeat command

Hi all!

I'm not sure if this is a problem on my side, but this happens when I add paredit to my config:

When I'm in the middle of a word and I change the end "ceTEXT":
wo|rd -> woTEXT
I expect . to do the same on other words:
oth|er -> othTEXT
Instead I get:
ohTEXTher

How come? Am I missing something?