code editors I have known

[Uncle Buddy]

For years I've used Notepad++, a simple but feature-rich open-source code editor. I regularly try an IDE only to find that the bells and whistles are distracting.

I'm finally hoping to move on to a more amazing editor (but not an IDE).

I tried Atom and liked it but it seemed glitchy and some of the features were not reliable. Every time I wanted a missing feature I had to research which plug-in to install, and sometimes had to shop among several competing plug-ins, which is a case of too many chefs spoil the stew.

So I installed VS Code. Atom and VS Code are both open source and totally free, and they're both owned by Microsoft.

Here's a comparison of Atom and VS Code. I'll be adding to this list if I learn more. I'll stick to features that are important to me. For example, I turn off all autocomplete, because I find it distracting. I prefer to hone what's left of my memory and I get kinda dizzy when I type something and stuff appears to the right of my cursor.

Here are the features I really liked from Notepad++ which I expect to find in NPP's replacement if I do end up making the switch.

Dragging highlighted text and dropping it somewhere else:
--Atom has the feature if you install it. It sort of works part of the time. (Works like a plug-in vs. something that was planned from the start.) You have to "click & hold" or some such extraneous nonsense.
--VS Code's feature works perfectly out of the box, no extra work to do such as the Atom plug-in's "click & hold".

Highlighting of same words:
--Atom has the feature if you install it. The highlighted words are highlighted by an ugly thick border around them.
--VS Code has this feature out of the box. Highlights normally by adding a transparent color over the same-spelled words.

Search (ctrl+f):
--Both Atom and VS Code are better than Notepad++ because the dialog opens within the main GUI window instead of opening a separate window. Notepad's separate search window gets in the way because I tend to have it open a lot, and it doesn't accept themes so it has a bright background. It's one of the reasons I wanted to switch, although its functionalities are excellent.
--VS Code's search area is a lot smaller than Atom's.
--VS Code's find-and-replace input opens with ctrl-H as expected; Atom's is always open.
--Another GUI misfeature in Notepad++ is fixed in both Atom and VS Code. In Notepad++ you have to click a button to get a count of how many occurrences there are of the search term. Atom shows this count but in an overly-large and too-detailed search form. VS Code's search form is very small by default, gets bigger if you add the ctrl-H input and the term count is easy to spot.
--Both VS Code and Atom make you point at an icon to find out what it does (whole word, match case, regex, etc.). In Atom these icons are way too big.

Left panel for directories:
--I didn't know I missed this feature in Notepad++ till I tried Atom. It's no longer necessary to look in Windows Explorer all the time or use the Open menu at the top like in Notepad++.
--I like Atom's better. At least out of the box anyway, VS Code's directory panel shows only files from the current project and it doesn't show the directory you told it to open in the panel itself, just in the title bar of the app. Then it only shows this directory's subdirectories and files in the left panel. Why break up the family like this? I want to see the whole tree in one place.
--In Atom on the other hand, you add any directory you want to the panel and there that directory is displayed as a project with all its subdirectories. You can add a bunch of projects and collapse the ones you don't want to see. So far I like Atom's better but you have to remember to delete a project from the directory before changing your file structure outside of Atom or Atom will complain about missing files every time you open it.
--EDIT: VS Code again measures up to Atom. I tried File > Add Folder to Workspace and now all three of my current projects are displayed with all their subfolders in the left panel, and the root folder of each project is there too as expected. It's a little more complicated in VS Code only because the instructions start out with the bells & whistles, but when you figure out what to do it's as easy as adding a project in Atom.
--Even better, I added an empty folder called "Test" to the workspaces panel and then deleted it from outside VS Code. Next time I opened VS Code, instead of Atom's big scary red error message that made it look like my computer was going to melt, there was just a red "!" next to the folder in the left panel. All I had to do to get rid of the "!" was to use a right-click menu option "Remove Folder From Workspace". Once again, VS Code just plain works better than Atom.

