4 ms·

> The vim vs emacs flame war I doubt that there is any ongoing vim vs. emacs flamewar. Most people are probably arguing about VSCode vs. JetBrains these days.

> The vim vs emacs flame war I doubt that there is any ongoing vim vs. emacs flamewar. Most people are probably arguing about VSCode vs. JetBrains these days. My impression as an Emacs user is that if someone says they use Vim, I think "hey, one of us". (nano I guess falls into that category, but I bet nano users are missing out on some timesaving innovations from the last few years, and nothing frustrates me more than people that have inefficient workflows because they eschew learning new things.) > Emacs Lisp is not really a particularly fun language to use simply for customizing the behavior of an editor — as they say, Emacs is a nice operating system, it just needs a good editor. I doubt one would like an OS where the SDK only supports a language they don't like. I know this was an attempt to reuse a quote, but I think they actually like the editor and dislike the OS, which is the opposite of what sentiment that quote conveys. (Here's another tired meme: "eighty megs and constantly swapping".) Emacs Lisp is actually very interesting in its staying power. It was designed from the ground up to write programs that the programmer is in front of all day, and that's very different than the enterprise / systems programming use cases that modern languages optimize for (where tens of thousands of copies of your program need to run unattended). The API and tooling matter more than the actual programming language, and I've looked around at other editor platforms and they're just not there yet. You can't C-M-x to run the line of code you're currently editing. You have to write HTML and CSS to supply preferences to your plugin. It's so weird to me how actively extension-hostile the popular editors are these days, and how hard they make manipulating the contents of the editor.

garciasn 5y ago
I wish vim had the option for CTRL-K/U behavior rather than having to do the unintuitive (to me) visual block.
- maddyboo 5y ago
  I think you're referring to multiple cursors? Visual-Multi [0] is an amazing Vim plugin for this with advanced features like searching by regex, alignment by regex, transposition, duplication, auto-numbering, and more. You can ignore the advanced features at first, it's very intuitive: just `C-n` to find the next occurrence of the word or `\\a` to find all, and then whatever editing operation you want like `cfoobar<esc>`. Or to just get another cursor on the line below, `C-<down>`. [0]: https://github.com/mg979/vim-visual-multi https://github.com/mg979/vim-visual-multi
  - georgyo 5y ago
    This is not multiple cursors. Ctrl+k is cut line, similar to yy Ctrl+u is paste, similar to p The difference is hitting Ctrl+k five times will put all those lines into a buffer. And Ctrl+u will paste those five lines. In vim, this is complicated. You could do 'y5' requiring to know/calculate the number of lines in advance. But more often then not you are going into visual mode, selecting everything, then y, then p. This is complicated series of distinct commands. It's a matter of preference, but I personally prefer Ctrl+k/u of nano over the vi/vim method.
    - maddyboo 5y ago
      Forgive me for misunderstanding the ambiguous comment, both C-k and C-u are associated with multiple cursors in VSCode [0] ;) I use the following mappings for emacs-ish editing in insert mode: " emacs-style editing & motion inoremap <C-a> <Home> inoremap <C-e> <End> inoremap <C-b> <Left> inoremap <C-f> <Right> inoremap <C-n> <Down> inoremap <M-b> <S-Left> inoremap <M-f> <S-Right> inoremap <M-d> <C-o>de inoremap <C-k> <C-o>D inoremap <C-p> <Up> inoremap <C-d> <Delete> " restore support for digraphs to M-k inoremap <M-k> <C-k> `C-k` doesn't append to a "kill ring", but you could probably accomplish that with something like inoremap <C-k> <C-o>"Kdd inoremap <silent> <C-u> <C-o>"Kp<C-o>:let @k=""<cr> Or if you want it in normal mode rather than insert mode: nnoremap <C-k> "Kdd nnoremap <silent> <C-u> "Kp:let @k=""<cr> Edit: This is the closest behavior I could get to how nano seems to do it: let @k="" let @l="" nnoremap <silent> <C-k> "ldd:let @k=@k.@l \| let @l=@k<cr> nnoremap <silent> <C-u> :if @l != "" \| let @k=@l \| end<cr>"KgP:let @l=@k<cr>:let @k=""<cr> The bigger point I'd like to make is that it's a bit silly to complain about vim's default behavior not being as you'd like it. This is the beauty of vim (and emacs): it's a solid foundation upon which to build your ideal workflow. Few people find vim's defaults to be entirely satisfactory, but with a bit of creativity, you can make just about anything happen (and luckily, thanks to many thousands of plugin developers, you can probably find it ready-made). [0]: https://stackoverflow.com/a/29953572/947478 https://stackoverflow.com/a/29953572/947478
      - garciasn 5y ago
- deleted 5y ago
  [deleted]
techrat 5y ago
https://i.imgur.com/LV6umMH.png https://i.imgur.com/LV6umMH.png
bitwize 5y ago
It's a bit twee to compare Emacs to a Lisp machine, as those machines could do lots of incredible things that are still difficult in Emacs. But dammit, Emacs brings many Lisp Machine advantages to your editor, including live-coding your editor's configuration. If there's a task you need done, or a change you need to make to how the editor works, you can code it up in Emacs Lisp right in the running editor (or even record a macro as a starting point), test it, debug it, and save it off if you like the results. Without leaving your editing session. The huge advantages this brings outweighs my complaints with Emacs Lisp the language (which are many).
hnfong 5y ago
Oooh, let me start one then! https://imgur.com/a/VjrUjBI https://imgur.com/a/VjrUjBI
- dangerbird2 5y ago
  Circa 2006, all the Emacs users realized it has perfectly good documentation built-in, so they didn't have to search for it anymore /s
