Run plugin

[qrmoon]

• You can either press f5 or use the run:run-doc command
• I have only tested it on Windows
• New languages/compilers/interpreters can be added like this:

local config = require "core.config"
local run = require "plugins.run"

-- add system command command for the go language
config.run.go = "go run %s"
-- for file matching this format use the go language
config.run_files["%.go$"] = run.lang "go"

-- use tcc instead of gcc
config.run.c = "tcc -run %s"

You can also add, for example, love2d support to your project module

local config = require "core.config"
local run = require "plugins.run"

config.run.love2d = "love ."
config.run_files["%.lua$"] = run.lang "love2d"
-- you can also do this instead:
config.run_files["^main.lua$"] = run.lang "love2d"
-- main.lua would have to be the active doc, useful if you have some plain lua scripts in your project

[qrmoon]

I have restructured the plugin a bit
You can now register love2d as a custom command and add a shortuct for it if you want to

local config = require "core.config"
local run = require "plugins.run"
local command = require "core.command"
local keymap = require "core.keymap"

config.run.love2d = "love ."
command.add(nil, {
  ["run:love2d"] = run.lang "love2d",
})

keymap.add {
  ["shift+f5"] = "run:love2d",
}

[rxi]

Have you seen the console plugin? I get the impression it may already solve the issue your plugin is trying to solve

[qrmoon]

Yes, I have used it, but I couldn't get it to work with infinite loops in my scripts, it didn't allow me to get user input, etc., so I've decided to use the native terminal and made this little plugin

[SwissalpS]

I do see a niche usage for this idea. Sometimes I do work on standalone scripts that I don't have a project hook for.
Plugins eval and exec work on selected text and are pretty obviously detectable to what they do.
Your proposal does seem like it could fit into console plugin.

lite would require sockets in C-portion of code to enable a host of similar usages like this one where communication between a running application and lite is required.
Bare minimum FIFO file-socket support would give lite even greater extendibility. Something like this would also be nice to have: SDL2 based TCP socket bridge.

May I suggest naming this plugin something like runinterminal, to be more descriptive, if it should be accepted as independent plugin?

[qrmoon]

@SwissalpS good idea, I have renamed the plugin name to runinterminal as you suggested

[Anachron]

This is hard-coding the gnome terminal on non-windows systems. I suggest to use an env-variable and default to gnome-terminal if not set.

[qrmoon]

I looked into it, although I am using a non-standard variable $TERMINAL, because $TERM often returns names that are not valid command names
And I have replaced gnome-terminal with xterm as it is installed on more machines and is generally more popular

[qrmoon]

I have also added a run.build method, which is same as run.lang except that it doesn't use the current doc's name and can be used when no file is open at all

[SwissalpS]

@Qermon did you forget to switch branch? :D

[qrmoon]

Thankfully not, just resolving conflicts with rxi:master

[SwissalpS]

Oh, sorry. I now see what happened :)

[SwissalpS]

why not use a config setting for this? I use termit mostly and would change that and other arguments for my usage case.
Pretty sure there are others who have a favourite terminal that is not setup as xterm/gnome-terminal override.

[qrmoon]

You can actually change it by putting something like config.run_cmd = 'some-terminal -some_arg "%s"' in your config module file, where %s will be replaced by the command assigned to a given language or build, for example editing hello.py will result in some-terminal -some_arg "python hello.py" being run.
The default command (and arguments) is there if a user doesn't set their own.

[Anachron]

But if the default can already respect the user command in a non-breaking way, why should we force them?

[qrmoon]

Well, I've realized that $TERMINAL is not as viable an option as I initially thought, because many terminals use different arguments to accomplish the task, so it often breaks anyway.
I think it's better to just have the user set both their terminal and arguments or stick to xterm (and it's default args).