guns / vim-sexp Goto Github PK

Are there any plans of implementing the feature? Or is it left out on purpose? The lack of it is keeps me from switching from vim-paredit.

I love vim-sexp, and am very excited about the possibility of using vim-sexp instead of paredit; having used it for several weeks, however, there are several useful paredit commands I really miss: e.g.,
paredit-forward-down
paredit-forward-up
paredit-backward-down
paredit-backward-up
paredit-split-sexp
paredit-join-sexps
paredit-splice-sexp-killing-backward
paredit-splice-sexp-killing-forward

If vim-sexp had these commands, I think it would be "no contest" between it and vim paredit (and possibly even emacs paredit)...

e.g.

<localleader>wdefn should be the repeat#set text instead of <localleaderw alone. This makes it easier to repeat that kind of change, and would align the behavior with a and i for example.

Maybe these things are just happening for me, because of some other plugin or settings, but...

In the following, |x| represents the cursor position, and <x> represents a visual selection.

Starting with (+ 10|0|0) and doing vae results in (+< 100>0).
Starting with (+ sym|b|ol) and doing vae results in (+< symbo>l).
Starting with something "a str|i|ng" and doing vae results in something< "a string>".

There are similar problems with ie motions. In summary, the element motion does not quite work for the last element in a list, or if the element is a string.

Breaks sexp#leaf_flow on occasion. May break other things.

see: vim/vim@d70840e

The ae and ie object selectors would be more useful if you could prepend a count. BTW, I'm really liking vim-sexp.

Makes sense, right? I want it in particular for a generic "eval top level form" operation, where the top level form might just be a symbol.

Vim-sexp is a breath of fresh air after paredit, thank you :)

Hey there! Love the plugin, it makes working in Clojure a breeze.

I've run into a small problem where if I use nvim-treesitter and leave additional_vim_regex_highlighting = false (meaning all syntax highlighting is provided by TS), then the " insert maps don't work correctly anymore, as s:syntax_match can't find any highlighting under the cursor.

Would it be feasible to add some awareness of TS and use that when appropriate?

I know than a solution is to set additional_vim_regex_highlighting = true, but it's not ideal because the two highlights clash and don't look great together.

I just want to make sure I am getting the most out of this very useful plugin. My question is, if I want to move an element from one form to another it seems like I am left to deal with whitespace manually, eg:

(a form [with an ele|ment])
(target form)

;; daf
(a form)
(target form|)

;; p
(a form)
(another form[an element])

meaning I have to add the space between "form" and "[an element]".

And also, if I had put the cursor on the bracket and used dae, the paste would work as expected, i.e. (another form [an element])

The plugin claims to be under the "MIT" license: https://github.com/guns/vim-sexp/blob/master/plugin/sexp.vim#L12

However it's impossible for anyone looking to build upon (pieces of) your work to comply with this license. Assuming you meant this license:

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Note that it says "The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software." This plugin itself violates this requirement, and
it's impossible to copy this license to derivative works because the notice wasn't in the original to
begin with.

