Got a little excited and accidentally deleted a comma.
New Clojure-like language atop VimL. Only differences for vim-sexp is the lack of the #= EvalReader and the addition of the #* reader macro. https://github.com/tpope/timl
Suggested by glts. Closes #3
This breaks from the behavior of the builtin bracket text objects, which do not fallback to the current word, but is strictly more useful. Lisp forms are defined in terms of their ability to be evaluated, so falling back to an atomic form when a compound one does not exist is unsurprising. Suggested by Tim Pope. Closes #2
And then match characters with stridx(). Assumes no macro chars will be multibyte.
setpos() does not set curswant, which leads to unexpected behaviour when moving up and down after ( and ) movements. s:setcursor() simply calls cursor(), which does what we always intended.
Where selection is expanded when on closing bracket
* development: Add <Plug>(sexp_indent) and <Plug>(sexp_indent_top) Documentation fixes Reword comment Check for blank string from visualmode() Optimize backward top-level movement Rename sexp_lift_* to sexp_raise_*
== shadows the mostly useless internal motion.
I thought it was a bug, but let's hedge our bets since I didn't bother sending a patch upstream.
Using setpos() to set visual marks does not change the member that visualmode() returns, so raise (and likely others) did not work properly when called before ever entering visual mode.
Removes an unnecessary call to s:nearest_bracket(1) when travelling backward --todo
This was the original name for mapping/function, but I changed it when I was led to believe that paredit's sexp raise did not do the same. After installing paredit.el and trying it out for myself, it appears to be essentially the same as sexp_lift_element, so we are changing it back!
e.g. [|a] With cursor at |, d<M-w> would fail.
All changes done with a count leave the current form unbalanced, and it's not clear what non-changing operations would benefit from having a count that is not handled by sexp_outer_list.
This branch changes the behaviour of element-wise movement: moving element-wise never climbs to a parent compound form. This allows the element-wise movement motions to be used more freely without fear of accidentally climbing out of the current lexical scope. * bounded-elementwise-movement: Re-implement sexp#move_to_adjacent_element [bounded-movement] Fix selection swapping Change s:nearest_element_terminal() to gate movement
Count handling is moved to the function itself, as well as the decision to make the selection inclusive.
Happily, the "fix" is actually just what I should have written in the first place, regardless of the change to s:nearest_element_terminal
Element-wise movement in normal mode now no longer climbs levels to the parent list. This behaviour makes use of the element-wise motions feel dangerous since it is not easy to dive back into a child list. Unfortunately, this behaviour underlies many functions, so we will have to fix them one by one.
Japanese Vim plugin authors wrap their <Plug> mappings like so: <Plug>(my_custom_mapping) I believe this originated with Kana Natsuno with vim-textobj-user. This style has the advantage of being visually unambiguous when used in mappings. I resisted doing this when I first started on this plugin because I wanted to ensure that <Plug> map names like sexp_outer_list could be looked up by a user using the K command. However, I now realize that the K command happily does substring searches, so adding ()s around the plug name does not affect the ability to look for help docs.
Instead of deleting v:count surrounding brackets, delete the brackets v:count ancestors up.
Better just to keep all the <LocalLeader> maps together This reverts commit e972790.
Bug is still present; I had forgotten how to trigger it
The normal command m` pushes v:count to v:prevcount
We are now targeting full 7.3 compat
Looks like this was a temporary bug in the version of Vim I was running at the time.