7 ms·

It is a chicken and egg problem though. The quality of the ecosystem can be improved with a really strong editor underneath. However bringing the ecosystem to t

It is a chicken and egg problem though. The quality of the ecosystem can be improved with a really strong editor underneath. However bringing the ecosystem to the editor is incredibly hard. I think vim is a messy pile of hacks, and I would love to see that changed. Neovim is nice with the extend and evolve approach but I'm always looking for something that can really provide a clean base for extensions to build on. (Yes ,yes, I know emacs is an editor-writing IDE) On the other hand I see nothing about plugins here. I think the approach to extensions is a very important question to answer early on.

pradn 5y ago
How about Emacs in eVIl mode?
- Koshkin 5y ago
  The worst of both worlds?
  - drums8787 5y ago
    Nah, it's the best. A recent thread on this convinced me to try Doom Emacs. It's great and just doubled my nerd factor.
  - 1_player 5y ago
    Evil mode is better than VIM itself and a good editor for the Emacs operating system which previously lacked one.
    - alpaca128 5y ago
      Many people constantly recommending Evil mode don't seem to get why some use Vim. No, Evil mode is not better than Vim itself. For one it's slower, defining keybindings is much more verbose, everything outside the actual text file has completely different controls, and I lose most of the seamless interoperability with other terminal tools. And it runs within an environment that tries to be literally every text-related tool by itself, making it overly complicated in many aspects.
      - 1_player 5y ago
        > everything outside the actual text file has completely different controls Not sure what you mean by this > lose most of the seamless interoperability with other terminal tools It's not like VIM is more or less interoperable than Emacs is with other shell tools. They live in their own space, you don't (often) pipe stuff in or out of it. Though there's not much to read into my comment, it was an attempt of being witty, but evil mode is the best VIM implementation found in any editor and just for the fact that Elisp >> Vimscript, makes evil mode a better environment than VIM itself.
        apocolyps6 5y ago
        > They live in their own space, you don't (often) pipe stuff in or out of it. Well that's not true at least for vim. : read !FOO will run the FOO command and read the results back into the current buffer. I usually search my codebase by reading the results of a grep into a temporary buffer and 'gf'ing to the appropriate file
        rhabarba 5y ago
        There isn’t much Vim can do which ed cannot, though.
        gnubison 5y ago
        Except for some extra trivialities, like everything that isn't an ex command (and some that are).
        c2the3rd 5y ago
        C-u M-! does the exact same thing in Emacs.
        flukus 5y ago
        But that goes back to the original point they made, everything outside of the actual text editing and you're in EMACS land with all of it's controls. Even with something as complete as spacemacs, the default landing page when you open it has different key bindings.
  - prussian 5y ago
    not sure about worse. enabling evil-ex-visual-char-range allows you to do things ex commands in (neo)vim cannot do. That is, run things like !rev on a visual select. in (neo)vim this reverses the whole line where with (evil-ex-visual-char-range t) enabled in evil does what I'd argue is expected, only reversing the string selected in visual mode.
    - gnubison 5y ago
      OTOH, Neovim lets you edit the ex command line; e.g. '!}' might expand to ':.,.+5!', which lets you execute any other ex command simply by deleting the '!'. They both have advantages, and I'm certainly not advocating that forcing ex commands to work on lines is the best idea.
  - samus 5y ago
    That would be... an editor with Emacs keybindings, extendable with Vimscript?
atweiden 5y ago
If you like VSCode, you might be interested in Onivim — it’s a VSCode/Vim hybrid.
- linsomniac 5y ago
  Not sure about OniVim1, but just last week I bought the OniVim2 Early Access license, after watching oni 1/2 for a few years. I will say that it seems a bit early, but it does look promising. For example: My main workstation loses syntax highlighting after I do two motion commands ("jj" or "Gk" for example).
  - zbaylin 5y ago
    Hey, Onivim contributor here. Thanks for the feedback! I will mention that syntax highlighting fixes are something we’re gonna be focusing on in the coming weeks/months so if you haven’t already, feel free to file an issue on GitHub (or comment on one that looks similar)!
    - kristiandupont 5y ago
      Onivim looks great! Does it/will it support remote development like VSCode? I do all my development on a virtual machine. I love everything about VSCode except for the vim plugin.
      - WiiManic 5y ago
        (Another dev here!) Its a workflow we are looking into supporting, but its difficult. VSCode has extensions that are licenesed in a different way to the rest, which includes all the remote development ones (WSL/SSH/Docker). Their license can be found on the marketplace, but broadly they can "only be used with Visual Studio Family products" (or something of similar wording, i.e. Code only, some are VS only). They are also fully closed source as well, the GH repos are just for issues. So we'd like to support that sort of workflow, but it will mean more work on our end since we can't use that existing work due to the license.