Scrollbars:
--Atom's scrollbars are thin and trendy. When you point at them, they get fat enough to use, but the problem is that using them includes pointing at them. So I consider them relatively useless, because I often have to re-aim when they don't expand or when I guess wrong about where I'm supposed to be pointing.
--VS Code's scrollbars are also trendy--they appear and disappear--but they are much better then Atom's. The vertical scrollbar is always there and the horizontal scrollbar appears long before you need it. This works with the principle of "how can you point at something if you don't know where it is" which modern trendsters seem to be missing in their mad dash to make everything invisible and flat.

Auto-Indent:
--Or whatever it's called when something should be indented a certain way and the editor tries to do it for you. Notepad++ usually guesses wrong and I couldn't figure out how to turn the feature off, so every time I pasted code I had to change the indentation on the first line. At one time I had it set up right but when I updated to a new version it went back to "smart is stupid" and I never spent the time to re-figure out how I fixed it the first time.
--In Atom, if I type <div> and the </div> fills in to the right of the cursor, obviously I will then want to hit enter to put the closing tag on its own line. This works but the closing tag is then auto-indented so it looks like this and I have to fix it manually, negating the supposed value of the whole feature:
 <div>
   </div>--VS Code refreshingly keeps the opening and closing tags lined up, which means I won't have to try and figure out how to turn auto-indent off. I tried several times to fix auto-indent in Atom but my research didn't turn up any simple instructions. In VS Code it works right out of the box. Maybe Atom is for developers who'd rather spend their time polishing their tools than writing code. The instructions I did find for auto-indent in Atom never really said what auto-indent was supposed to do, and it sounded like fixing whatever-it-is possibly involves hopping up and down on one foot while throwing salt over your left shoulder. Hells bells, I can't even walk and chew gum at the same time, that's why I had to give up walking.
--I haven't looked into other auto-indent functionalities but VS Code beats Atom with one hand tied behind its back in terms of auto-filling HTML closing tags and then correctly placing the closing tag in the right column, i.e. not auto-indenting.

Editor margins:
--Atom is better in this category. There's a tab at top with the file name on it. The tab and the line number column at far left are a different color than the editor body where I type. This is normal. It's just sensible. I don't want to feel lost in a space of undifferentiated backgrounds.
--VS Code is terrible in this regard. Flat is trendy right now, so flat is being overdone everywhere, especially in the margins of VS Code Editor. The tab at the top and the line number column at far left are exactly the same color as the editor area where I type. This has been bugging me for days and I just now realized what was bugging me. I want to know where I am. Also VS Code has an extra line of text displayed at the top of the page, between the top tab and the editor area. On this line is shown the file's path and some buttons with redundant functionality. So the line is useless, ugly clutter, but the worst part is that once again it's exactly the same color as the editor page. Hopefully this "flat only" trend will not be fashionable forever, and designers can go back to letting us know, within reason, where we are and what we can expect from different parts of the page.
--The extra line for the path could be a tooltip that is shown if I point to the tab. It's just redundant noise and not wanted. But if it didn't have the appearance of just swimming around in a huge area of all one color, I never would have thought to complain about it. The editor area should be one color. The top tab and the left column for line numbers should be a slightly different color. But one big uni-color area is just a confusing void. The extra line of text intrudes upon my work area because it looks like I typed it there. Same goes for the line numbers column at far left. It looks like I typed them there. I haven't looked into whether or not this can be customized.
--There is actually a shadow between the extra line above the editor and the editor itself, but this line disappears when the file is scrolled all the way to the top. Cute but useless feature. Worse than useless because it blends the page header into the page and makes it look like somebody forgot to do something. This "make it disappear" trend is all about designers wanting to play, and not considering whether their design feature makes the GUI easier or harder to use. If an icon or button or anything else disappears from the page, there should be a solid reason for it, not just because it's fun to design that kind of stuff.

