News: 1613678711

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

VS Code acknowledges its elders: Makefile projects get an official extension – and VIM mode is on the backlog

(2021/02/18)


Makefile projects, widely used in open source development, are getting an official Microsoft extension in Visual Studio Code (VS Code), and a request for built-in VIM support is on the official backlog.

Makefiles are text files containing instructions for make, a build automation tool originally written by Stuart Feldman at Bell Labs in 1976 but rewritten many times since.

[1]

Building C or C++ projects with Make is old school, and makefiles seem arcane at first but they have advantages. “We chose make, and you should too, over other agnostic build tools because of its rather simple language and its ubiquitous availability,” [2]said Trivago software engineer Simon Bruggen, for example.

Makefiles are part of the magic behind the three commands every Linux tinkerer knows - ./configure, make, make install – and still widely used in open source projects.

[3]

This being the case, Microsoft has created a new [4]VSCode extension for makefile support, now in preview. The extension gives developers shortcuts for make commands, and the ability to set a script to preconfigure terminal operations before running make. Microsoft has provided configurations for around 70 projects including ffmpeg, git, Mono, Node, PHP, PostgresSQL and also for make itself.

Make is not difficult to use from the VS Code terminal with or without this extension but the fact that Microsoft has chosen to do this shows the continuing importance of this 40 year old utility.

Some might imagine that VS Code is a welcome alternative to vi, a command line editor for Unix which is approximately the same age as make, first written by Bill Joy in “probably 1976” according to this [5]archived interview . Vim, or Vi IMproved, dates from the nineties and typing vi in a Unix-like operating system will normally bring it up. Ubiquity is an asset, so too is the power of its modal interface.

“Suddenly you realize you want to copy the current line and paste it directly below the first. How do you do this? Tell me your process step by step, and let’s count the keystrokes it takes to accomplish this,” [6]wrote developer Luke Maciak back in 2012, challenging the reader to beat vim’s three (y y p). Maciak also noted that “it is not what you would call a user-friendly piece of software”, but once its keystrokes are familiar, it is highly efficient. Modality, which distinguishes between commands and text entry, is a sensible way to control an editor.

There are, therefore, plenty of developers who would like VS Code to be more like vim, one of whom opened this [7]feature request for “VIM mode like Sublime” (Sublime being another popular code editor). It soon won over 800 upvotes and has been automatically added to the Visual Studio code backlog. This does not guarantee that it will be implemented. “If and when a Backlog item is scheduled for a concrete iteration depends on how well the issue aligns with our Roadmap”, the team wrote in its [8]guide to issues triaging.

There are also objections: VIM extensions already exist, and “I'd rather have a lean and mean VSCode that I can extend as necessary than a monolithic one that has tons of features I'll never use,” [9]said another user.

The problem though is that implementing vim keystrokes as an extension has performance issues that can impact VS Code and its other extensions. “If I turn vim plugin on (all other plugins off), vscode starts to lag,” [10]wrote says a user. There is an architectural issue, in that VS Code is carefully designed to keep extensions somewhat isolated. “We decided to run extensions in a separate process so that the VS Code core is less impacted by extensions,” [11]said VS Code inventor Erich Gamma recently. This is generally a good thing, but it is sub-optimal for an extension like hooks into every keystroke, particularly if it is competing with other extensions. It does not look like there will be an easy solution.

Not everything in the VS Code world is retro. Microsoft program Manager Jeffrey Mew has [12]posted about Python improvements in the February update, including integration with [13]TensorBoard for visualising machine learning models, improved readability for docstrings (documentation embedded into Python code), and streamlined code navigation for “go to definition”, and “go to declaration.”

[14]

VS Code has huge number of open issues, more than 4,400. Every developer wants a favourite feature added, but none of them wants a bloated or slow editor as a result. The problems with vim mode illustrate how challenging that can be. ®

Get our [15]Tech Resources



[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YC7xhyFSv60KSe7bkHywTQAAANg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[2] https://tech.trivago.com/2019/12/20/makefiles-in-2019-why-they-still-matter/

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YC7xhyFSv60KSe7bkHywTQAAANg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[4] https://devblogs.microsoft.com/cppblog/now-announcing-makefile-support-in-visual-studio-code/

[5] https://web.archive.org/web/20120210184000/http://web.cecs.pdx.edu/~kirkenda/joy84.html

[6] http://www.terminally-incoherent.com/blog/2012/03/21/why-vim/

[7] https://github.com/microsoft/vscode/issues/114851

[8] https://github.com/microsoft/vscode/wiki/Issues-Triaging

[9] https://github.com/microsoft/vscode/issues/114851#issuecomment-780162510

[10] https://github.com/VSCodeVim/Vim/issues/2021

[11] https://www.theregister.com/2021/01/28/erich_gamma_on_vs_code/

[12] https://devblogs.microsoft.com/python/python-in-visual-studio-code-february-2021-release/

[13] https://www.tensorflow.org/tensorboard

[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YC7xhyFSv60KSe7bkHywTQAAANg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[15] https://whitepapers.theregister.com/

matthewdjb

Copy line to the next? Select, Ctrl-c,ctrl-v.

People are used to what they're used to. Sometimes what they're used to is slower compared to modern applications. But having used vi(m) for years, I doubt it's really more effective than modern editors.

Anyway, as a developer, I spend more time thinking than I do typing.

Really smart syntax checking in the editor. That's what I want.

Key collisions - forced decisions

Anonymous Coward

You forgot to mention the details. That 'select' - how'd you do it? Mouse? shift-downarrow? something else? "Ctrl-c, ctrl-v" - congratulations you just replaced your line with the same line.

Vim/vi (so when does Bram get a name check?) is an editor, specialized for that like other editors. If it seems too different to you, maybe it's because you take for granted that mice must be used? The shortcut example I use is " x p " - reverse two mistyped characters.

As a developer, I spend much time trying out alternative formulations of code, seeking clarity for self and others. An editor mismatched with the task of editing is wrong.

VSCode uses the same mode (keyboard space?) for everything, and keyboard usage collisions resulting in decisions of "too hard to do" may be forced upon them? VSCode shows its compromises too vividly.

Smart syntax checking? Love it. So I pause every so often while editing and check what VSCode has to say, by switching to that window. Love having that additional tool for that.

Brewster's Angle Grinder

Actually, it's Alt+2 in my editor, and has been since at least the 90s, because duplicating the current line is such a useful feature.

One of the things I still lament is the decision to move function keys to the top of the keyboard, rather than keeping them down the left hand side. Up there, they're out of easy reach and that restricts them to less frequent bindings.

+1

Anonymous Coward

> One of the things I still lament is the decision to move function keys to the top of the keyboard, rather than keeping them down the left hand side.

Respect.

"I am getting pretty good at running diff and patch now"

- Jeff Merkey