- Joined
- Aug 17, 2018
Internally you can do :vs **/*foo and hit tab to find any file containing foo.Can you show me a demonstration of that? It would be news to me.
There are also plugins that are faster.
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Internally you can do :vs **/*foo and hit tab to find any file containing foo.Can you show me a demonstration of that? It would be news to me.
mmm, no that's not really what I'm talking about. Have you ever used jetbrain products before?Internally you can do :vs **/*foo and hit tab to find any file containing foo.
There are also plugins that are faster.
Forever ago. What do you want to search: file names, file content, function/class names?mmm, no that's not really what I'm talking about. Have you ever used jetbrain products before?
Updated my original post to include examples. They pretty much cover what I'm talking about.Forever ago. What do you want search file names, file content, function/class names?
All three are possible with vim.
Sounds like vimgrep, you can also use external grep, which is as fast it gets for raw text.Updated my original post to include examples. They pretty much cover what I'm talking about.
I realize that thousands of extensions exist for vim, and I'm sure that if you put some large number of them together, you can approximate an IDE. However, the amount of potential fiddling, breakage and lack of polish, to me, is not worth over just paying $70 per year, which pays itself off in less than a few days. Also in my experience fuzzy search with vim was pretty slow. I don't know if it's indexing anything and might just be using raw text find.
If we take languages like Java as an example would you say the compiler chain is the more significant part the IDE hides from you, or the compiler chain, abstraction, project structure, class hierarchy, etc?Probably correct, but I'd say that's less due to the autocompletion and more of them completely hiding the compiler chain from you. You just press a button and now you have a program. It's magic!
So can GNU/Emacs, with frameworks like Helm and Ivy.VIM can do that.
I'm unsure what you mean by hiding abstractions/project structure/hierarchy. The only thing i can guess is that the navigation tools make you not have to refer to them as often. They're still there and they're still important to maintain, though.If we take languages like Java as an example would you say the compiler chain is the more significant part the IDE hides from you, or the compiler chain, abstraction, project structure, class hierarchy, etc?
It can cause a mental hitch on the rare occasion when navigation breaks, but I haven't experienced that impacting my workflow. I'll grant that it allows your memory to be not as precise to get by, but I couldn't speak to the long term effects of that.It is my experience that IDEs can cause brain damage which becomes evident when the IDE can't be of much help or is non existent. Try bringing someone used to IntelliJ over to Lisp of OCaml, they'll have an anuerism.
That sounds like a config issue. On my setup, my screen is only code and everything else is hidden under context menus/hotkeys. Only there when I need it.IDEs hide too much and bombard you with useless information at the same time. When I'm programming I want to see text, not buttons, terminals, prompts, project tree, what have you. Too much visual noise instead of a text buffer and maybe some unobtrusive visual popups. When I see how my colleagues work I'm appalled at the actual code taking up the smallest part of screen real estate.
I completely agree with that, for what it's worth.I don't think IDEs are bad, but I think programming shouldn't be taught with them and if you work with them take a couple of weeks each year without them just to reset your brain.
What I mean is that the developer might have no idea what some class is, what other classes use it, what interfaces it satisfies. IDEs are so sophisticated they allow you to narrow your scope of focus to such a degree it becomes disconnected from the rest of the code base.I'm unsure what you mean by hiding abstractions/project structure/hierarchy. The only thing i can guess is that the navigation tools make you not have to refer to them as often. They're still there and they're still important to maintain, though.
It isn't just memory. It's understanding. IDEs save you some of the mental effort of thinking about how stuff fits together, because you don't even have to remember.It can cause a mental hitch on the rare occasion when navigation breaks, but I haven't experienced that impacting my workflow. I'll grant that it allows your memory to be not as precise to get by, but I couldn't speak to the long term effects of that.
And what does it say about IDEs that their default configurations are god awful and developers don't even bother messing with them?That sounds like a config issue. On my setup, my screen is only code and everything else is hidden under context menus/hotkeys. Only there when I need it.
Ofc you need a debugger where everything is mutable, things can pass by reference, and the method of abstraction is encapsulation. That sounds like a paradigm problem with procedural languages.Whether your text editor is part of an IDE or not is immaterial, but debugging without a graphical IDE (i.e. not some hack where you pipe gdb output into emacs) is a fool's errand.
Doesn't this strike you as a problem? Why do you even need such heavy refactoring tools? Why do you have to write so much boilerplate? It sounds like a problem inherent to the tools.I think the best things about using an IDE is refactoring and code analysis. I'm not really sure what the capacilities are with vim when it comes to those but I can hit a few buttons and let the ide refactor for the next 15 minutes and grab a coffee. That combined with the autogeneration of boilerplate is pretty much the only reason I use an ide over anything else. Autocompletion is nice too but generally not needed when you can jump to source code with a hotkey. I would say the worst part about ides is the perpetual bloat they receive to justify their development team being employed.
It's a problem of the Java language itself in the case of intellij idea. Having encapsulation creates a getter/setter for every field you want to be "public" in your java api. Kotlin solves this issue by having properties like C# (with getter/setter creation which you can override) plus data class generating getters/setters, hashCode, toString during compilation. Kotlin is basically a bandaid solution to all the problems of Java, it supports a lot of things Java never could but it still is java/javascript.Doesn't this strike you as a problem? Why do you even need such heavy refactoring tools? Why do you have to write so much boilerplate? It sounds like a problem inherent to the tools.
An IDE doesn't hide anything from you except what you want it to hide. You have full access to browse source code of all your dependencies and any hierarchy. There are hotkeys and a menu to go to declaration/usages, type definition, superclasses, subclasses, etc.What I mean is that the developer might have no idea what some class is, what other classes use it, what interfaces it satisfies. IDEs are so sophisticated they allow you to narrow your scope of focus to such a degree it becomes disconnected from the rest of the code base.
Who exactly isn't messing with their IDE's window configuration?And what does it say about IDEs that their default configurations are god awful and developers don't even bother messing with them?
Everything isn't mutable and debuggers don't become useless because your program limits side-effects.Ofc you need a debugger where everything is mutable, things can pass by reference, and the method of abstraction is encapsulation. That sounds like a paradigm problem with procedural languages.
That's a feature, not a bug. If the design of a program is so inherently wirecrossed that I have to think about the entire system every time I'm making a change, that's a really serious problem that needs to be addressed separately.What I mean is that the developer might have no idea what some class is, what other classes use it, what interfaces it satisfies. IDEs are so sophisticated they allow you to narrow your scope of focus to such a degree it becomes disconnected from the rest of the code base.
That's a problem with people in general. Most people never invest the few hours it takes to customize out the defaults on anything. I'd rather an IDE start me out with everything displayed on screen so I know what's there, then give me easy options to hide it.And what does it say about IDEs that their default configurations are god awful and developers don't even bother messing with them?
Because we don't live in a perfect world. Most code is 'legacy code' and needs to remain compatible with useful, real world applications. Industrial applications are a mess. That's a product of tight deadlines and limited resources. At some point you need to make it work and move on. Perfect code is useless code.Doesn't this strike you as a problem? Why do you even need such heavy refactoring tools? Why do you have to write so much boilerplate? It sounds like a problem inherent to the tools.
I'd like to get detailed reports about identifiers on demand, for example, I'd like to be able to select a type and get a window on the side that tells me about the struct's size and memory layout, what files use it, what functions take it as an argument, what functions use it in their body, the lines where it's used, etc.
I believe resharper can do all of those (except expanding templates).I'd like to be able to select a macro or template at its call site and see how it actually expands/specializes.
I'm actually surprised this feature isn't in more places. A jank approximation is 'local history' extensions where it will make a copy of the file every time you save in an out of sight, out of mind location, and then you can recover whatever you want from those scrap files. That's far from elegant, but it does help me be less afraid to make "big undos".I'd like a tree-like undo system so I don't have to worry about deleting future work when going back in time to copy something I didn't realize I needed.
I've been using this for some time and it's a godsend.I'd like curly braces and parens to have alternating highlighting so it's easier to spot pairs.
The slowness is a valid complaint. Turning off code analysis (eg: clang) can help a lot, though.it's always so fucking slooow.
Eclipse has an abomination of an interface and I think it gives a lot of people a bad impression of IDEs who would otherwise like them.The last time I worked at a Java shop we were forced to use Eclipse, and I spent a day exploring the bowels of its menus so I could find and disable every feature that just got in my way. There's so much useless shit in there, and a lot of it caused Eclipse to randomly grind to a screeching halt when I was trying to do stuff. Breaking my concentration like that isn't acceptable, and I don't get how the Eclipse Foundation thinks any of this is a good idea. I don't like IntelliJ either, but at least it's not obviously retarded.
Java now introduced Records which are basically this feature, too, and fields are immutable by defaultIt's a problem of the Java language itself in the case of intellij idea. Having encapsulation creates a getter/setter for every field you want to be "public" in your java api. Kotlin solves this issue by having properties like C# (with getter/setter creation which you can override) plus data class generating getters/setters, hashCode, toString during compilation. Kotlin is basically a bandaid solution to all the problems of Java, it supports a lot of things Java never could but it still is java/javascript.
It eliminates about 95% of the use cases for a debugger when tests don't require elaborate set up and tear down for state. And I didn't mention side effects, I put more emphasis on immutable data. I rarely have to reach for a debugger most of the time, and I don't work on trivial code.Everything isn't mutable and debuggers don't become useless because your program limits side-effects.
You an Emacs user?tree-like undo system
Haven't tried it yet. My current code editor is Sublime. Tree-like undo is just the obvious way to handle the problem.You an Emacs user?
Emacs has undo tree. Saved my ass a few times.Haven't tried it yet. My current code editor is Sublime. Tree-like undo is just the obvious way to handle the problem.
Forgot to reply to this one. My takeaway is that IDEs today are too powerful for our monkey brains. They make writing big-ball-of-mud too easy. Only by limiting yourself can you find enlightenment, or something gay like that.That's a feature, not a bug. If the design of a program is so inherently wirecrossed that I have to think about the entire system every time I'm making a change, that's a really serious problem that needs to be addressed separately.
You should definitely look more into Clojure. I think CIDER's at a point where it's richer than SLIME, among other reasons because it had to be to make up for features CLers like to brag about, such as conditions and restarts. It's the best programming experience I've had and writing production grade applications isn't complicated or requires much ceremony.I use Emacs pretty religiously, and the best development experience is when the language exposes a server to which Emacs connects, so that if my editor wants to autocomplete a symbol, it can send a request to the server and the big brains that's responsible for parsing/type-checking/compiling the code can give back an intelligent response. I believe the first example of this was Common Lisp and SLIME. Clojure took the same model with Cider. Scala has ensime. Ocaml has Merlin which is now a must for me, but honestly, its feature set looks pretty puny compared to Cider. Nowadays, the model is standardised in LSP, and I guess most folk writing new modes for Emacs look first to writing LSP clients.
If I end up Java coding again, I will certainly check out https://github.com/emacs-lsp/lsp-java, but this didn't exist when I was last full-time java, and I couldn't figure out an Emacs setup that came close to what IntelliJ offered. Some of the benefits of IntelliJ are, as has been said, just problems with Java. The amount of boilerplate makes it the most obnoxious language I've ever used, and the fact that I need an IDE to fix this is not a point in favour of IDEs. But IntelliJ does stuff that I want just as much in Emacs, like semantically aware autocomplete/renaming/goto-definition/find-usages/format-according-to-styleguide. For Java, and for other imperative first languages, I also want a solid integrated debugger, with the ability to set conditional breakpoints and evaluate code. All of this is possible in Emacs, and is available for some languages, but it's not universal.
Having a compiler toolchain abstracted away is normally dealt with outside of Emacs, and in compiled languages, I expect to be able to hit C-c C-c and have my project rebuilt. But exactly what I want here depends on the language. I quite like REPLs, and I want to be able to quickly switch to one with my current file reloaded. But better than REPLs is the sort of exploratory testing I can do in Emacs lisp, where I can just evaluate arbitrary expressions in my buffer. I assume this is standard in Clojure, and along with Cider, it's a real temptation to look more into that language.
For simple editing tasks, things like undo-tree are great, but just having an undo-ring is superior to the normal implementation of undo/redo. Ditto for copy/paste (kill/yank). I recall that IntelliJ had undo history, but I believe it had only 5 or so slots by default, which made it pretty useless for the way Emacs has accustomed me to using the kill ring. I have also used Elisp in anger to do nasty refactors on large code-bases, in ways that I'm not sure would be possible in IntelliJ, but it's not exactly stuff I'm proud of.
Oh no no, the autocompletion IS the Devil. Toolchain hiding is just a minor demon in comparison.Probably correct, but I'd say that's less due to the autocompletion and more of them completely hiding the compiler chain from you. You just press a button and now you have a program. It's magic!