kovisoft / paredit Goto Github PK
View Code? Open in Web Editor NEWOfficial mirror of Paredit versions released on vim.org
Official mirror of Paredit versions released on vim.org
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.
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?
To reproduce:
myprogram.scm
), and insert the following on the last line:
(define s) "hello"
<Leader>>
).(define) s "hello"
This behavior only seems to occur when the string is the very last item on the last line of the buffer.
I noticed some strange behavior in Janet files.
(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.
(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.
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.
vi test.rkt
i(<ESC>
,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,#,%,^
.
(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)))
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?
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.
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.
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.
#'(lambda (x) (+ x 1))
If I position the cursor on the opening bracket of (+ x 1)
and press <Leader>S
(splice):
#'(lambda (x) + x 1)
(f #'(lambda (x) (+ x 1)))
If I position the cursor on the opening bracket of (+ x 1)
and press <Leader>S
(splice):
f #'(lambda (x) (+ x 1))
(f #'(lambda (x) + x 1))
(g (f #'(lambda (x) (+ x 1))))
If I position the cursor on the opening bracket of (+ x 1)
and press <Leader>S
(splice):
(g f #'(lambda (x) (+ x 1)))
(g (f #'(lambda (x) + x 1)))
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.
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.
Steps to reproduce:
vim test.scm
:call PareditToggle()
to disable parediti(abc<ESC>
yyp
Expected result:
(abc
(abc
Actual result:
(abc
abc
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"]}
["test"]
vector awayParens 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
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)
The reference to the cheat sheet is gone and really not necessary as the docs are more than suffficient:
Line 371 in d99905a
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.
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?
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:
defun
with [[
;Leader>
;but, I can also do:
Backspace
, D
, etc.;Please let me know what you think, or if this is in the scope of the project.
How to reproduce:
vim test.lisp
(print)
in the first line.(pr
.Ctrl-x Ctrl-n
(or just Ctrl-n
).print
using the down
key.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?
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.
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 "......")
Is there a way to switch paredit on and off when editing a file? e.g. Something similar to :PareditOn
, :PareditOff
, :PareditToggle
.
Referring to these lines in PareditInsertClosing
:
Lines 935 to 937 in 76c1fb8
What is the purpose of these lines?
These lines cause a bug. Steps to reproduce:
myprog.lisp
).(deb
.debug
). Do not select any completion candidates.ug)
.Observation: when the user types the closing parenthesis (e.g. in step 4 above), the closing parenthesis disappears! This is clearly a mistake.
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.
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
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?
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 😄
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.