The insert mode mappings by default don't allow me to match unbalanced parentheses (| denotes the cursor).
What I have: ([(|])
What I want: ([()|])
What I get: ([(]|)

Rather than recognizing that the internal paren is unmatched, and therefore allowing me to insert, it moves my cursor to the closing ). This comment in the source explains that it's a tradeoff made for performance reasons. Is there any way to get the desired functionality without taking the performance hit? I'm happy to do the work if you have a solution in mind.

@guns, when I consult the table of contents at :h local-additions vim-sexp isn't there. This is because vim-sexp does not respect the convention documented at :h write-local-help: The first line of a plugin doc is magic, and the proper format is

*myplugin.txt*<Tab>This is the tagline for my plugin

In practice, hardly anybody uses <Tab>. (I do: to make sure "the entries line up nicely".)

I have a creeping feeling that I'm turning into the GitHub resident respect-local-additions-magic-first-line-of-doc.txt zealot, but hey, we do what we do best, don't we? Feel free to disregard this end of the year (at least on my end) trifle.

Looking forward to using vim-sexp in the new year, nice work!

Thanks for the great plugin.

I'm trying hard to get it to work on a mac in iterm2 with vim version 7.4.488.
My .vimrc is pretty big so I'm eliminating any possible conflicts by using a plain vanila .vimrc
with nothing in it but your plugin.
None of the <M mappings work for me.

Am I missing some obvious thing specific to Mac. Anybody else has/had this issue?

I saw that there is a possibility to set your own mappings using the 'sexp-explicit-mappings' directive.
But I like the default mappings so want to stick to those..

Thanks

When capturing tail on a top level form, capture will place the bracket at the end of subsequent comments. Similar behavior can be seen with emit-tail. This seems surprising to me as it unbalances forms. Capture and emit should probably ignore comments altogether and act on the next real element.

Given the following with the cursor on foo.

(foo) ;comment-a
bar
;; comment-b
zap

Capture tail twice should produce

(foo ;comment-a
bar
;; comment-b
zap)

For example:

(f1 (f2 fC3 f4))

cursor position marked by C. After barfing once to the left, the cursor moves to the left paren:

(f1 f2 (Cf3 f4))

This is quite annoying compared to paredit in emacs. Is there an option to make the cursor stay where it was?

Thanks!

(map #(f % 5) (range 10))

With the cursor inside the anonymous function, daf deletes the form, except for #. You will get similar results with #"".

I hope I'm not missing something obvious but navigating into (and out of) subforms seems to be more difficult than one would hope it would be in a Lisp. For example imagine the following Clojure code:

(defn some-function
  "Some
   docstring."
  [x]
  (if (= x 42)
    "That's the answer!"
    (str x " is not the answer")))

If the cursor is at |(defn (perhaps by way of using [[ or ]] to navigate) and one wanted to navigate into the function to add a parameter, for example but imagine introducing another let assignment, adjusting a condition, etc., how would one achieve this? Currently I believe you have to move the cursor into the form you wish to subnavigate and use the sibling motion keys but then of course this navigates elements and not forms.

The plugin is loading, but then the text objects don't seem to work. If I understand correctly, I should be able to put my cursor inside of

(an sexp)

and type

daf

and it will delete it? Other bindings don't seem to really work either. Matched parentheses are inserted though during insert mode.

I have a very annoying problem with the closing parenthesis magic from vim-sexp. I have the following .clj file:

(defn foo []
  (println "Hello"))

I do the following after opening the file:

• Hit o to insert a line before the println
• type (bla
• Hit ESC to exit edit mode
• Do lx to delete the closing brace
• a to enter append mode

No matter what I do, i can't seem to close the opening brace anymore, it always jumps to the last line.

I use MacVim 7.4, no other plugins installed (except pathogen).

Clojure uses reader macros like @ and # before forms. I think it makes sense to include macro characters as a part of the COMPOUND FORM to make it more consistent with ELEMENT behavior
In the current implementation ( | denotes cursor, <> denotes vim command):

@(re-|frame/subscribe [::the-sub])
<daf>
|@
;; but
(@a|bc de fg)
<dae>
(|de fg)

After my suggestion:

@(re-|frame/subscribe [::the-sub])
<daf>
|
;; but
(@a|bc de fg)
<dae>
(|de fg)

Many of the default g:sexp_mappings do not make sense in visual mode (correct me if I'm wrong). To avoid visual-mode mappings, extra configuration steps are needed.

If I configure sexp mappings like this:

let g:sexp_mappings = { 'sexp_insert_at_list_head': '<I' }

vim-sexp creates nmap and xmap mappings, but sexp_insert_at_list_head is not really useful in visual-mode.

In order to avoid this, I must do this:

nmap <I     <Plug>(sexp_insert_at_list_head)
let g:sexp_mappings = { 'sexp_insert_at_list_head': '' }

Perhaps the plugin could be more discriminating about which maps it creates in visual-mode.

Hi, great plugin!

There are two features of slurping in emacs paredit mode that I really miss in vim-sexp. The cheat sheet here shows how it behaves and below is why it feels more natural for me to use than the vim equivalents.
http://emacswiki.org/emacs/PareditCheatsheet (See Barfage & Slurpage)

Take the example of introducing a let for the map result, after typing (something xs)

(let [xs])
(map to-x ys)
(something xs)

The first thing I miss, is that slurping an element does not move the cursor (or if at the end of a line it moves to the prev char). It makes it far easier to quickly drop out of insert, put forms in the right place and then back to insert without losing focus of where you were working. In the example, I can finish the vector and easily slurp in the map I was working on with ...[xs])<ESC><slurp><slurp>. With vim-sexp captures, it's painful to do this as I need to navigate to the previous form after each slurp.

The second thing is that slurping will recursively slurp up the tree if there's nothing to slurp in the current form. In the example, my cursor can be on the s (the last non-closing char I need to type) and I can just slurp three times to get the map into the binding and the final form into the body.

Would it be possible to change capture to behave in this way or introduce slurp and barf calls with this behavior?

I would have loved to do a PR but I've never written a vim plugin and I felt like I was way over my head when I dove into this.

I'm writing Julia using the Julia-vim plugin. When I also have Vim-Sexp loaded, any parenthesis or bracket (([{) inserted in a Julia (*.jl) file is autoindented by one space - a space is inserted before the parenthesis right after it's typed. Commenting Vim-Sexp out makes the issue go away.

I understand the description is light on details and the problem might as well be in the Julia-Vim plugin rather than Vim-Sexp. However, I think this issue might be helpful to anyone who runs into the same problem. Maybe someone will actually be able to figure it out!

This plugin looks cool but I am having difficulty figuring out how to use it. I see that a video is on your todo list. Any chance of getting that done?