5 ms·

I'm not sure I understand what your comment has to do with Sublime...but in any case, Sublime does have a very active plugin ecosystem: https://packagecontrol.i

I'm not sure I understand what your comment has to do with Sublime...but in any case, Sublime does have a very active plugin ecosystem: https://packagecontrol.io/ https://packagecontrol.io/

eswat 11y ago
From OP… > Sublime seems to be falling into that sunsetting stage the same as jEdit
bigtunacan 11y ago
I thought my points were fairly clear. 1) Vim and Emacs are already on your production servers so a large number of people have to use them anyway so that's extra mental overhead. 2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins. 3) Stick with a tool that you can have a level of faith will still be well supported for the next 20 years.
- oldmanjay 11y ago
  Not all of us are stuck in the cult of the editing paradigm of the 70s despite the fervent mistaken belief that it is objectively superior.
  - pachydermic 11y ago
    How is sublime fundamentally different? Sure, it might be shinier and easier to get into, but is it a different "paradigm"? No way. If anything, vim is the most unique editor with the most unique "paradigm" I've ever really had much experience with. Atom, Sublime and Emacs all seem pretty much the same in terms of how you interact with them. Pretty sure saint ignucius will damn you to proprietary software hell for dissing on the One True Editor (tm).
    - wodenokoto 11y ago
      If vim is different from sublime, then sublime must, by definition, be different from vim. Parent is saying that vim is a 70's paradigm and people not stuck in the past enjoy the modern paradigm that sublime follows.
      - pachydermic 11y ago
        Emacs is also from the 70s, so that's why what he said doesn't really make sense.
- ashwinaj 11y ago
  > 1) Vim and Emacs are already on your production servers so a large number of people have to use them anyway so that's extra mental overhead. Production servers usually have no vim plugins. Basic vim editing is good enough to get by if you're just looking at logs. In my workplace and I guess it's pretty standard these days (in Linux shops at least) where the code repository resides on a server in a data center and not locally on your laptop/desktop. Here are the issues with this development work flow: - There are a lot of hurdles to go through to install all the vim plugins (no root access, security of plugins etc.) - Which plugin manager to use (Vundle, pathogen or some variant??). Why isn't there a standard for this after all these years? - Unreadable .vimrc file with all sorts of key bindings (Yes I know it's "write once use everywhere", it still is unreadable a few months down the line) - In my experience, using vim on a mounted drive with the plugins I need (git,ctrl-p,ctags,cscope,nerd tree and a few others) is slower as compared to Sublime Text. > 2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins. https://packagecontrol.io/stats https://packagecontrol.io/stats I don't think these are low numbers by any means. I'm not a vim basher, I just don't prefer working with it.

I'm not sure I understand what your comment has to do with Sublime...but in any case, Sublime does have a very active plugin ecosystem: https://packagecontrol.io/ https://packagecontrol.io/

eswat 11y ago

From OP… > Sublime seems to be falling into that sunsetting stage the same as jEdit

bigtunacan 11y ago

I thought my points were fairly clear. 1) Vim and Emacs are already on your production servers so a large number of people have to use them anyway so that's extra mental overhead. 2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins. 3) Stick with a tool that you can have a level of faith will still be well supported for the next 20 years.

oldmanjay 11y ago
Not all of us are stuck in the cult of the editing paradigm of the 70s despite the fervent mistaken belief that it is objectively superior.
- pachydermic 11y ago
  How is sublime fundamentally different? Sure, it might be shinier and easier to get into, but is it a different "paradigm"? No way. If anything, vim is the most unique editor with the most unique "paradigm" I've ever really had much experience with. Atom, Sublime and Emacs all seem pretty much the same in terms of how you interact with them. Pretty sure saint ignucius will damn you to proprietary software hell for dissing on the One True Editor (tm).
  - wodenokoto 11y ago
    If vim is different from sublime, then sublime must, by definition, be different from vim. Parent is saying that vim is a 70's paradigm and people not stuck in the past enjoy the modern paradigm that sublime follows.
    - pachydermic 11y ago
      Emacs is also from the 70s, so that's why what he said doesn't really make sense.
ashwinaj 11y ago
> 1) Vim and Emacs are already on your production servers so a large number of people have to use them anyway so that's extra mental overhead. Production servers usually have no vim plugins. Basic vim editing is good enough to get by if you're just looking at logs. In my workplace and I guess it's pretty standard these days (in Linux shops at least) where the code repository resides on a server in a data center and not locally on your laptop/desktop. Here are the issues with this development work flow: - There are a lot of hurdles to go through to install all the vim plugins (no root access, security of plugins etc.) - Which plugin manager to use (Vundle, pathogen or some variant??). Why isn't there a standard for this after all these years? - Unreadable .vimrc file with all sorts of key bindings (Yes I know it's "write once use everywhere", it still is unreadable a few months down the line) - In my experience, using vim on a mounted drive with the plugins I need (git,ctrl-p,ctags,cscope,nerd tree and a few others) is slower as compared to Sublime Text. > 2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins. https://packagecontrol.io/stats https://packagecontrol.io/stats I don't think these are low numbers by any means. I'm not a vim basher, I just don't prefer working with it.