8 ms·

> Why not just get rid of it to free up more screen real estate for actually useful things? Like? I have an 80 column width by default. To not let my code run

> Why not just get rid of it to free up more screen real estate for actually useful things? 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.

tlamponi 5y ago
I definitively do not want to critique your workflow, that would be pretty dumb by me, just two comments to your points that I don't agree with in full. > 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.
- KrishnaShripad 5y ago
  > 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. 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.
- KrishnaShripad 5y ago
  > or (type) signature changes 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.
wyuenho 5y ago
> 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. 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.
- KrishnaShripad 5y ago
  > 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. 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.

tlamponi 5y ago

I definitively do not want to critique your workflow, that would be pretty dumb by me, just two comments to your points that I don't agree with in full. > 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.

KrishnaShripad 5y ago
> 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. 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.
KrishnaShripad 5y ago
> or (type) signature changes 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.

wyuenho 5y ago

> 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. 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.

KrishnaShripad 5y ago
> 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. 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.