pradn 5y ago

How about Emacs in eVIl mode?

Koshkin 5y ago
The worst of both worlds?
- drums8787 5y ago
  Nah, it's the best. A recent thread on this convinced me to try Doom Emacs. It's great and just doubled my nerd factor.
- 1_player 5y ago
  Evil mode is better than VIM itself and a good editor for the Emacs operating system which previously lacked one.
  - alpaca128 5y ago
    Many people constantly recommending Evil mode don't seem to get why some use Vim. No, Evil mode is not better than Vim itself. For one it's slower, defining keybindings is much more verbose, everything outside the actual text file has completely different controls, and I lose most of the seamless interoperability with other terminal tools. And it runs within an environment that tries to be literally every text-related tool by itself, making it overly complicated in many aspects.
    - 1_player 5y ago
      > everything outside the actual text file has completely different controls Not sure what you mean by this > lose most of the seamless interoperability with other terminal tools It's not like VIM is more or less interoperable than Emacs is with other shell tools. They live in their own space, you don't (often) pipe stuff in or out of it. Though there's not much to read into my comment, it was an attempt of being witty, but evil mode is the best VIM implementation found in any editor and just for the fact that Elisp >> Vimscript, makes evil mode a better environment than VIM itself.
      - apocolyps6 5y ago
        > They live in their own space, you don't (often) pipe stuff in or out of it. Well that's not true at least for vim. : read !FOO will run the FOO command and read the results back into the current buffer. I usually search my codebase by reading the results of a grep into a temporary buffer and 'gf'ing to the appropriate file
        rhabarba 5y ago
        There isn’t much Vim can do which ed cannot, though.
        gnubison 5y ago
        Except for some extra trivialities, like everything that isn't an ex command (and some that are).
        c2the3rd 5y ago
        C-u M-! does the exact same thing in Emacs.
        flukus 5y ago
        But that goes back to the original point they made, everything outside of the actual text editing and you're in EMACS land with all of it's controls. Even with something as complete as spacemacs, the default landing page when you open it has different key bindings.
- prussian 5y ago
  not sure about worse. enabling evil-ex-visual-char-range allows you to do things ex commands in (neo)vim cannot do. That is, run things like !rev on a visual select. in (neo)vim this reverses the whole line where with (evil-ex-visual-char-range t) enabled in evil does what I'd argue is expected, only reversing the string selected in visual mode.
  - gnubison 5y ago
    OTOH, Neovim lets you edit the ex command line; e.g. '!}' might expand to ':.,.+5!', which lets you execute any other ex command simply by deleting the '!'. They both have advantages, and I'm certainly not advocating that forcing ex commands to work on lines is the best idea.
- samus 5y ago
  That would be... an editor with Emacs keybindings, extendable with Vimscript?

atweiden 5y ago

If you like VSCode, you might be interested in Onivim — it’s a VSCode/Vim hybrid.

linsomniac 5y ago
Not sure about OniVim1, but just last week I bought the OniVim2 Early Access license, after watching oni 1/2 for a few years. I will say that it seems a bit early, but it does look promising. For example: My main workstation loses syntax highlighting after I do two motion commands ("jj" or "Gk" for example).
- zbaylin 5y ago
  Hey, Onivim contributor here. Thanks for the feedback! I will mention that syntax highlighting fixes are something we’re gonna be focusing on in the coming weeks/months so if you haven’t already, feel free to file an issue on GitHub (or comment on one that looks similar)!
  - kristiandupont 5y ago
    Onivim looks great! Does it/will it support remote development like VSCode? I do all my development on a virtual machine. I love everything about VSCode except for the vim plugin.
    - WiiManic 5y ago
      (Another dev here!) Its a workflow we are looking into supporting, but its difficult. VSCode has extensions that are licenesed in a different way to the rest, which includes all the remote development ones (WSL/SSH/Docker). Their license can be found on the marketplace, but broadly they can "only be used with Visual Studio Family products" (or something of similar wording, i.e. Code only, some are VS only). They are also fully closed source as well, the GH repos are just for issues. So we'd like to support that sort of workflow, but it will mean more work on our end since we can't use that existing work due to the license.