going old-school with emacs on raspbian

Here’s another one for the Raspbian Buster notebook. I spent a bit of time trying to install Microsoft’s Visual Studio Code by following these directions at https://pimylifeup.com/raspberry-pi-visual-studio-code/. After setting up all the dependencies, downloading the tarfile and pulling it apart, then attempting to run the script that would install and build everything else, the VS Code installation failed because the JavaScript engine ran out of heap space. Fine. I’ve used VS Code everywhere else, including Linux systems with only 4GB of memory, but I’ve never had a heap-space issue before now. To be truthful I like working with VS Code and all its various plugins. I would have tried to debug the blocker, but I decided to cut my losses then and there.

I got to the point of trying to install VS Code because I found myself thrashing about looking for a comfortable code editor and almost IDE. I say almost IDE because, after nearly two decades immersed in IDE development environments, I’d grown tired of it. VS Code was a nice step back. But it wasn’t going to happen on the Raspberry Pi 4 with Raspbian Buster. That’s when I turned back to VIM (VI Improved) and rather quickly got it into pretty good shape for my needs. But something still nagged at the back of my mind, and as good as Vim has become, it just wasn’t quite right. I then figure, what the hell. I’ll install and try Emacs again.

I was introduced to Emacs back in the early 1990s by an Emacs goddess. That is no exaggeration. She could code rings around all the other guys, and part of her prowess can be attributed to her mastery of Emacs. She showed me how much better Emacs was over vi and then set me up with some directions and  a beginning .emacs file. I learned how to edit with emacs and how to configure it to fit my tastes. It soon became my default editor, and I carried around my .emacs file from project to project. But a funny thing happened on the way into the 21st century. I got swept up into the bigger-is-better development tool environment and eventually forgot about Emacs.

Until today. It’s been so long since I’ve used it that I’ve had to open up a basic web-based user manual and started to build an .emacs from scratch. Fortunately for me Emacs has evolved considerably. The version I’m using now is a desktop client, and it’s menu support has allowed me to quickly get back up to speed again with regards to setting up a decent visual environment. All the very old muscle memory is coming back, and I think I understand part of my uncomfortable feeling with Vim; a lot of the key sequences are too close together. Being back in Emacs, everything just falls naturally back into place.

Emacs is not better than Vim, and Vim isn’t better than Emacs. But Emacs is best for me.

Advertisements

getting started with flutter on macos mojave, part 4 final

I’ve reached the end of the Flutter introduction, having produced an “app” that will supposedly work equally well on Android and iOS. Nothing out of the way to report, as part two of the exercise was clear and correct. I even went back and removed the code that produced the “Welcome to Flutter” header. Now the app is cleaner looking with only one header.

The good news is how so many different parts worked together to accomplish this: XCode (the Apple iPhone simulator), VS Code (Microsoft’s powerful open-source editor with plugins), and Flutter (Google’s development tools with additional support via Brew). If you dig a little deeper into how VS Code is built, you’ll see that it’s built on the Electron framework which is itself based on Node.js and Angular. So there’s a lot of integration of disparate languages and supporting tools into a non-trivial cohesive working whole. I’m suitably impressed.

Unfortunately for me, I couldn’t test how this looks on an Android device. I couldn’t get the Android emulator to work from the command line, even though I powered up Android Studio and used it to install SDK support for Android 9/Pie. Using Android Studio I also started the Android Virtual Device manager to create a Pixel 2 XL Android device to simulate, but unfortunately not the current top end, the Pixel 3 XL. This apparent lack of latest device support, along with the inability to launch the emulator from the command line (required if using VS Code to develop), almost makes the use of Flutter a pointless exercise, at least for me.

Yes, I was able to “develop” the app (or act as a code copying monkey from web page into the source code with the larger blocks of code). And it was interesting to see it run flawlessly on the iPhone XS Max emulator with the latest iOS version (12.1 as of 30 October). So there was that. I was also exposed to an alternative method for writing apps, which involved Javascript/Dart, so that was also a good thing. It really is good to try alternatives.

But being able to easily, seamlessly, develop for both Android and iOS on the same computer (running macOS in this case), that was a failure for me. And in order to do that kind of development you need to work on macOS, because you won’t run the Apple iPhone simulator on Windows 10. Or not that I’m aware of. And possibly solving the problem by developing within Android Studio instead of VS Code is a non-starter with me, unless I were being paid to do this, and then I would (might) begrudgingly switch. But on my own nickel, nope.

Prior Posts

getting started with flutter on macos mojave
getting started with flutter on macos mojave, part 2
getting started with flutter on macos mojave, part 3