[Uncle Buddy]

I'm trying to be more open-minded and try things. VS Code is pretty good. I'm trying the autocomplete. Theoretically it's not so bad to have a list of possibles. This could actually teach me, whereas my memory is not going to teach me anything about something I've never done before. But after trying and trying to not be annoyed by flyouts and automatic typing, I can't help but think this is the wrong way to teach what a programming language might expect. Maybe the suggestions will be useful later when such a large percentage of what is shown is no longer gibberish that means nothing to me.

In VS Code there are way too many big flying things popping up in the editor when I try to type. I'll probably get tired of them and turn them off. It seems there is more than one similar feature I'll have to turn off, but I'd like to keep the autocomplete for html tags and maybe suggestions for program key words. I definitely don't like the huge explanatory flyouts. I need this information when I need it, not whenever some helpful designer wants to shove it in my face. I prefer to go to MDN myself and do my research instead of having MDN info splattered on top of code I'm trying to read and write. Does anyone actually like this flyout stuff?

In Treebard autofill inputs, nothing flies out to block the view. It's just an input and the possible values just fill in when you type the right letters. I'm talking about nested places, which no one would want to type over and over. Having a big list of values open up to cover the part of the page you're trying to look at is one of those weird ideas that doesn't seem to go away. Comboboxes are useful when there aren't a lot of values, but if there are a lot, then who wants to change over to arrows or mouse or scrollbar to flip through dozens of values by eyeball? The software should just fill in the right values if possible, while the user types, and if the desired value isn't stored, the user can type it in.

Also in Treebard, if a tooltip is very large or if it's something that only some people will want to see, it's displayed on the statusbar, not on top of the page content. I think most of the pop-ups since the dawn of the GUI are mainly appreciated by the GUI designers who create them. It is fun to make stuff like that. But does the user actually appreciate them?

[Uncle Buddy]

I think I got rid of the huge tooltips and VS Code is now in pretty good shape.

It wasn't hard to do. The instructions are here and here.

Here is the pertinent section of my resulting JSON file.

   "workbench.editor.enablePreview": false,
   "workbench.colorCustomizations" : {
     "editorBracketMatch.background": "yellow",
     "editorBracketMatch.border": "skyblue",
   },
   "explorer.compactFolders": false,
   "editor.detectIndentation": false,
   "editor.tabSize": 2,
   "editor.hover.sticky": false,
   "editor.quickSuggestions": {
     "other": false,
     "comments": false,
     "strings": false
   },
   "editor.snippetSuggestions": "none",
   "editor.suggestOnTriggerCharacters": false,
   "editor.acceptSuggestionOnEnter": "off",
   "editor.acceptSuggestionOnCommitCharacter": false,
   "editor.quickSuggestionsDelay": 10000,
   "editor.parameterHints.enabled": false,
   "editor.suggest.snippetsPreventQuickSuggestions": false,
   "editor.autoClosingQuotes": "never",
   "editor.hover.enabled": false,
   "editor.wordBasedSuggestions": false,
   "editor.hover.delay": 10000

[Uncle Buddy]

I was surprised to learn that VS Code doesn't have a simple macro recorder like Notepad++ has. MS Word has had this feature since the dark ages. Atom supposedly has something similar but not as good as Notepad++. There are a lot of macro extensions in VS Code but you have to write the macro yourself. If anyone knows of a simple macro recorder for VS Code that works like Notepad++ or Word's macro recorder, let me know. To meet the standard set by Notepad++ and Word, it would have to have an easy way to assign key combinations also.

Easier than using the available macro extensions that make you write the macro code yourself: open Notepad++, paste in the code you want to modify, record the macro, do the modification, paste the result back into VS Code. This won't work for key combinations I use on the fly in Notepad++ which save me a huge amount of time. So in order to migrate the treebard_gps project to VS Code, I'll have to learn how to find the commands and use them to create macros. Not in a hurry to do that but it's probably easier than I think.

