1. 40
  1. 22

    What I didn’t like about Vim was that a good number of plugins always felt like a hack…. Another popular plugin is Syntastic. I absolutely hate the way it displays the errors. It is not a smooth transition from “no error” to “error”. Not much to say here, it just looks awful, yet it is highly recommended.

    Dedicated Vim user for about 8 years here. I feel this pain. My setup feels hacky.

    Yet I’m not willing to lose the power of modal editing + command line integration (see my post, “Making Vim, Unix and Ruby sing harmony”, and I doubt any emulation will satisfy me.

    Kakoune is the first editor I’ve seen that looks like it might be my future tool of choice; the author is like “I see why modal editing and Unix integration are great and I intend to do them better than Vim.” If the usability is also better, I’m sold. I’m just waiting to find the time and an easy enough onramp to start learning it.

    1. 10

      I tried Kakoune for a week around New Year’s. And it was surprising how deep I got into it. In the end, though, I found myself deeply incompatible with it.

      • In spite of being modal, Kakoune’s shortcuts started to feel like Emacs. Default chords like alt-C would require pressing three keys at once.

      • Kakoune’s scripting language started to feel just as hacky as Vim, albeit in different ways. More minimal, but a lot more nested-string escaping. If I was willing to put up with chords, why not just use Emacs and get a real language to script my editor with?

      • Critical keyboard shortcuts had no equivalent. { and } for navigating by paragraph. , was impossible to make work as I expected. X for deleting a character backwards. You can’t just hit w to skip ahead one word and then hit i to start typing. You have to hit w, then ; to reset the selection before you can start inserting. Just felt weird.

      • Kakoune has no window management. Instead you’re supposed to just use tmux. That felt nice and orthogonal in theory. In the spirit of Unix. But in practice it turned out to be not so nice. For example, I could open multiple windows in tmux panes, but Kakoune would always be in the directory I first started it in, rather than the directory I opened the current window at. There was no sequence of autocommands and scripting that would allow windows to have their own directories like Vim has. I think the same idea may apply to Rob Pike’s criticism of the proliferation of commandline flags in Unix: it’s easy to criticize Unix on principle, but when you get into the details it is perhaps not so bad.

      Perhaps I was just too programmed by Vim. I don’t know. Interesting, mind-broadening experience for sure. The lesson I was left with was something fundamental about software: we still don’t know how to unbundle the timeless essence of a piece of software (in the case of Kakoune, the object-verb grammar and multiple cursors) from the slow accretion of more arbitrary design choices like how you navigate by paragraph or the implementation of f and ;. Back in the git history of Kakoune is a sweet spot with a more compatible and elegant text editor. It may have missed some features, but it didn’t have conflicting features to a human being on Earth used to Vim.

      1. 9

        Vis is another option that I’ve been eyeing, along side Edit.

        1. 1

          micro is more nano like but it’s still a pretty good editor.

        2. 8

          I second the Kakoune recommendation. It lacks plugins but is very promising. I missed CtrlP for example when I tried it.

          1. 8

            Have you tried spacemacs out? it’s really a much better at customizing the editor than vim but still has a very well done version of vim emulation. I consider myself to be a power user of vim and spacemacs is very compelling if you don’t want the hacky feel. magit is a phenomenal package(shows just what a decent programming language inside the editor gets you) and changes the way I look at version control.

            1. 3

              I had this exact same experience. Initially I went to emacs (and I still love bits of emacs - org-mode is outstanding) but for day to day editing I’ve transitioned to Visual Studio Code.

              It’s very featureful and its extension language is Javascript, which I’m finding much easier to wrap my head around.

              1. 2

                I love kakoune too, I think it’s heading in a very interesting direction. The always-on “visual mode” is great, and the use of standard UNIX tools to extend the editor makes a lot of sense. I implemented a simple “netrw”-style extension with little effort and calls to ls.

                One thing that bothers me though is the lack of a simple C key to replace until the end of the line, as in Vim. I use this very often, and maybe I just missed something, but it’s just not that quick and easy in kakoune, it would require a custom mapping or something, I believe.

              2. 19

                I found that neovim is much, much faster than vim, with a comparable setup. I would highly recommend trying it. I have been using neovim for over a year now, it’s very good. A lot of high quality plugins are being written with support for only neovim now.

                Additionally, I would highly recommend fzf.vim over CtrlP and others. I have tried all of the major fuzzy finding plugins for vim, and fzf.vim is by far the fastest and works how I would expect.

                I stopped using CtrlP because in a large project (several hundred thousand files), searching for a small string “icp” would not find “app/models/icp.rb”, but would instead find longer and more irrelevant results. fzf.vim works as I expect in this case.

                You also never need to invalidate the cache, it rebuilds every time you search. It’s fast enough that you can use it to search all files on your computer. You can do locate / | fzf and it’s ready to go in a second or so (you can still search while it’s indexing). In normal projects it’s pretty much instant.

                tl;dr: use neovim and fzf.vim. All hail junegunn.

                Edit: Oh, and if you want to use ctrl-p to activate it, add this to your vimrc.

                noremap <c-p> :FZF<CR>
                1. 3

                  Seconded, fzf is great. I didn’t yet know about the vim specific wrapper for it though, so thank you for that! This is part of why I love fzf, it’s not specific to vim and so I use it all the time, even when not inside vim.

                  1. 3

                    FWIW, OP was a neovim user.

                    1. 2

                      junegunn has made me love vim again. He’s tpope’s successor :-)

                    2. 14

                      I’ve used some form of vi and/or sam as my primary editor for decades. There’s one simple reason: it’s everywhere. I SSH to a lot of different machines every day, sometimes those machines are ancient, and sometimes I’m using shared accounts. I can’t trust that they’ll have vim, much less some highly-customized version of it.

                      So I need an editor that’s everywhere and/or has good remote editing support. sam does, and I use it when it’s available, but it often isn’t. Sublime Text has support for remote editing, so does VS Code, etc, etc. But it breaks my workflow to have to upload the remote part of the editor when I’m just trying to edit something quickly. I’m comfortable enough with vi that that time would be better spent simply editing the file.

                      Even on my local box, I tend to have vanilla tools, because if I get too comfortable with some customized version of something, the cognitive burden of switching to something else on a different machine becomes great enough to become annoying. It’s the same reason why I don’t use an IDE: I’ve been using the UNIX shell for decades, and I always end up back on the shell to do stuff…so UNIX is my IDE. :)

                      1. 7

                        I’m glad to hear somebody else with the same philosophy!

                        I like stock tools because no matter where I am, they’ll be the same level of discomfort. If I start really customizing my vim/sublime/etc. I know that when I end up on an unfamiliar system I will be even less productive than normal because I’ll have become reliant on those extensions.

                        For the remote editing, though–have you considered mounting the stuff via sshfs or similar?

                        1. 1

                          For the remote editing, though–have you considered mounting the stuff via sshfs or similar?

                          I have, but it still breaks my workflow. If I’ve SSH’d in to a box, and I’m doing work there and I cd into some directory, I can just type “vi foo” and edit the file. To do the SSHfs thing, I’d have to change over to my editor, navigate to the file via whatever means, and then edit it. It’s a lot of extra work.

                          sam, via the B command, lets me open a file in my local editor from the remote machine, and I know that Sublime has something similar, but the necessary remote commands aren’t always installed.

                          (If there’s a better way, I absolutely want to know.)

                          1. 1

                            If you can assume all your hosts have tmux installed (which is true for me these days, but probably not true everywhere), and you use OSX, you can probably make something like that happen with iTerm’s tmux integration, which speaks with the remote tmux instance and gets various bits of useful information from it. For example in the default setup, you can right-click on a filename in remote ls output and download it over scp. This is probably (but I haven’t tried to do it) possible to script so that instead of downloading the file, you instead pass the remote filename to something like emacsclient /ssh:user@host:/fully/qualified/foo, which will then open it in your local emacs.

                            Essentially my reasoning is something like this, where step 3 is the sketchy one outlined above:

                            1. There are already text editors that can natively edit remote files over ssh without needing anything installed on the remote machine. Emacs can do this, for example, by asking it to open a file with a filename that looks like /ssh:user@host:/path/to/file.

                            2. Now it’s a UI problem, effectively: you want to, from your remote terminal window, do something like type localedit foo that executes a no-op on a remote machine but somehow causes emacsclient /ssh:user@host:/fully/qualified/foo (or similar) to execute on the local machine. Instead of, as you say, having to manually navigate to the remote file in your local editor. But you also don’t want to install this localedit command on the remote server as a special remote helper of your editor.

                            3. So what’s needed is for the local terminal emulator to intercept / respond to this command, not the remote server to handle it. And your terminal emulator needs to grab the fully qualified filename when doing so. There are various ugly screen-scrapey ways I can think of doing this, but the iTerm/tmux integration seems like the most likely to be reliable.

                        2. 3

                          Vim comes closest to an editor I could use entirely without configuration. My .vimrc is 10 lines long, and I understand that with neovim I could get rid of some of those lines. I’m an Emacs weenie, but I like to keep my vim-muscles for when I have to use a new machine or a machine I do not own.

                        3. 9

                          I understand many of the arguments written by Eduardo. I even agree with some of them. I am an Emacs and Vim user and I have faced a few of the issues stated by the author.

                          However I don’t agree with the idea behind this sentence:

                          However, open source, with its potential to bring hundreds (if not thousands) of developers together to help create amazing software, has given us: editors that run slower than what we had available in the 90s.

                          There are many open source editors that are fast. Anyways, I could agree with the idea that there is not an open source editor without a big learning curve as good as Sublime. However my biggest issue with that sentence is that it somehow express the idea that open source is a waste of time. It express something that was pretty common to hear when I started working for big companies more than 10 years ago: open source is done by junior developers that don’t have the ability to production ready code. OpenBSD, Linux and most compilers are the evidence that the idea behind that sentence is not real.

                          Going back to the editor discussion, I am pretty sure xi editor will be another counter example to that sentence. In the editor’s area we will have to wait a few years to see if I am right.

                          1. 12

                            editors that run slower than what we had available in the 90s

                            I agree that this is inexcusable. Text editors, of all things, should work faster than we can think in 2017.

                            1. 5

                              in this hn thread jonathan blow speculates on whether text editors would be better off with a keep-it-simple-stupid approach, trusting the cpu to make simple code and data structures fast rather than striving for clever datastructures and algorithmic efficiency.

                              1. 2

                                Even better, Mark gives a specific scheme that worked for him:


                            2. 6

                              No, I did not say open source is a waste time. I said that just because something is open source, does not make it good software.

                              Edit: Also, I am excited to see what becomes of xi editor. Hopefully it can learn from all the editors currently available and bring the best parts from all of them.

                              1. 4

                                I think Sublime is a good example of that and that is why I think that for the moment you have a point. However I think that sentence is worrisome. From my point of view it gives the idea that there is something inherently bad with open source.

                                1. 3

                                  There’s something inherently bad with software in general if it’s written by inexperience people, those that don’t care about UX, or those that don’t care much about resource efficiency. That’s a lot of FOSS in the editor or IDE space. If looking more broadly, you’ll find the problem all over the place esp if .NET, Java, or PHP apps. The complex or half-ass platforms that also bring in the masses. ;)

                            3. [Comment removed by author]

                              1. 4

                                This feeling of hackiness is definitely there. It is there in almost any software that purports to be infinitely customizable, especially if the original author decided it would be best if core features (such as UI) were outsourced to plugins.

                                The allure of infinite customization is a bit of a honeypot for tweak-happy users. I used to be a big fan of this approach, but later I realized that the flexibility of customization effectively helps users rationalize the wasted time they spend doing systems integration with plugins: “such and such is no longer maintained, I need to swap it to something else.” I don’t really care for such things anymore and it gets tiring keeping up with what the best plugin is for some ridiculously tiny niche feature.

                                The “everything is a component” approach still has value, however. I just prefer to use it for in-house development. It imparts high amounts of modularity and low (sometimes too low) coupling across a project. You can make semi-crappy components and have full freedom to refine/redo them when they start to show weaknesses.

                                1. 4

                                  I’m in complete agreement. The fixation with keeping your hands cramped on the home row needs to end. It’s 2017 and there is more to programming than typing. More than half my coding time is spent reading and exploring code. More than half of the remaining time spent thinking about the problem. Of that remaining typing time only a fraction is entering new code, the rest is refactoring and extending existing code.

                                  For most of those tasks a mouse is simply faster. I don’t want to think about counting the number of words or letters I want to highlight or subselecting underscores with a regex. I just want to point and drag the text, with multiple cursors if need be. If I want to jump to the definition of a function I take 50ms to move my pointer there and ctrl+click. I don’t want to be forced to navigate line by line, word by word to get to the function name before jumping to its definition. The great thing is that with sublime/code/atom/gedit/geany/scite I get the best of both worlds and can use the right control for the situation.

                                  1. 3

                                    Relative line numbers genereally removes most of the hassle for me, using my mouse is generally a cognitive shift that makes it harder for me to stay concentrated

                                    1. 5

                                      I really like relative line numbers, but the actual line number on the line with the cursor. set rnu and set nu together does this in vim.

                                      1. 2

                                        using my mouse is generally a cognitive shift that makes it harder for me to stay concentrated

                                        I’ve never been able to understand this sentiment. I’m currently a user of probably the most mouse-heavy editor ever invented but even when I was an emacs/vim user, I never understood the complaint here.

                                        I’m wondering if it’s just a difference in development approach: the majority of my time isn’t spent writing code, but thinking about it - I tend to get most fussy about having a large, clean whiteboard with ultra fine tip markers.

                                        When I do need to edit a large section of code, I find that the combination of structural regexes and sweeping a selection with the mouse is about as close to perfection as you can get. Much nicer than mucking about with line offsets or setting marks.

                                        Not saying anything is wrong with it - I just find it very interesting that I can’t even relate to such a commonly held opinion. I’ll have to look around to see if there’s been any research done on this.

                                        1. 2

                                          My problem is that it feels jarring, but then maybe acme, not being a weird hybrid like most programs and jnstead being actually pointed towars efficient use of the mouse, does not feel like that, I’ll have to try it out

                                      2. 1

                                        I generally move by screens or “paragraphs” (ctrl u/d, {}) when doing that kind of stuff, and use visual mode liberally. Refactoring and stuff like that is when vim feels noticably awesome. Typing in new code you could be using word.

                                        1. 1

                                          I agree, see my other comment in this thread for a super rough demo of what i imagine might be a cool extension to these somewhat basic editors.

                                        2. 3

                                          but I know it enough that any editor that forces me to use the mouse would make me less productive

                                          imho this is because of the brain-dead default mouse usage patterns copied over decades. acmes mouse usage is amazing, but anything different from left-select right-context menu is better.

                                          1. 3

                                            Something is broken when it comes to the monetization of these editors. The end result is a lot of half baked editors. Want great keyboard editing: Vim,Emacs. Want nice Java refactoring: eclipse. How about a fast editor that just works: sublime. Nice plugins for Go: Atom. Python code browsing: Pyclipse.

                                            I’d like 1 editor which is perfect for all these use cases.

                                            1. 2

                                              I’m terrible with emacs and vim - actually I used gedit for a while. Then I switched to sublime text. I made the switch to openbsd and unfortunately can’t use it there.

                                              For fun I was playing with copying some of acme/c9x.me edit concepts and put together a tiny proof of concept demo. - https://www.youtube.com/watch?v=5XfxzigjhUw

                                              Let me know what you think of the idea. I know the implementation is rough, but this is close to all I wanted from an editor. sublime like, with more platforms and easy access to shell commands.

                                              1. 1

                                                Who needs more than 256 colors for syntax highlighting?

                                                1. 3

                                                  Who needs […] syntax highlighting?


                                                  1. 3

                                                    vim -u NONE

                                                    The fastest editor you will ever use.

                                                  2. 3

                                                    Neovim does truecolor fine. I don’t see why you’d want to limit yourself. My colorscheme uses like 4 colors but they’re exactly the ones I want.

                                                  3. 1

                                                    I use both vi and gedit. I don’t think gedit is slow (as suggested by the author…), at least not on my Fedora desktop, but then again, I only use few features and one or two plugins.

                                                    1. 1

                                                      One example is CtrlP. ….. but I was never able to get it even close to the performance and quality of the results of Sublime Text.

                                                      This. This. This.

                                                      I used to be a vim user. I never really learned it well enough to have a very tailored vimrc (I have a vimrc, but one I wouldn’t shed many tears over if lost. The settings I care about I can replicate.). At some point I started using sublime, and I would switch between editors, depending on my mood and the task at hand.

                                                      Now I’m working on larger projects and rarely use vim. Ctrl-P and fzf.vim are just too slow, and it’s a tool I use a lot.

                                                      I still miss vim keybindings (yes, I know there are plugins, but see comment below).

                                                      I may try spacemacs or neovim at some point. I’ve heard good things.

                                                      These days I don’t have the time to put effort into what I perceive to be marginal improvements to my editing experience, so I’ve not really put more effort into fixing things. When I was a student I spent way too much time on this and realized it doesn’t matter as much as you think it does. I’m quite fast with sublime and won’t be too much faster with the hypothetical vim-bindings-plus-sublime-and-does-everything-i-want-it-to editor.

                                                      1. 1

                                                        I have used vim since forever and I still have major issues with it.

                                                        For work I have markdown files that are a few thousand lines long and each has about 18 level two (##) markdown headers. I enable folding to collapse those files into 18 workable sections, and vim is noticeably slow when folding is enabled.

                                                        I recently introduced someone to vim for the first time and the amount of configuration needed to get a somewhat sane default is annoying. We can debate the value of syntax highlighting but when a new user has to hunt down and install 3rd party syntax, filetype and folding configuration for very common file types as the very first thing, I think that’s insane.

                                                        I tried neovim on the same markdown files and it was only a little bit faster.

                                                        At least things like native packages and async is slowly coming around but it’s taken much too long.

                                                        1. 1

                                                          Wherever you go, there you are.

                                                          If you managed to make Vim slow with your choice of plugins and configuration, it’s only a matter of time until you do it again with your new editor.

                                                          1. 1

                                                            I always had issues with it. From having to refresh every time I made a new file, to folders such as node_modules being included in the results unless I refreshed again (although this could be an issue with The Silver Searcher).

                                                            Switching from ag to ripgrep was one of the best decisions I made in 2016 as far as tooling is concerned. Not only it’s faster (tbh, the speed difference is negligible in most cases), but it also correctly parses .gitignore patterns.

                                                            I have tried for a long time to get it to work as well as it works on Sublime Text, but I was never able to get it even close to the performance and quality of the results of Sublime Text.

                                                            On my MBP 13” Mid 2014, with JazzCore/ctrlp-cmatcher and ripgrep, indexing the whole Linux repo takes less than a second and searching for a specific file isn’t significantly slower than searching for a file in a much smaller repo. That’s with caching turned off, because ripgrep is so fast in my daily use that I don’t need caching.

                                                            But still, I don’t know if it’s specifically ag’s fault, maybe we just use vastly different hardware.

                                                            1. 1

                                                              I think it’s only a matter of time until I switch to evil mode. Gonna figure out how to get doc view to match zathurra keybindings.

                                                              And then I can have my entire work setup working cross platform…

                                                              Maybe I do want emacs to be my OS :P

                                                              1. 1

                                                                One example is CtrlP. It is currently the most recommended way of opening files in Vim. The default setup can be improved by using The Silver Searcher to find the files and using ctrl-py-matcher to match files with your search query. I always had issues with it.

                                                                I see ripgrep + fzf recommended much more often nowadays

                                                                From having to refresh every time I made a new file, to folders such as node_modules being included in the results unless I refreshed again (although this could be an issue with The Silver Searcher).

                                                                Did you set this in your agignore?

                                                                One of the settings that really slowed my Vim down, was the relativenumber setting. If you are not familiar with this setting, what it does is instead of displaying the actual line numbers in the file, it displays the how many lines away a line is relative to your current line. If that sounds confusing, just type :set relativenumber and you will see what I mean. Apparently this can make your Vim really slow when moving up and down.

                                                                TIL! Looks like :lazyredraw may help with this? In any case, definitely not the first culprit I would point to for slow down, so thanks.

                                                                1. 1

                                                                  I see ripgrep + fzf recommended much more often nowadays

                                                                  I was not aware of fzf. I will try it out someday.

                                                                  Did you set this in your agignore?

                                                                  No, but it was in my gitignore, which ag supposedly used as well. That folder would appear randomly every time I refreshed.

                                                                  TIL! Looks like :lazyredraw may help with this? In any case, definitely not the first culprit I would point to for slow down, so thanks.

                                                                  lazyredraw helps a bit but not when you are required to scroll.