Categories
Applications Coding Useful stuff

Unfashionably still an Atom editor fan

I’ve loved the idea of the Atom editor since I saw the initial announcement video three years ago:

I used it on and off as a text editor since it was released. Sure, it was sluggish, but I didn’t think too much of it. I used Atom for a text-based productivity system a couple years ago, when I couldn’t find a cross-platform task management system I liked. At some point, I decided to try something a little more responsive, and lightweight.

All the cool kids seem to be using Visual Studio Code, and they love it. There’s certainly a lot to like about Microsoft’s (mostly) open source code editor. It’s lightweight, extensible through a range of really good extensions, it’s cross-platform, and free.

I used it for a while, and enjoyed it. As a newbie coder, it gives me a lot of feedback as I poke around at my coding projects. This can be really helpful, for sure. That’s probably one of the reasons I used VS Code for as long as I did (and why I still have it installed on my laptop). Of course, another reason why I used it is that a number of developers I follow have raved about it.

I initially moved off VS Code, and returned to Atom earlier this year when I started using a more powerful MacBook Pro, and felt drawn back to Atom for some reason. Part of the reason was that a Markdown extension I relied on in VS Code stopped working for me (at least when I used it in conjunction with Alfred.app that I use heavily for my work).

When I came back to Atom, I noticed how well some of the packages I installed seemed to fit into how I worked. The Markdown Writer package, for one, has become one of my favourite packages, just because it makes it easier for me to write in Markdown.

There was certainly a point where I was concerned about Atom’s ongoing development, and how seemingly simple issues didn’t appear to be addressed. I received some good feedback on this, and moved on.

One of my colleagues recommended Sublime Text, so I spent some time testing it out. I love how quickly it starts up, how similar it is to Atom (well, more the other way round). At the same time, I’m not sure I can justify paying the cost for Sublime Text because Atom does want I want to do, with less of the fiddling I need to do to Sublime Text to configure it for how I like to work (mostly keybindings, and Markdown support).

It’s not that Sublime Text isn’t worth the $80 license fee, it really is (and I agree with paying for good quality software). Even though it took me a few weeks to configure it to work pretty well for me, there are little features that I absolutely love. One little one that I discovered is how it automatically closes HTML tags when I start typing closing tags. These little things are awesome, and bring a little more joy to my day.

In the meantime, Atom has been improving with each release. Sure, it doesn’t have all the tips and feedback that VS Code, and it loads a little slower (although not as much as it used to). I don’t mind that as much actually. I stick with Atom because it works for me.

It fits into how I write Markdown, works well enough for me when I switch over to CSS, HTML, Python, shell scripts, JavaScript, and so on. On those occasions when I need extra help, I may dip back into VS Code, or give Sublime Text another go.

I’m also just figuring out how to “hack” this “hackable text editor for the 21st Century”, and I really enjoy this sort of freedom with my text editor. There’s still so much I can learn about how to use my editor more effectively. Another colleague pointed out a really cool Emmet feature that just blew my mind.

So, in a time when everyone seems to be flocking to VS Code, I thought I’d add my vote for Atom. I’m still a fan, thanks GitHub!

unsplash-logoFeatured image by Luca Bravo
Categories
Applications Mindsets

VS Code has a little too much of the old Microsoft

Update (2018-09-18): I had this wrong. I was able to disable the Live Share and Azure extensions in VS Code. I just wasn’t paying close enough attention to the error messages I highlighted below.

You can disable the both the Azure and Live Share extensions by first disabling their dependencies. In the case of Live Share, I first had to disable the Live Share Audio extension. In the case of the Azure extension, I had to disable the Azure Functions extension first.


I like VS Code. That, in itself, still surprises me a little given which company created it. I still remember the Old Days when Microsoft took every opportunity to coerce users to use its solutions, often using pretty aggressive tactics.

Many have said that we’re dealing with a new Microsoft, friend to the FOSS community, trusted custodian of critical platforms like GitHub. That may well be true. At the same time, I still see a little of the old Microsoft seeping through now and then.

I opened VS Code today, to take a look at some code I’ve been meaning to continue working on. I noticed that Live Share updated when I open the app, and then seemed to start running for some reason.

I don’t use Live Share (although the functionality is interesting).

Rather than have extensions running that I don’t use, I thought I’d disable Live Share, along with the Azure extensions that seem to be installed and activated by default. That didn’t quite work out for me.

Can't uninstall or deactivate Live Share
Can’t uninstall or deactivate Live Share

I can't uninstall or deactivate VS Code's Azure extensions either.
I can’t uninstall or deactivate VS Code’s Azure extensions either.

As good as VS Code is, I don’t like being required to keep Microsoft’s extensions installed when I don’t make use of them. I’d expect that from an application that doesn’t hold itself out as “extensible and customizable”.

This just taints the progress the company has made, to a degree. It also leaves me wondering what else is running in VS Code when I use it, that I didn’t enable?