Sometimes one needs to say things one never imagined one would say:
Thank you Microsoft for the code editor I am using under Linux!
Yes, all these words in the same sentence! Microsoft in the past years started and released a wonderful code editor, the name is Visual Studio Code. The naming was a bit annoying at first because we have Visual Studio which is a totally different software, but I suppose that on the long run they want the name Visual Studio to be associated with everything they do for the developers more than a specific software.
But what brought me to use some Microsoft software under Linux? Simple productivity. My goal is to always be extremely productive and I am always, on a regular basis, evaluating the different tools to assess if they can provide after the associated learning curve a net benefit for me and my customers. I am paid by the hour in my work and I try to have such highly efficient hours that my customers never complain about the bill (never had one complain in 10 years, keep crossing my fingers).
So, after a bit of wondering, I decided to test Visual Studio Code even so it has at first sight some issues:
- It consumes a lot of resources, from 30MB for my Emacs session to more than 400MB for the same code.
- It is written by Microsoft, which is not known to support Linux user very well.
But productivity is more important than 500MB RAM on my system which anyway is equipped with 16GB, Microsoft is supposed to have solve the latency issue of the rendering of the text editor to end-up with something nice and it is always better not to be dogmatic and look what the other side is doing (and Visual Studio has long been a wonderful piece of software).
All things said, I decided to try it and after a bit of adjustment here is the view of the beast when I am working on some Fortran code:
You have basically everything you need:
- nice syntax highlighting with the fortran extension;
- intellisense with the fortran language server;
- git integration;
- debugger integration;
- and much more because you can easily have many different languages in the same workspace.
Ease of Extension
Microsoft is really showing its expertise at developing developer software with it and also their fresh look at what others have been doing for a long time, that is, the concept of extensions pioneered by Mozilla for Firefox.
This is because all the power of Visual Studio Code is coming from a very well though system of extensions. With a couple of key strokes, you can install and use a large number of extensions. You an extension for everything you may need.
They also pushed ahead the Language Server Protocol (LSP) to integrate all the IntelliSense functionalities of any kind of software into the editor. The LSP is an open standard and it is relatively easy to develop a server. Because the servers providing the language support are independent of the editor, they can be used by any software (yes, Emacs/Vim too).
The extension for the syntax highlighting is always pretty simple and I was able to fix the support of comments in fixed format mode.
All that within a week of using the software...
But Still Place for Improvements
Navigation Within a File
I am still missing some of the great navigation control of Emacs as VS code is using
a lot the arrow keys to navigate. I do prefer the
Ctrl + key approach from Emacs
and I have already added some custom keybindings to help me. This is still a work in
The reason why prefer the navigation using
Ctrl + key is because I need to move my
hands to access the arrow keys on my Typematrix 2030.
I can already feel that I am using a bit too much the mouse because of the non
Fixed Format Fortran (Punchcard)
The good old fixed format Fortran is still a big part of my codebase, this is why I need a good support. What I am missing from Emacs is the really good automatic indentation, ease of line breaking with continuation character and automatic change of color of the code after the column 72. I have a partial alternative with some user settings to set a rulers at different columns and force tabs as 3 space characters:
The current Fortran extension working with the language server is not as good as the modern Fortran extension. But the language server is a need to have all the great contextual help. So, I will need to see if I can get the language server to be supported in this better extension.
For the moment, my conclusion is simple: I really like it and it is really improving my efficiency at work, this is why I really recommend you to try it!
To solve the missing continuation line command, using the macros extension, I created the following macro (defined in my
"text": " $"
And then in my
keybindings.json I added:
"when": "editorTextFocus && editorLangId == 'fortran_fixed-form'"
this enables the binding only for the
fortran_fixed-form language. This is the
language id of the fixed format Fortran from the modern Fortran
To use the modern Fortran together with the Fortran Language Server,
I had to patch the LS glue extension and the
modern Fortran extension.
The two changes are basically just to ensure that the extensions are enabled at the same
time. In my
settings.json I changed the key
For the navigation, the emacs key bindings extensions were not convincing. I will need to explore a bit more the different options, especially the ability to have key bindings enabled only within different contexts.
- Am currently trying an improved Emacs extension which is working pretty well. We will see how it goes over the long run.
- I created a fork of the language server including a series of fixes, you can
masterbranch to have all the fixes already applied:
- I still have to fork the corresponding VSCode extensions to nicely package the patches I made and allow integration.