Two macros I use constantly in Notepad++.

1) The code is stored in another module called dev_tools.py which I import as dt. I position the cursor in a blank line of a file and hit the key combination. The stored code types `dt.make_rollback_copy()` in the blank line. I run the file and the added function call creates a snapshot of the file with a timestamp in a folder where I keep all my rollbacks. I hit another key combination to delete the extra function call and save the file. For example, if the name of the file is `places.py`, the name of the snapshot would be something like `places202106051156.py`.

2) This one is saving me a lot of time, it's a recent addition. In a blank line I type any Python variable that has a definition in the file, e.g. `ids`, and hit a key combination. The macro changes the line I just typed to this: `print("line", looky(seeline()).lineno, "ids:", ids)`. In the console, the current value of the variable prints out like this: `line 455 ids: [9, 14, 1]`. This code is also stored in dev_tools.py and imported like this: `from dev_tools import looky, seeline`.

Regarding the first macro above, this is how I save snapshots of my code every time I do something right. At the end of the day I copy all the rollbacks to my backup drive. But when I've made changes to more than one file, I run a module called backup.pyw and it makes a snapshot of the whole project as well as a log.txt file with all the file names, when they were last modified, and notes I add about where the project stands at the time of this snapshot.

That's what I've been doing instead of using git. Now just recently, I have git working and I'm also keeping local commits, working in a branch, etc. I haven't learned how to roll back to a previous version using git, but when I do, my personal way of recording snapshots of files and of the whole project can be abandoned.

[Uncle Buddy]

Here's a good VS Code feature. The flyout suggestions don't work since I have them turned off, but the main functionality itself does work. For example, type `!` and press Tab in a blank HTML document, and the basic HTML boilerplate fills in automatically. Or type `script` and press Tab, and you get this: `<script></script>` with the cursor correctly positioned between the two tags. Same goes for all the HTML tags.

www.youtube.com/watch?v=45eWEO0gRHI

If these don't work:

In settings search Emmet and enable "Emmet: trigger expansion on tab".

[Uncle Buddy]

VS Code: The extra line between the top navigation tabs and the editor, which redundantly shows the file path and is the same color as everything else and just plain looks bad as well as being redundant, out of place, and just bad feng shui...

Easy to get rid of it. Open settings, search "breadcrumb" and uncheck the box that says "enable/disable navigation breadcrumbs." It's gone and the editor looks pretty good now.

I can still complain about the wide far left border being the same color as the editor--you don't know where to click with the mouse to get to where you'd go if you just pressed the Home key on the keyboard, because you can't tell where the line numbering wide left border ends and the editor begins. This issue has been raised in the VS Code github repo here: github.com/Microsoft/vscode/issues/7739. I will see if the suggested solution works for me.

Yep, works great. I just opened my settings.json file and added "editorGutter.background": "#055973", in the "workbench.colorCustomizations" section. Perfect. Now VS Code looks like a code editor. Less cluttered and easier to find my way around than the out-of-the-box version.

[Uncle Buddy]

I got fed up with VS Code's fading scrollbars and got rid of the feature by adding these two lines to the settings json file (File>Preferences>Settings, then click an icon in the NE corner to open the json file).

"editor.scrollbar.vertical": "visible",
"editor.scrollbar.horizontal": "visible",

Nothing wrong with hiding scrollbars completely when they're not needed. But when the window is smaller than the content, the scrollbars should already be visible when I look for them. This also makes it possible for the user to discern at a glance where they are within the document, proportionately to the full document size.

Another backwardsly-intuitive feature of the VS trendy scrollbar is that the bottom scrollbar trough is semi-transparent. This causes me to see what's under it. So I click what's under it and my cursor doesn't appear there. I click again. And again. Finally I remember what this semi-transparent stripe is at the bottom of the editor. A scrollbar trough. Without a slider. Oh my aching hand.

