Skip to content

Vim: Add a RustRun function to run the current buffer contents #7787

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

dotdash
Copy link
Contributor

@dotdash dotdash commented Jul 14, 2013

This allows to run the contents of a buffer through "rust run" and show
the results in a scratch buffer. Handy for things that are just a bit
too big to be done comfortably in rusti.

Refs #7747

This allows to run the contents of a buffer through "rust run" and show
the results in a scratch buffer. Handy for things that are just a bit
too big to be done comfortably in rusti.

Refs rust-lang#7747
@chris-morgan
Copy link
Member

Certainly a good idea, but I'm not really happy with this in its current form.

  • I'd like it to work on saved files, too, with their proper names, only going via stdin if &modified.

  • This leaves behind in the working directory a binary stdin~; it should be removed (I don't understand why rust run leaves it around, to be frank)

  • /dev/stdin isn't cross-platform. It should be using - which rust run... supports in concept as "stdin", but breaks on in linking. TODO: file bug about that (going to bed now). We're probably best to bypass rust run and invoke rustc and the resulting file directly: You could do something along the lines of:

    let s:tempname = tempname()
    exec "!rustc - -o " . s:tempname
    exec "%!" . s:tempname
    unlet s:tempname
    

    Actually, on second thoughts, tempname() might not be such a good idea—the working directory will still be right, but the binary directory wouldn't be, which could potentially cause trouble for some code. Could go for a name like ./.vim-rust-run-binary, I guess. Oh, and on Windows it'll need to end in .exe.

  • It'd be kinda nifty if it tied into the rustc compiler (which would need some modification to fit with it, to support a -o X option at least), so that you'd replace the :!rustc step with :make, with the effect that compile errors would be handled normally. (Danger there: it would at present then try to show you the errors in a buffer with the filename <anon>. I guess adding another set of errorformat lines before the others with the hardcoded would more or less fix that up, though if you use other files it would still get hairy.)

What do you think?

@emberian
Copy link
Member

emberian commented Aug 7, 2013

@chris-morgan @dotdash any update on this? it has been languishing in the queue for a while. I'm happy to just rubber stamp it, but the concerns are valid.

@dotdash
Copy link
Contributor Author

dotdash commented Aug 7, 2013

I'll probably not get around to fix this any time soon. I'll be happy if anyone picks this up, but would not like to see it merged as is, especially, but not only, because of the annoying stdin~ executable it currently leaves behind, which I initially had no idea where it was coming from.

@catamorphism
Copy link
Contributor

I'm going to close this; if anyone wants to fix it, they can reopen it or submit a new PR :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants