3 ms·

Paredit.vim – Paredit Mode: Structured Editing of Lisp S-Expressions

38 points by susam 4y ago

dan-robertson 4y ago
Interestingly, there is a popular vim-style sexp editing mode for Emacs: https://github.com/abo-abo/lispy https://github.com/abo-abo/lispy
- LanternLight83 4y ago
  Noctuid, of `general.el` fame, has a related package which integrates lispy's approach with `evil.el` better. https://github.com/noctuid/lispyville https://github.com/noctuid/lispyville
neilv 4y ago
The Emacs paredit.el that they cite is by Taylor Campbell. https://www.emacswiki.org/emacs/ParEdit https://www.emacswiki.org/emacs/ParEdit http://mumble.net/~campbell/emacs/paredit.el http://mumble.net/~campbell/emacs/paredit.el
- agumonkey 4y ago
  I wish I could tip him
deleted 4y ago
[deleted]
cormacrelf 4y ago
The major alternative to this is Parinfer (https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/). It works very well, especially for Vim where paredit-style bindings aren't that natural IMO. Parinfer has less to remember. There are some very solid implementations like https://github.com/eraserhd/parinfer-rust https://github.com/eraserhd/parinfer-rust and its Vim plugin.
- memling 4y ago
  I have been learning Racket on and off for the last few years as part of an interest in DSLs. (The documentation is well written, but I confess a certain kind of impatience with it because it is hard for me to get task-specific information when I'm trying to solve a particular problem.) I recently had to remove parinfer because its inferences in multi-line syntax-parse statements were not great: I had to join a bunch of lines together to put in the parentheses I needed and lost placement. Parinfer's unwillingness to let me balance parentheses manually is a frustration. Am I misusing it?
Sharlin 4y ago
I wish source code editors were much more AST-oriented rather than row-column-oriented. Sure, it’s more difficult when your grammar is more complex than s-expressions, but most editors these days maintain an AST of the source in real time anyway. Features such as selection that grows "inside out" (or bottom-up) rather than line by line, moving a selection around to the next/previous valid position, moving various delimiters around to next/previous valid position, enclosing whatever’s under the cursor in a new block/pair of parens, and so on. Unless we’re talking about FORTRAN or COBOL circa 1960, source code is a tree natively and text only incidentally.
- davidkunz 4y ago
  Have a look at Neovim with its Tree-Sitter parser, it enables such 'growing selections' natively. It's also relatively easy to write plugins based on the parsed AST. I wrote treesitter-unit[1] making it easy to select/modify the subtree of the selection. [1]: https://github.com/David-Kunz/treesitter-unit https://github.com/David-Kunz/treesitter-unit
- ckolkey 4y ago
  I think you'll find treesitter quite interesting: https://github.com/nvim-treesitter/nvim-treesitter#incremental-selection https://github.com/nvim-treesitter/nvim-treesitter#increment...

38 points by susam 4y ago

Interestingly, there is a popular vim-style sexp editing mode for Emacs: https://github.com/abo-abo/lispy https://github.com/abo-abo/lispy

LanternLight83 4y ago
Noctuid, of `general.el` fame, has a related package which integrates lispy's approach with `evil.el` better. https://github.com/noctuid/lispyville https://github.com/noctuid/lispyville

neilv 4y ago

The Emacs paredit.el that they cite is by Taylor Campbell. https://www.emacswiki.org/emacs/ParEdit https://www.emacswiki.org/emacs/ParEdit http://mumble.net/~campbell/emacs/paredit.el http://mumble.net/~campbell/emacs/paredit.el

agumonkey 4y ago
I wish I could tip him

deleted 4y ago

[deleted]

cormacrelf 4y ago

The major alternative to this is Parinfer (https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/). It works very well, especially for Vim where paredit-style bindings aren't that natural IMO. Parinfer has less to remember. There are some very solid implementations like https://github.com/eraserhd/parinfer-rust https://github.com/eraserhd/parinfer-rust and its Vim plugin.

memling 4y ago
I have been learning Racket on and off for the last few years as part of an interest in DSLs. (The documentation is well written, but I confess a certain kind of impatience with it because it is hard for me to get task-specific information when I'm trying to solve a particular problem.) I recently had to remove parinfer because its inferences in multi-line syntax-parse statements were not great: I had to join a bunch of lines together to put in the parentheses I needed and lost placement. Parinfer's unwillingness to let me balance parentheses manually is a frustration. Am I misusing it?

Sharlin 4y ago

I wish source code editors were much more AST-oriented rather than row-column-oriented. Sure, it’s more difficult when your grammar is more complex than s-expressions, but most editors these days maintain an AST of the source in real time anyway. Features such as selection that grows "inside out" (or bottom-up) rather than line by line, moving a selection around to the next/previous valid position, moving various delimiters around to next/previous valid position, enclosing whatever’s under the cursor in a new block/pair of parens, and so on. Unless we’re talking about FORTRAN or COBOL circa 1960, source code is a tree natively and text only incidentally.

davidkunz 4y ago
Have a look at Neovim with its Tree-Sitter parser, it enables such 'growing selections' natively. It's also relatively easy to write plugins based on the parsed AST. I wrote treesitter-unit[1] making it easy to select/modify the subtree of the selection. [1]: https://github.com/David-Kunz/treesitter-unit https://github.com/David-Kunz/treesitter-unit
ckolkey 4y ago
I think you'll find treesitter quite interesting: https://github.com/nvim-treesitter/nvim-treesitter#incremental-selection https://github.com/nvim-treesitter/nvim-treesitter#increment...