181–190 of 210 posts
Earlier quoted context omitted.
All decent IDEs have a file search command.
Somehow my colleagues who use VS Code or JetBrains IDEs don't manage to learn about those features while all of my vim-using colleagues somehow do. (Haven't worked with anyone using Emacs yet)
Earlier quoted context omitted.
Somehow my colleagues who use VS Code or JetBrains IDEs don't manage to learn about those features while all of my vim-using colleagues somehow do. (Haven't worked with anyone using Emacs yet)
I use CLion almost exclusively and I use shift-shift to find things so often that I have basically no idea what file anything is in. Is there anything free that even begins to approach the quality and accuracy of the JetBrains Rust analysis plugin? If so, I’d love to know about it and start using vim.
I used to think that Emacs is some weird editor with absurd keybindings, until I learned lisp and understood what makes it so special. Now Emacs (Spacemacs[0]) is my main driver. [0] https://www.spacemacs.org
I think there are weird things about spacemacs. It’s probably somewhat good for someone who doesn’t know any emacs because a lot of the emacs defaults are bad. And for someone who wants vim bindings it’s good because it has a lot more than evil mode does. On the other hand I feel like a lot of the layers are developed by people who spend too much time tinkering with editor features trying to make the most complicated…
Spacemacs made my transition from Vim much smoother, and introduced me to many great packages and ways of configuring Emacs, so I'll always be grateful for that. It's a wonderful project.
But after a few months I started noticing those issues it introduced because of the additional layers of complexity, and decided to start from a scratch .emacs.d and add packages I strictly needed. It's surprising how much can be accomplished with just use-package and a init.d inspired loading structure.
The best thing about Emacs is its malleability, and relying on others to do this for you can be helpful, but is usually not what works best. I suppose this also applies to every 3rd party package you depend on, but I'm not versed in Elisp enough yet to _really_ build my Emacs experience from scratch. ;)
Earlier quoted context omitted.
With lsp-mode, there’s really nothing I can think of that emacs can’t do compared to IDEs. In fact, emacs blows them out of the water. Before LSP was invented, I would have agreed with you. But pretty much all IDE features have been commoditized by LSP now.
The man-or-boy test for IDEs was proposed long ago by Martin Fowler. If the editor can do the ‘extract method’ refactoring, then it's an IDE that properly understands the structure of the code. More generally and forgivably, I'd say the IDE must know that two variables of the same name may be different variables, and to know which instances are which vars. Funny enough, this benefit of IDEs might rarely be felt with…
As soon as you add any kind of metaprogramming or macros to the mix, IDEs start to break, because they can't refactor code that doesn't exist yet. That's an issue for IDEs for C, C++, Rust, D and probably few other languages.
Earlier quoted context omitted.
I use CLion almost exclusively and I use shift-shift to find things so often that I have basically no idea what file anything is in. Is there anything free that even begins to approach the quality and accuracy of the JetBrains Rust analysis plugin? If so, I’d love to know about it and start using vim.
I'm sure there has to be a vim plugin for rls
Earlier quoted context omitted.
Somehow my colleagues who use VS Code or JetBrains IDEs don't manage to learn about those features while all of my vim-using colleagues somehow do. (Haven't worked with anyone using Emacs yet)
In JetBrains you just double shift and a small searchbar opens to allow you to type in any file name. It autocompletes so you do not have to remember the whole name. It is pretty neat.
The one thing I consistently do in emacs that shocks my coworkers -- is running this (custom) function, that I call "arrayify": (defun arrayify (start end quote) "Turn strings on newlines into a QUOTEd, comma-separated one-liner." (interactive "r\nMQuote: ") (let ((insertion (mapconcat (lambda (x) (format "%s%s%s" quote x quote)) (split-string (buffer-substring start end)) ", "))) (delete-region start end) (insert in…
Earlier quoted context omitted.
A lot quicker to do something specific. What if your problem involves text, but is always changing? Then you need general tools and a way to compose them together. Just like general Unix command and Awk which automatically loop through files. I would go crazy if I had to write actual code to do that kind of work 50 times a week.
A difference between emacs functions and awk one-liners is that the former are highly composable. Over the course of weeks you can build whole libraries of custom text-manipulation functionality for your particular domain, all integrated seamlessly into your editor. The thought of calling out to tools like awk for this is really galling. Could just be me, though.
This is mostly a listing of packages and very known ones at that. One of the best features I like is undoing regions. That is, if you know the approximate location of the text that you want to undo, you just select a region that contains that location and call undo. It can be used as a quick git alternative. Say you modify the buffer all over the place. If you want to undo some text that you've modified an hour ago b…
What the fuck, how did I not know this. I am now glad that I read this thread. So much time lost undoing a bunch of changes, killing the piece I want to restore, redoing the changes and then yanking.