Like? I have an 80 column width by default. To not let my code run the entire length of screen for obvious reasons. Also, it is code smell IMHO if you have to write that much code in a single line.
> I know Sublime introduced it but what does it do exactly? Why is everyone copying it? It just shows you the shapes of blocks of texts of a long file from ten meters away
Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll (or if you are using vim you would still need to ctrl+D till you find the problematic line).
If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
> VS Code has a breadcrumb IN ADDITION TO the minimap, possibly because Microsoft realizes its gimmick nature
I sometimes hide my Sidebar in vscode while working in Zen mode. I can then access the directory structure through the breadcrumbs. Especially useful when I don't remember the name of the file ahead of time to use it in command palette search.
Clicking on the filename in the breadcrumb gives me access to all the symbols defined within the file. Quick way to navigate between declared top-level variables/functions.
> Like? I have an 80 column width by default. To not let my code run the entire length of the screen for obvious reasons. Also, it is code smell IMHO if you have to write that much of code in a single line.
What about a split view? I'd be far less productive if my screen wouldn't have space for 4 split view's for >> 80 columns in my editor + a small terminal split by terminal multiplexer.
> Visual cues. I can immediately know if my linter finds something wrong.
Hmm, while there are a few things like renames of variables/functions/... or (type) signature changes for that to happen outside the view one is currently editing in, it's only solving part of the problem — as other files can have those issues too and require changes, so one needs to run a check/lint test or build anyway.
This includes using split views. Of course I have to mention that I use Mac as my primary development machine (which comes with 5K retina display). So already have plenty of real estate. It might be an issue on laptops. But I haven't tried it to give feedback on that. I just gave my personal anecdote.
> so one needs to run a check/lint test or build anyway
If your entire team is already using lint from the start you wouldn't have to worry about it. Even if not, you would have typically run the linter when you cloned the repo. The build process should have lint as a pre-step anyways. So the chances of you having non linted files elsewhere is minimal. And when you rename functions/variables you can rename as symbol, which will change it in all files that reference it. If you have the right workflow setup you wouldn't have to worry about other files being affected.
This I would consider as refactoring. It won't be just making normal edits anymore. Yes, when it comes to refactoring everything goes haywire. But that is a conscious decision isn't it? Then you'll for sure be running linter/tests anyways. So yes, in such cases what you said is valid. However, having a mini-map won't be a hindrance here. At least I don't see how it could be. It might be useless for this case. That I agree.
There are many useful things your editor can render on screen other than code. If you've used any IDE at all, you wouldn't be saying this. File browsers, syntax tree index, class hierarchies etc. Let you imagination run wild.
> Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll.
Again, lack of imagination here. You only need a red icon on a status bar or something to know if your linter has found something wrong, and a counter next to it to tell you how many. If you want to go to an error, you jump from the keyboard, not use your mouse to scroll.
> or if you are using vim you would still need to ctrl+D till you find the problematic line
As an Emacs user who's seen plenty of fancy vim configs of my colleagues, I suspect you didn't even bother configuring your vim at all.
> If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
LOL. Any reasonable editor has a diff mode and allows you to zoom in and out with something like cmd +/-.
As to the breadcrumb, I wasn't saying breadcrumb was a gimmick, I was saying the minimap is a gimmick, therefore Microsoft has to introduce breadcrumb to aid navigation because the minimap just takes up space.
Which is already available in the VS Code Sidebar. You have everything you mention in VS Code already.
> Again, lack of imagination here. You only need a red icon on a status bar or something to know if your linter has found something wrong, and a counter next to it to tell you how many. If you want to go to an error, you jump from the keyboard, not use your mouse to scroll.
Which I already get in VS Code. I am talking about advantages I get with mini map. I don't want to use my keyboard or the mouse to know where the problem is (if any). I can get 10000 ft view of my entire code in the mini map without having to touch my keyboard or mouse. You won't get it if you haven't used an editor with mini map functionality for a period of time.
> As an Emacs user who's seen plenty of fancy vim configs of my colleagues, I suspect you didn't even bother configuring your vim at all.
I just gave you my take on VS Code features that I like.
I have configured Vim according to my liking. I use Vim within VSCode. But what use is that for this discussion? I don't want to take any extra steps to know the status of the file. I get that with the mini map. I don't want to touch the mouse or keyboard to know where the problem is. Or which part of the code I want to instantly navigate to.
> introduce breadcrumb to aid navigation
You literally have a file browser in VS Code in the sidebar. Apart from that you have a Command Palette that you can invoke to navigate between pages. Why would you need breadcrumb to aid navigation?
> LOL. Any reasonable editor has a diff mode and allows you to zoom in and out with something like cmd +/-.
I am talking about what I like about the minimap. All editors have diff mode including VSCode. I want to see it at a glance without having to touch my keyboard or mouse. Not use cmd +/- to zoom in and out. All these introduce extra steps that I just don't want to do.
This is exactly what I'm trying to understand. Why? What *actionable* information does it give you that you can't get from a red bar next to the scroll bar or the error total on the status bar?
> I don't want to touch the mouse or keyboard to know where the problem is. Or which part of the code I want to instantly navigate to.
Why do you need to know where? Just jump to the first one from the keyboard. When you are done fixing one, jump to the next one from the keyboard until all of them are fixed. It's not like you can compile or commit before all of them are fixed anyway, and it's not like you can jump to the errors just by looking at the minimap.
> You literally have a file browser in VS Code in the sidebar. Apart from that you have a Command Palette that you can invoke to navigate between pages. Why would you need breadcrumb to aid navigation?
Because that's the only mechanism that will take you to exactly where you want in the syntax tree hierarchy within the same file. It's not great as it only takes you up and down one path, but it's better than having to click on a screenful in the minimap and then having to scan the entire screenful to find the thing you are searching for because all you have is the shape, you aren't even sure what exactly it is.
> I want to see it at a glance without having to touch my keyboard or mouse.
Why? Your compiler or linter or precommit script won't let you proceed without having them fixed anyway. What does it matter where in relation to everything else a blurry red line is in the file? If there's any type checking in your tooling, typically one error is going to lead to dozens and often half of the file will be red. The most useful information is the root cause of a massive error, how does a minimap help you besides telling you you broke half of your code in a file?
> Because that's the only mechanism that will take you to exactly where you want in the syntax tree hierarchy within the same file
That's not true. The quickest way is to Cmd + R. It opens the Command Palette with the list of all symbols. You can either fuzzy search or navigate to the symbol.
You also have it in the Sidebar. Check the Outline tab you'll get the entire list of symbols used within the file. I don't use the Sidebar Outline anyways because I have the Command Palette for it to jump to symbol. I find using Command Palette for most editor based operations much faster. That includes file navigation, going to a symbol (which you call syntax tree hierarchy) and other stuff (like running builds, running tests etc).
> Why do you need to know where? Just jump to the first one from the keyboard
Because I have a rough idea of what parts of my code is where. When I encounter an error, I simply know it is in that particular region of the mini-map and just click that region. It is so much faster than any keybinding that you can think of.
Also, if the error is in multiple places but I know the source for the error is not at the top of the file but at the bottom of the file, I can go straight to that region. Not all errors have to start from the first error that is encountered.
This is not something that can be explained. This is acquired experience that you get only after you give the feature a shot for sometime.
> besides telling you you broke half of your code in a file?
If that is your consistent experience then you have far bigger problems than the editor. I would look at why your code is so tightly coupled that it leads to half the file showing you red lines. That is not normal. At least in my experience I haven't had to deal with squiggly lines that span half the file. At most 2-3 lines. Unless I am refactoring code (which is not considered fixing in technical sense).
> Your compiler or linter or precommit script won't let you proceed without having them fixed anyway
I have a linter running in realtime in VS Code which auto-formats my file and points to any problems in realtime. The linter precommit script is only for extra layer of security and for those devs who have their own custom configurations which don't allow for realtime linter. I hope you realize that every developer has his/her own unique setup to make life easier for themselves.
I've been programming professionally since 2004, have tried the minimap on various editors since Sublime invented it, never found it useful.
As to tightly coupled code, well, ha, I don't know of a compiler/linter that won't spew 100s of errors because of one syntax error in a commonly used type.
I realize it's a unique workflow, that's why I want to know more why it's prioritized in every editor these days as I don't think this uniqueness qualifies it to ever become mainstream, much less prioritized.
I agree with you here that you have to go one extra step to open the Outline panel in the left. I would rather the Outline panel be in the right. However, I don't use symbols that often. My workflow is a bit different. So I don't particularly miss this feature. When I really need to look up by symbol, I just use Cmd + R and just fuzzy search for it.
> In the case of breadcrumbs, clicking on it with the mouse is probably faster than searching.
Again, this is personal preference. I find Command Palette faster. You find Breadcrumbs faster. But I guess since you already use Emacs, it is fastest with Outline panel on the right.
> I realize it's a unique workflow, that's why I want to know more why it's prioritized in every editor these days as I don't think this uniqueness qualifies it to ever become mainstream, much less prioritized.
Maybe Telemetry data shows that the feature is used a lot. I don't know. Even if it was by default turned off, I would turn it back on because I just feel comfortable having it on the side. I use it subconsciously so whatever I gave you were mostly from what I could remember. It is only when it is off (or when I am using another editor), that I subconsciously try to reach for the mini-map and find it jarring when it is not there. I gave you few examples. But I am sure there are few more that I am missing out on.
I mean, I can see why it got popular when Sublime introduced it. It was a time when most webdevs were editing in massive HTML templates, SASS/CSS and ES5, where the traditional outline view would return too much noise or missing important targets. But we've quickly moved past that era, it doesn't seem to make sense anymore for new players to prioritize it now.
Overall I would say that trying to notice and measure the effect isn't productive. It's just a bit of extra context I realized in retrospect.
Not only the position in a source file is relevant for many languages, but if you're jumping to references/definitions blindly from another source, you can tell which source file it is and where you are in a single shot without looking at the rest.
That being said, I don't use the minimap. I did try to use it though to see what's the fuss around it. For me it takes too much horizontal space. I can have another vertical split pane instead of having minimaps showing. Heck, I'm not even using scrollbars.
Having an indicator of which function your cursor is currently inside provides very similar benefits to me. Not as immediate as a minimap I have to say, but more useful if you take the time to read it. This is a tradeoff people will argue on forever.
You could argue it's highly situational, but IMO it's nice to always be able to see how complicated your codebase is getting, tech debt is no joke
I didn't try this one (I'm not on a mac), but I fully expect it to do that too. All of them do. (I'll be glad if somebody tells me it doesn't.)