gauchojs 5y ago
100%. If I understand correctly. to change a single line (say some behaviour that is wrong for your workflow) of a VSCode plugin you have to fork it on Github. In Emacs it would probably be a short snippet, tested in your scratch buffer and added to the end of your init.el: (add-hook 'vscode-todoist-xxx-hook ...) This is what I miss the most about Emacs - what I don't miss is the endless configuration/tweaking...

garciasn 5y ago

I wish vim had the option for CTRL-K/U behavior rather than having to do the unintuitive (to me) visual block.

maddyboo 5y ago
I think you're referring to multiple cursors? Visual-Multi [0] is an amazing Vim plugin for this with advanced features like searching by regex, alignment by regex, transposition, duplication, auto-numbering, and more. You can ignore the advanced features at first, it's very intuitive: just `C-n` to find the next occurrence of the word or `\\a` to find all, and then whatever editing operation you want like `cfoobar<esc>`. Or to just get another cursor on the line below, `C-<down>`. [0]: https://github.com/mg979/vim-visual-multi https://github.com/mg979/vim-visual-multi
- georgyo 5y ago
  This is not multiple cursors. Ctrl+k is cut line, similar to yy Ctrl+u is paste, similar to p The difference is hitting Ctrl+k five times will put all those lines into a buffer. And Ctrl+u will paste those five lines. In vim, this is complicated. You could do 'y5' requiring to know/calculate the number of lines in advance. But more often then not you are going into visual mode, selecting everything, then y, then p. This is complicated series of distinct commands. It's a matter of preference, but I personally prefer Ctrl+k/u of nano over the vi/vim method.
  - maddyboo 5y ago
    Forgive me for misunderstanding the ambiguous comment, both C-k and C-u are associated with multiple cursors in VSCode [0] ;) I use the following mappings for emacs-ish editing in insert mode: " emacs-style editing & motion inoremap <C-a> <Home> inoremap <C-e> <End> inoremap <C-b> <Left> inoremap <C-f> <Right> inoremap <C-n> <Down> inoremap <M-b> <S-Left> inoremap <M-f> <S-Right> inoremap <M-d> <C-o>de inoremap <C-k> <C-o>D inoremap <C-p> <Up> inoremap <C-d> <Delete> " restore support for digraphs to M-k inoremap <M-k> <C-k> `C-k` doesn't append to a "kill ring", but you could probably accomplish that with something like inoremap <C-k> <C-o>"Kdd inoremap <silent> <C-u> <C-o>"Kp<C-o>:let @k=""<cr> Or if you want it in normal mode rather than insert mode: nnoremap <C-k> "Kdd nnoremap <silent> <C-u> "Kp:let @k=""<cr> Edit: This is the closest behavior I could get to how nano seems to do it: let @k="" let @l="" nnoremap <silent> <C-k> "ldd:let @k=@k.@l \| let @l=@k<cr> nnoremap <silent> <C-u> :if @l != "" \| let @k=@l \| end<cr>"KgP:let @l=@k<cr>:let @k=""<cr> The bigger point I'd like to make is that it's a bit silly to complain about vim's default behavior not being as you'd like it. This is the beauty of vim (and emacs): it's a solid foundation upon which to build your ideal workflow. Few people find vim's defaults to be entirely satisfactory, but with a bit of creativity, you can make just about anything happen (and luckily, thanks to many thousands of plugin developers, you can probably find it ready-made). [0]: https://stackoverflow.com/a/29953572/947478 https://stackoverflow.com/a/29953572/947478
    - garciasn 5y ago
deleted 5y ago
[deleted]

techrat 5y ago

https://i.imgur.com/LV6umMH.png https://i.imgur.com/LV6umMH.png

bitwize 5y ago

It's a bit twee to compare Emacs to a Lisp machine, as those machines could do lots of incredible things that are still difficult in Emacs. But dammit, Emacs brings many Lisp Machine advantages to your editor, including live-coding your editor's configuration. If there's a task you need done, or a change you need to make to how the editor works, you can code it up in Emacs Lisp right in the running editor (or even record a macro as a starting point), test it, debug it, and save it off if you like the results. Without leaving your editing session. The huge advantages this brings outweighs my complaints with Emacs Lisp the language (which are many).

hnfong 5y ago

Oooh, let me start one then! https://imgur.com/a/VjrUjBI https://imgur.com/a/VjrUjBI

dangerbird2 5y ago
Circa 2006, all the Emacs users realized it has perfectly good documentation built-in, so they didn't have to search for it anymore /s

gauchojs 5y ago

100%. If I understand correctly. to change a single line (say some behaviour that is wrong for your workflow) of a VSCode plugin you have to fork it on Github. In Emacs it would probably be a short snippet, tested in your scratch buffer and added to the end of your init.el: (add-hook 'vscode-todoist-xxx-hook ...) This is what I miss the most about Emacs - what I don't miss is the endless configuration/tweaking...