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

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 …

[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.

[Anonymous Coward]

Key collisions - forced decisions

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.

[Anonymous Coward]

Re: Key collisions - forced decisions

When developers start arguing over how many keys strokes to copy a line you know they haven't got any proper work to do.

The thing limiting your code isn't how fast you can type. If it was all you vi users would be touch typists. I know a lot of devs, I can't think of any others who can.

This isn't about speed or efficiency, it's about dinosaurs who won't move on, despite embracing the so-called enemy and using VSCode.

Spend more time thinking about your code, less time counting the fucking keystrokes.

[Brewster's Angle Grinder]

Re: Key collisions - forced decisions

" If it was all you vi users would be touch typists. I know a lot of devs, I can't think of any others who can."

Touch typing doesn't work for `(::x->*d)()` and the innumerable other squiggles languages insist on. It's also handicapped by dodgy autoinsert implementations.

[naive]

Re: Key collisions - forced decisions

Vi is actually pretty advanced, name one M$ product which:

- is not changing text on own because it think lines start with a capital letter

- doesn't interfere with file names because Bill Gates decided in 1978 text files should end with .TXT

- respects case

- can not be tricked into executing exploit code changing the kernel of your computer using special crated input files

- allows one to type type this

:1,$ s/12[a-b[A-Z]/1234/g

- Runs on anything from $25 set top TV boxes to the largest super computers in the world and even onwindows

[Falmari]

Re: Key collisions - forced decisions

I am not arguing and never really noticed how many key strokes were needed to copy a line and paste a second underneath. But reading the article made me think and I could not get it below 4 as the AC above pointed out.

I just do without thinking:-

shift-downarrow

Ctrl-c

Ctrl-v

Ctrl-v

It has become second nature to me.

If I have to use another editor then that has different key strokes I will just adapt.

[Anonymous Coward]

Re: Key collisions - forced decisions

But shift down arrow ^C doesn't do the same thing as yy, it would copy from the current cursor position on the current line to the corresponding position on the line below, whereas yy copies the whole of the current line. But you are thinking on the right lines rather than moving your hands off the keyboard all the way over to the mouse. Adding home to the front of your sequence works though.

Personally I found the adoption of the PC style keyboard slowed me down as the escape key had moved too far from the normal finger positions whereas an HP IFT family keyboard had escape just outside the life shift key where my little finger could easily reach it.

The thing about editors whether it's vi or any other is that generally once you know them your fingers just do the necessary without needing to think about it. Vi is a PITA to learn but great to use once you've learned the subset of its commands you actually use.

[Falmari]

Re: Key collisions - forced decisions

Yep you are right and it hit me after I had posted I would still need to get the cursor to the start of the line I wanted to copy. I just could not be bothered to edit and add the extra step and I just thought no one would notice, how wrong I was. :)

But that's the problem because it is second nature without actually having the editor in front of you, you just can't visualise all the steps. ;)

[Tom 38]

Re: Key collisions - forced decisions

My first day as a full time software engineer, my mentor sat me down and took me through the source code of the C++ web app we'd be developing. The rate at which code appeared, edited, refined, compiled, linted was out of this world. That's when I knew that being good at vim was necessary - first few weeks were hard, but you quickly get to grips with it.

Roughly 20 years later, I still do everything I can in vim. There are plugins for doing most everything I would want in an IDE, but without it actually being an IDE. If you take something like autocomplete, the much vaunted intellisense in VS code uses the same jedi engine as vim-jedi.

Its most likely not "dinosaurs who wont move on", we're still actually using vim, its probably people who've been forced to move to vscode because of some departmental standard and wanting to stay productive.

[John Riddoch]

Re: Key collisions - forced decisions

I don't think Vi (well, originally ex) was designed to specialize for coding. It was written in a time of scarce, expensive compute resources and dumb terminals wired by RS-232 cables. Minimising keypresses reduced the amount of data being transferred over the wire and being managed by the operating system so it became efficient as a by product. Mice weren't available much, if at all.

It's a steep learning curve and frankly I only got good at it because it was the only editor guaranteed to be available on Solaris, AIX and HP-UX on a base install. I still use it as my default editor on Linux despite other options being available out of familiarity and the fact I can do a bunch of common tasks on config files quickly with it (quicker than I could with e.g. notepad). Also, it's quicker for me to not have to switch between mouse & keyboard, just keeping my hands over the keyboard.

If you prefer another editor, great. For folks like myself who can be efficient with vi(m) and are familiar with it, it could well be faster than using a GUI based editor.

[sw guy]

Re: Key collisions - forced decisions

I remember reading that when Bill Joy developed vi he was often connected to computer by a 1200 baud modem. This convinced him to find a way to minimize bytes flows in the 2 directions, with curses library as a consequence.

[Tom 7]

Re: Key collisions - forced decisions

If the keyboard does everything then a good set of well chosen short cut commands is far far faster than a combination of keyboard and mouse. So long as ALL commands are at your fingertips then with a little practice you get exactly what you ask for whereas a mouse, even a pixel off, will wreak havoc with your menus or command choices, as will returning to the keyboard from the mouse.

But unless you have had the fortune to start before the mouse became ubiquitous its unlikely you will believe this and spend the time (and we're talking weeks not days) of sitting down with an editor and beating it into submission.

If you get a chance though, ditch the mouse and in around about a month using the same editor for pretty much everything you'll start to notice a noticeable increase in fluidity and production.

[yetanotheraoc]

Re: Key collisions - forced decisions

"If the keyboard does everything then a good set of well chosen short cut commands is far far faster than a combination of keyboard and mouse."

Exactly. That's why developers so thoughtfully make sure some functions are *only* possible with the mouse. Otherwise the keyboard buffer might overflow and the beeping will wake the neighbors! Just the other day I was reading a help manual "how to" and "the way" was Ctrl+MouseScroll. Um, great, but I have only a keyboard and a trackball....

[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.

[Anonymous Coward]

+1

> 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.

[J.G.Harston]

Re: +1

Function keys at the top of the keyboard keeps the keyboard a sensible size, allows access from both hands, and allows you to place a function key strip above/below them.

[Brewster's Angle Grinder]

Yes, I grew up on an 84-key keyboard

The arrow keys, page up, page down, etc... are all their on the numeric keypad. You don't need them - unless some app insists on being pissy. (RESPECT THE NUMLOCK!) Get rid of them and there is space for the function keys down the side where the left hand can curl over. But, to be honest, I wouldn't care even if my keyboard was wider still.

[James Wilson]

Ctrl-d. I have the 'Duplicate selection or line' extension installed.

[roeltz]

Finally, someone that knows their own editor shortcut keys and doesn't let those marginally-more-efficient-examples-of-typing-as-proof-of-superiority go unscathed.

I have always thought the vi people were pretty smug about their single key commands, but actually, in day-to-day usage, no other productivity app have the same command key bindings, so all that muscle memory and "efficiency" is lost after pressing Alt+Tab.

[Anonymous Coward]

Makefiles - Luxury!

40 years ago we had to type the build commands in by hand and pay th' Mill Owner for the privilege.

[AndyJF]

Re: Makefiles - Luxury!

"Type"?! You had a keyboard? Luxury. We had to toggle the O/S in on the front panel.

[Stuart Castle]

Re: Makefiles - Luxury!

"Front Panel"? Luxury. We had to hard wire the O/S into the memory chips, and pay t' computer owner for t' privilege.

[adam 40]

Re: Makefiles - Luxury!

Your memory were on chips? Luuuxureh! Ours were mercury delay lines, and if we were lookey t'mill owner would let us sip a bit for us tea....

[Fruit and Nutcase]

Creator/Destructor

Bill Joy

not to be confused with Bill DeJoy

[JohnnyL]

Make Love!

Oh the joy for a 'wet behind the ears' programmer to enter "make love" and get the response "Don't know how to make love". How apt for a teenage boy, modern AI take note.

[Tony Gathercole ...]

Re: Make Love!

Somebody else must remember TOPS-10's response to entering "make love"?

Not war?

(mind you "make" only used to invoke TECO to create a file in those days!)

[katrinab]

Re: Make Love!

FreeBSD:

katrina@teto:~ % make love

make: don't know how to make love. Stop

make: stopped in /usr/home/katrina

Big Sur:

katrina@lily ~ % make love

make: *** No rule to make target 'love'. Stop.

Debian:

katrina@kaai:~$ make love

make: *** No rule to make target 'love'. Stop.

Windows 10:

PS C:\Users\katrina> make love

make : The term 'make' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

At line:1 char:1

+ make love

+ ~~~~

+ CategoryInfo : ObjectNotFound: (make:String) [], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

[Fruit and Nutcase]

Re: Make Love!

@katrinab

Call me

[yetanotheraoc]

Re: Make Love!

I *wanted* to upvote you. Does that make me a bad person?

[adam 40]

yyp - waste of a keystroke!

I use Yp

I've been using vi for so long it's hard-wired into my brain.

:w!q

[AJ MacLeod]

Re: yyp - waste of a keystroke!

Does the shift keystroke not count then? (Actually I didn't know that Y also yanked, despite having used vi in many variants for several decades)

[adam 40]

Re: yyp - waste of a keystroke!

No because it happens at the same time, whereas yy is definitely two strokes taking longer.

Just goes to show - you're never to old enough to learn a vi trick!

I miss <ctrl>space support, which seems to have been dropped in later versions.

[DevOpsTimothyC]

Re: yyp - waste of a keystroke!

:x

[Michael Wojcik]

Re: yyp - waste of a keystroke!

Or ZZ, which for some people is a little quicker to touch-type. (On a US-QWERTY keyboard, touch-typing :x is left-shift with left hand, colon with right hand, release left-shift, x with left hand, Enter with right hand. ZZ is just right-shift with right hand, z twice with left; it's a command-mode command so it takes effect immediately and doesn't need the Enter.)

In vim, with multiple changed buffers, :xa to exit all, saving changed ones. To discard all buffers, :qa!.

[Anonymous Coward]

Re: yyp - waste of a keystroke!

I've been using vi for decades, on account of not being able to find the exit.

[Anonymous Coward]

Re: yyp - waste of a keystroke!

Y seems to be inconsistent between vi and vim then.

In earlier vi editions Y yanked from here to the end of the line, in the same way that D deletes from here to the end of the line.

Now in vim D & Y operate of different sets of data.

Hmmm weird.

[Elledan]

Darn ageisms

The quality of a tool shouldn't have anything to do with its quality. Just because screwdrivers and hammers have been around for hundreds of years doesn't mean that they're obsolete now.

I use hand-written Makefiles, because they do everything, whether it's a quick compile job or a complex cross-platform build system with the minimal amount of fuss. Yes, I had to go through a bit of a learning curve, but mostly due to the lack of solid n00b guides.

Main advantage for me is that I can use the same Makefiles across Windows (MSYS2), Linux, BSD, MacOS, QNX, VxWorks and others without problems, as Make is supported for all platforms, including toasters. Meanwhile other build systems and build system generators like autobreak^Wautoconfig and CMake have given me mostly grief, whether for complex commercial projects or just trying to compile a random OSS project.

[GrumpenKraut]

Re: Darn ageisms

> I use hand-written Makefiles...

Same here, together with little scripts for checking, testing, packaging, and whatnot. Everything completely under my control, everything _exactly_ how I want it.

[adam 40]

sOMETIMES i jUST uSE vi BECAUSE i LEFT CAPLOCK ON

Ahh that's better - you know you've just typed in a sentence without looking, paste it into vi and

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Job's a good'un!

[Michael Wojcik]

Next week, Microsoft announces a panini maker for your car

Yes, that's what I want. VS Code will be just like my current toolset, except with more bloat and a large public repository of unsigned and completely untrustworthy extensions, and with "integrated" tools instead of all the power of bash and the command-line utilities. Tempting!

As some others have suggested, I wouldn't in general recommend developers learn vi or vim. The requirements it was designed to satisfy apply much more rarely in today's industry than they did in the late 70's. But I've been using it for decades, and I know it very well, and I can't see any compelling or even particularly interesting reason to switch. Particularly not to an imitation that doesn't offer anything additional that interests me.