I mentioned above that the bars appear before they're needed but in practice this turned out not to be true. These bubble-gum features exacerbate my aching mousehand condition. I have to move the mouse to the scrollbar trough, wait the trendy milliseconds for the scrollbar to fade in, then move the mouse again to where the lately-realized slider actually appeared. Trendsters ruin user experience, don't be a trendster. There is going to be a decided lack of fadey/transparent/animated features in the Treebard GUI and I don't think anyone is gonna complain about that.

I will use transparency where it's beautiful and doesn't have impractical side effects. I love stupid pet tricks as much as anyone else.

[Uncle Buddy]

VS Code has been driving me crazy by not showing me all my tabs. Unlike Notepad++ and Firefox, there's no left and right arrows to the left and right of the tabs to scroll through all the tabs. Here's how this can be fixed in the settings .json file:

"workbench.editor.tabSizing": "shrink",
"workbench.editor.wrapTabs": true,
Instead of adding arrows to scroll through the tabs, the second setting makes two rows of tabs so I'm able to see all 13 open tabs.

The first setting stopped making the tabs so long. It shrank them to fit their contents. This setting by itself increased visibility from only 5 tabs to 8 tabs. The second setting shows them all.

[Uncle Buddy]

VS Code: I'm all for replacing Windows' built-in title bar with a custom title bar, and I went to a lot of trouble to make a feature like this in Tkinter. But VS Code has filled its custom title bar with the menu items you'd normally expect to see right under a title bar. This means that if you want to drag the window by the title bar, you have to seek a blank place on the title bar to drag by, otherwise you're clicking a command to open a dropdown menu.

To get rid of this further example of featuritis: File → Preferences → Settings → Window → Title Bar Style and set it to native.

[Uncle Buddy]

Trying to get VS Code to stop looking like a bubble gum machine is getting harder, not easier. I actually took a couple weeks off to beat my head against a new wall: creating my own simplistic code editor. I forced myself to stop at a certain point but it's looking good and has some nice features including one that's not available elsewhere. I hope to get back to it someday.

It's named after a lightweight one-man boat that a fisherman carries home on his back.

CWRWGL

[Uncle Buddy]

