671–680 of 680 posts
Earlier quoted context omitted.
You can always get the EAP version for free. It's probably stable enough for your rarely touched Go program https://www.jetbrains.com/resources/eap/
Hmm, I can appreciate that free EAP download links would probably be a tad nontrivial to find by design, but after having a bit of a dig I'm still coming up stumped. Do I have to go through the Toolbox to get this?
Earlier quoted context omitted.
You are delusional and immature. I've seen experienced Vim/Emacs kiddies like you really struggle to keep up with my productivity levels in IDEA with JVM languages. Doing everything at the command line doesn't make you 1337 and superior. The actual typing and manipulation of text is the least complex side of development. Most of my time is spent thinking, analyzing, rather than monkeying with text. However I use Vim…
You're not just wrong, you're also rude, which is a sign of immaturity. Professionals try to avoid that kind of language. If you never learned Vim to the sufficient level, you will never understand how incredibly empowering and powerful it is for navigating and editing text. And that IdeaVim is hopelessly lacking many of its features. And if you never gotten in Emacs to the point of writing your own Emacs-lisp packag…
Earlier quoted context omitted.
That's easy with the TUI
Dragging and dropping? Or do I have to rearrange the lines using a text editor?
Earlier quoted context omitted.
Use what works best, but Emacs is incredibly powerful, and certainly has the potential to make you more productive. I wish I had taken the time to learn Emacs earlier in my career, my task efficiency has increased significantly since converting my work flows. It does take a long time to learn relative to plug and play solutions (especially for someone like me with decades of old habits), luckily I had a few months of…
Yeah, that was the bit that got me. Emacs is in many ways the original IDE; insisting that people not use things like method signature hinting feels vaguely perverse.
It’s like the difference between someone who can navigate the highway system with interstate signs & atlases alone vs someone who is unable to navigate at all without a GPS system.
Even if the GPS system experiences no downtime, they still lack skills that make the driving lower quality, like anticipating changes or adjusting for weather.
Coders heavily reliant on IDE tools simply understand the ramifications of what they are writing less well, because they haven’t invested in the mental map of the code and mistakenly believe they can safely offload many parts of that cognitive requirement to an IDE.
Worst of all, they believe that code shipped this way is somehow reinforcing evidence that the IDE was a value additive tool, which is the wrong counterfactual for comparison. You have to consider the value lost from what better solution could otherwise have been shipped for lower cost using a different set of tools.
Earlier quoted context omitted.
Comments like this were part of the reason I wasted a lot of time earlier in my career trying to use emacs or vim on large code bases instead of an IDE. I suspect this is some tribal identity thing about being a “real” programmer that I fell victim too. The IDEs are extremely powerful and much better out of the box for working in a large code base. They allow you to navigate a lot more easily and focus on the code it…
I know a couple of people holding the same opinion as OP. Can't say they are more productive. The percentage of people that are hard to work with is higher in this group though. And I know, what I'm talking about here. Started with a Commodore 64 in 1982, first Linux 1994. Did everything in emacs, calculated mode lines, Unix was my IDE, you name it. I'm a very happy user of CLion and IntelliJ IDEA now. Wouldn't want…
This seems more telling about your attitude towards this subject, and perhaps also lesser skill in assessing or understanding those productivity differences.
I can’t tell you how many times my use of very vanilla Emacs with zero jedi / autocomplete / search features has saved me in my career. It’s so critical to use text editors for software development and extract all other functionality to separate shell tools. If a mix of very simple vim or Emacs + grep / git grep / silver searcher + CLI tools for automatic linting, test cases, etc., isn’t efficient for you, and motiva…
> But general code search, linter/test integration, and embedded features like autocomplete, pop-up signatures or docs, etc., are disastrously bad things hands down for regular development. Do you have any substantiation for that claim?
Earlier quoted context omitted.
Just yesterday I noticed a "Fork Activation" option in the Fork menu with fields for an email and a license key. I think you might be right, it won't be free for much longer.
Yep, and the 'Buy Now' link leads to https://fork.dev/buy Not subscription based!
Somehow I hesitate to pay subscription based models, although I understand why this model exists.
Earlier quoted context omitted.
Can you briefly enumerate some of them here? I'm a casual vimmer and have plateau'd on the basic vim features that are good enough, so I'm curious what advanced commands are useful day-to-day.
Nothing really advanced, I think, although maybe one or two obscure things. Here's the problems I found and remember (I wasn't looking for anything, I was just trying some basic stuff). They all might seem trivial, but we're talking muscle memory heI'M. 1. First thing I did was to fold all the functions in the file - this is something vim does pretty badly, actually, because it doesn't know how to deal with Python sy…
The biggest plus is when working with larger projects. The single-threaded autocomplete and jump-to-definition functionality was very slow in Vim, stalling the UI updates. Goland feels so much smoother in these cases.
Earlier quoted context omitted.
Quite the opposite actually, by the time your hand even finds the mouse the vim user will already have jumped to the desired code block and have started editing it.
Having worked alongside longtime vim users, that's almost never the case. There's often more time spent on finding out/remembering the efficient way to get to a particular piece of code. And then there are the inevitable mistakes (oh, I counted give spaces/quotes/paragraphs, but there was one more/one less; oh, I failed to account for some minor thing in my macro etc.). In a modern IDE you have a multitude of shortcu…
Longtime vim users who didn't know how to use vim? That's... interesting.