1

Let's say that I have the following node.js script:

console.log("test")

If I use the command :set makeprg=node\ % | set autowrite | make I'll execute this node.js code and see the following result:

test

Press ENTER or type command to continue

From now on, if I type :make I'll execute my node.js file from inside Vim. So far everything is fine... The problem begins when I have a mistake on my code, let's say my node.js file has the following content:

console.log("test")
fklsjfj

Well, fklsjfj is not a valid javascript command, so the execution of the file should break after reaching that line and printing what happened until there. However, when I try to execute this file from inside Vim I'll see the error message and end up on an empty screen, so the only way to go back to the file is closing it with :q! and opening it again. Why does this happen? Is there any way of going back to editing my file after executing a node.js code that contains an error?

6
  • I don't know if using make to execute your script is an ideal approach. Can't you run it with :!.... ?
    – B Layer
    Jun 18, 2021 at 20:22
  • @BLayer Ah yeah, you're right... I think I was overcomplicating the problem. Just using :! node % solved the issue for me. :)
    – raylight
    Jun 18, 2021 at 20:30
  • Good to hear! :)
    – B Layer
    Jun 18, 2021 at 20:32
  • 1
    Try <C-l> or :redraw[!]?
    – D. Ben Knoble
    Jun 18, 2021 at 21:03
  • @D.BenKnoble After using :make none of those commands are working too :/... The screen gets empty and I don't manage to go back to the file even if I try :ls and :e myfile... However, :! node % solved this issue already, it just shows the execution output and goes back to my file regardless if there are errors or not.
    – raylight
    Jun 18, 2021 at 21:07

1 Answer 1

1

The problem you're having is that when you run :make and it fails, Vim tries to parse the output according to the 'errorformat' setting.

The output for the script with the syntax error looks something like this:

test
/path/to/script.js:2
fklsjfj
^

ReferenceError: fklsjfj is not defined
    at Object.<anonymous> (/path/to/script.js:2:1)

But the default 'errorformat' setting (mostly aimed at C compilers such as gcc) parses that output and thinks the error happened in a file named "at Object.<anonymous> (/path/to/script.js. It tries to open that file, which doesn't actually exist, so it puts you in a new Vim buffer with that filename, and that's why it looks like you "lost" the file you're editing.

You can see that you're in a new buffer using the :ls command:

:ls
  1 #    "script.js"                         line 2
  2 %a   "at Object.<anonymous> (/path/to/script.js" line 1

The buffer with the % flag is the current buffer, while the buffer with the # flag is your original script.

You can go back to your script with :e#, possibly followed by :bd# to delete the bogus buffer (you don't really need to, but you might as well.)

A more proper and permanent solution to this problem would be to set 'errorformat' appropriately, so that when you're using node % as a 'makeprg' to run your JavaScript code and there's an error, it will properly parse the output format of the output to correctly populate the quickfix list with the errors and move you to the actual file (and line) from where the first error happened.

You can find a Vim plug-in that sets that up in felixge/vim-nodejs-errorformat, which you can configure using vim-plug or native Vim packages or whatever other Vim plug-in manager you're using. Note that this plug-in will also already set up 'makeprg' to run 'node %', so it takes care of that part as well.

Note that the script will set up this particular 'makeprg' and 'errorformat' for every JavaScript file you open in Vim (any file detected as filetype javascript), which might not be the best approach overall... (Other plug-ins will typically configure :make to run something like eslint or use the npm package definition in a JavaScript/NodeJS project.) But perhaps this setup suits your use case well and might be what you're looking for.

9
  • I’m not sure this is the issue: see the comment after my redraw suggestion.
    – D. Ben Knoble
    Jun 18, 2021 at 22:03
  • @Ben I reproduced it locally and that's what I saw... It looks puzzling (without a statusline) but I was editing a file with a garbled name like that. :ls confirmed it and :e# got me back to my script.
    – filbranden
    Jun 18, 2021 at 22:12
  • I didn't really try the plug-in first-hand, but if it does what it claims (README is pretty detailed, with example) then I assume it would fix that exact issue.
    – filbranden
    Jun 18, 2021 at 22:13
  • 1
    Re: the plugin, Aside from the autocommand to finangle certain quickfix results (which is installed globally? yuck), the whole thing could have been a :compiler script
    – D. Ben Knoble
    Jun 18, 2021 at 22:22
  • 1
    My mistake, I did some experiments here and my comment about trying :e myfile was actually wrong... What I really tried was :e number like in :e 1. That was wrong, the way of moving around files from their numbers id is :b number. So using both :e myfile or :b 1 worked fine to going back to the original file...
    – raylight
    Jun 19, 2021 at 19:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.