Since the full version of Sublime Text is available for free (and then you're supposed to pay for it voluntarily), I tried it, and liked it right from the start. It seemed just like Notepad++ but prettier and presumably it would work on Linux etc., while Notepad++ only works on Windows.

Once I started using Sublime Text, I found that it falls short compared to Notepad++, in several areas which I find indispensable, since having them in Notepad++ has gotten me spoiled.

It seems like most people like autofill suggestions, etc. Now here's a scenario for you. A youtube coding coach is typing along, showing you code you're supposed to be typing along with him. Suggestion tips keep popping up the whole time on the teacher's screen, covering the code you're supposed to be copying off the screen... Is everybody just blind to this annoying sludge?

I have no use for suggestions. Not because I already know what to type, but because I have to think about it, like to think about it, want to think about it. It's not a matter of being right, I just turn off the distracting balloons that pop up while I'm trying to type. At my age, training my memory is not about letting software do my thinking for me. Training my memory is a full-time job, and it's for me to do. I was able to get most of the suggestions turned off in Sublime Text, but not all of them yet, and not as easily as I'd been able to do it in Notepad++.

Sublime Text sort of has one of Notepad's best features: if I highlight the word "junk_food", all instances of this word will be highlighted. In Sublime Text, this sometimes works, but instead of highlighting (which is easy to see), a line is drawn around words (which is hard to see). Similarly, the Notepad++ feature which colors pairs of brackets bright yellow when the cursor is next to one bracket... sort of works in Sublime. A tiny, fine line which I have to search for with my eyes appears, but by the time I see it, well shucks folks, I could have just opened up Notepad, you know what I mean?

Game killer number one in my quest for a cross-platform, modern-looking text editor to replace the Notepad++ outdated Windowsesque appearance? A tiny sliver of a scrollbar. Even those fellas down at the Windows 10 design dept.--who are fairly inconsiderate toward the user's interests--know how to make a skinny little scrollbar get bigger when you point at it. You see, if I have several apps open, they aren't side by side, they're overlapping most of the way so I can see the one I'm working on. To make the editor active, I'd normally see nothing but its scrollbar, and if I click on that scrollbar's slider, the editor will come to the top and my scroll position will not change. Sublime's scrollbar is so godawful tiny that doing this hurts my hand and slows me down. It has been suggested that the minimap is there to click on, but that is wide so I don't want to leave it uncovered, and if I click on it anywhere, a scroll event will generally be triggered and then I'll be lost. Since I don't use minimaps, I tried to turn it off, but no success so far.

Game killer number two is just as bad. The slinky transition-hobbled tabs are truly a nuisance. The tabs are supposed to help me find my way, not help me lose it by being animated. When are GUI writers going to realize that just because you can do something doesn't mean you should. The tabs cover other tabs adjacent to them which therefore can't be read or clicked when several tabs are open. And when you resize the app smaller, the current tab is no longer visible so you don't know which tab you're on anymore. In fact, because of the designer's broken attempt to look sweet, in order for me to add the comment that "this feature is absolutely wretched", I had to first move other tabs out of the way when in fact the tab was positioned right in the middle of the screen already, once I got it uncovered.

But the most wretched aspect of this horrible feature is that tabs adjacent to the current tab are hidden from view. My habit is to keep the tabs I'm currently using next to each other. Can anybody guess why I don't want tabs adjacent to the active tab to be hidden? In Notepad++, if there are too many tabs to show them all, you just scroll them with the arrow buttons or use hot keys to traverse through the tabs. Sublime's fancy-schmancy fiddle-de-diddle hanky-panky looks pretty with its purposely slow-but-sure transitionally showing you what you want to see, but I didn't come here to gawk at cartoon features. Speaking of superfluous fiddle-faddle, when I point at a partially hidden tab with the mouse, I have to wait almost a second before a tooltip pops up to tell me the full name on the tab. If this slowness to transition was necessary, well all right, but since it's being done on purpose, I have to ask: is Sublime Text a work station or a GUI fashion show?

And another thing about those ludicrously feature-logged tabs. When moving a tab with the mouse, if you drop it outside of the app, which I do accidentally since I'm not a genius mouse athlete and my mouse hand hurts, it opens the file in a new instance of Sublime Text. Notepad ++ does something similar, and I hate them both for it. This sort of thing might be useful to you and you and you, in which case you should be able to turn it on. It should not be on by default.

Several handy commands that I take for granted in Notepad++ apparently don't exist in Sublime Text. The File menu is missing Rename, Send To Recycle Bin, and Save Copy As. The Edit file is missing Set Read-Only, a command in Notepad++ which saves my butt regularly. The Window menu item is missing entirely, so I can't look at a list of open tabs and just click the one I want, I have to go fishing among cartoonish tabs that slink around covering each other up according to some algorithm that's considerably more clever than I.

Before I bring this whinefest to a climax, I should mention that Sublime Text does have a macro recorder like Notepad++ does, unlike both Atom and VS Code. And finally, Sublime Text has the best Find frame of them all. Unlike Notepad's useful but obnoxious Find window, it's the same color as the rest of the app and not a separate window that's always getting in the way. And unlike the better but still icky versions in Atom and VS Code, the Find area extends all the way across the app so that it doesn't cover up parts of lines of code. But that's not enough to make me want to use it.

Sublime Text keeps bugging me to pay for it instead of bugging me for a report on why I don't plan to pay for it (or use it much longer). At this point, the only reason I'm still using it is so I can flesh out this review. But I think this is long enough. Sublime Text just made me appreciate Notepad++ that much more.