Pass ++term to :make or :lmake to run it in a terminal in a new tab. The quickfix/location list will be populated when the command is finished, autocmds triggered, and first error jumped to if specified. It is partially implemented in C and the rest in Vimscript.
https://github.com/vim/vim/pull/18188
(4 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@zeertzjq commented on this pull request.
> @@ -956,6 +963,11 @@ option. This works almost like typing
":!{makeprg} [arguments] {shellpipe} {errorfile}".
+Note that this is different when using the ++term argument. Instead it will
+work similar to typing:
+
+ ":tabnew | term_start({makeprg}, {"curwin": 1})"
⬇️ Suggested change
- ":tabnew | term_start({makeprg}, {"curwin": 1})"
+ ":tabnew | call term_start({makeprg}, {"curwin": 1})"
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
> @@ -985,6 +997,13 @@ on the screen and saved in a file the same time. Depending on the shell used
If 'shellpipe' is empty, the {errorfile} part will be omitted. This is useful
for compilers that write to an errorfile themselves (e.g., Manx's Amiga C).
+For how the ++term argument works internally, it creates the tab page and
+terminal directly, and then sets the exit_cb callback of the terminal job to a
+Vimscript function called "PopulateQuickFixList" defined in
⬇️ Suggested change
-Vimscript function called "PopulateQuickFixList" defined in +Vim script function called "PopulateQuickFixList" defined in
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@zeertzjq commented on this pull request.
In src/testdir/test_quickfix.vim:
> @@ -6958,4 +6960,52 @@ func Test_vimgrep_dummy_buffer_keep() %bw! endfunc +" Test if ++term argument works properly for :make or :lmake +func Test_make_ppterm_argument()⬇️ Suggested change
-func Test_make_ppterm_argument() +func Test_make_ppterm_argument() + CheckFeature terminal
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
g:vim_terminal_make_command? Maybe internal variable would be a better fit? v:terminal_make_command?:term wherever it would be opened. Or :botright term ...—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
- can we not use
g:vim_terminal_make_command? Maybe internal variable would be a better fit?v:terminal_make_command?
Yeah that sounds better
- Is there a particular reason to do it in the new tab? I would prefer to have it in the regular
:termwherever it would be opened. Or:botright term ...
Any ideas how the user would configure that?
Maybe users wanting more advanced stuff could use that plugin. I think this should just be a simple way to run :make in the background. Maybe the user can configure if the terminal should automatically be opened or not?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Any ideas how the user would configure that?
What if :make would be able to accept :tab make ++term, :botright make ++term, etc?
Thus by default :make ++term opens terminal where :term would have opened it.
Maybe users wanting more advanced stuff could use that plugin. I think this should just be a simple way to run
:makein the background. Maybe the user can configure if the terminal should automatically be opened or not?
I would just create the setting for make, e.g. set makeprgbackground=terminal and expect :make to run in background with terminal or set makeprgbackground=job to do the same without terminal.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Any ideas how the user would configure that?
What if
:makewould be able to accept:tab make ++term,:botright make ++term, etc? Thus by default:make ++termopens terminal where:termwould have opened it.
Oh thats actually really nice, I will try implementating that
Maybe users wanting more advanced stuff could use that plugin. I think this should just be a simple way to run
:makein the background. Maybe the user can configure if the terminal should automatically be opened or not?
I would just create the setting for
make, e.g.set makeprgbackground=terminaland expect:maketo run in background with terminal orset makeprgbackground=jobto do the same without terminal.
Sounds good
Thanks for the tips, I'll make this a draft for now
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@yegappan commented on this pull request.
In src/quickfix.c:
> + if (argvar[0].vval.v_string == NULL) + return FAIL; + + sprintf((char *)argvar[0].vval.v_string, "%s %s %s", p_sh, p_shcf, cmd); + argvar[1].v_type = VAR_UNKNOWN; +#endif + + if (win_new_tabpage(0) == FAIL) + goto fail; + + init_job_options(&opt); + + // Create callback to populate location/quickfix list when make command is + // done. + cb_tv.v_type = VAR_STRING; + cb_tv.vval.v_string = (char_u *)"PopulateQuickFixList";
Instead of splitting the terminal creation logic between the C code and the quickfix population in Vimscript, would it make sense to move the entire implementation to Vimscript and invoke the function directly?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@yegappan commented on this pull request.
In src/quickfix.c:
> + if (argvar[0].vval.v_string == NULL) + return FAIL; + + sprintf((char *)argvar[0].vval.v_string, "%s %s %s", p_sh, p_shcf, cmd); + argvar[1].v_type = VAR_UNKNOWN; +#endif + + if (win_new_tabpage(0) == FAIL) + goto fail; + + init_job_options(&opt); + + // Create callback to populate location/quickfix list when make command is + // done. + cb_tv.v_type = VAR_STRING; + cb_tv.vval.v_string = (char_u *)"PopulateQuickFixList";
I see in your later comment that you are planning to move the entire logic to the C code. That also makes sense.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@habamax Can you check if it looks good? :botright, :tab, ... should work, and the :make command supports ++hidden, ++rows, ++cols just like the :terminal command.
Quickfix/location list is only generated when the make command is done, I tried having it appended to as the make command runs. Though I found that using the channel callback gives raw messages, meaning colour codes/any escape codes would appear in the quickfix window, not sure how to handle that.
Thanks,
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@habamax Can you check if it looks good?
:botright, :tab, ...should work, and the :make command supports++hidden, ++rows, ++colsjust like the :terminal command.
When you do :tab make ++term a new tab appears and if there is an error it jumps to the first error replacing terminal tab. Not sure if this is intended? Same for a regular split.
https://asciinema.org/a/4heU2snrwnlDjlq2cwRrGkdhu
Otherwise, looks good to me.
PS: It would be nice to not write :make ++term, hopefully you going to have it eventually with smth like set make=terminal/set make=job option.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
When you do
:tab make ++terma new tab appears and if there is an error it jumps to the first error replacing terminal tab. Not sure if this is intended? Same for a regular split.
That also applies to the regular :make, you just have to pass a shebang [!]]. In the docs:
7. If [!] is not given the first error is jumped to.
Maybe jumping to the first error should not be the default when adding ++term to the command?
PS: It would be nice to not write
:make ++term, hopefully you going to have it eventually with smth likeset make=terminal/set make=joboption.
I think it would be better to just create a custom user command instead. Adding a separate option seems kinda out of place? I mean you can't configure default behaviour with ++ arguments with other ex commands.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
PS: It would be nice to not write
:make ++term, hopefully you going to have it eventually with smth likeset make=terminal/set make=joboption.
I think it would be better to just create a custom user command instead. Adding a separate option seems kinda out of place? I mean you can't configure default behaviour with ++ arguments with other ex commands.
With the custom command I can't say "do not use terminal, but job instead" which I was referring to with set make=job.
Basically, with set make=term I would like to see how compilation happens, with set make=job I just want to make in background without any visuals.
PS
I can do it now without using :make at all, but I can do make in a built in terminal too without this patch :).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
That also applies to the regular :make, you just have to pass a shebang [!]]. In the docs:
Yes, I know, but I would expect it to jump in another window/split instead of replacing make results.
With regular :make it is fine as :make results are kind of hidden.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
With the custom command I can't say "do not use terminal, but job instead" which I was referring to with
set make=job.
Basically, with
set make=termI would like to see how compilation happens, withset make=jobI just want to make in background without any visuals.
Wouldn't ++hidden be the same as a job? It just creates a terminal buffer but doesn't actually open it.
PS I can do it now without using
:makeat all, but I can do make in a built in terminal too without this patch :).
I tried creating a plugin for that, problem was that trying to integrate makeprg was not possible because the args can be anywhere in that option using $*
Yes, I know, but I would expect it to jump in another window/split instead of replacing make results. That would be one of the reasons for me to use
++termhere to see context of the errors.
With regular
:makeit is fine as:makeresults are kind of hidden.
That makes sense
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I tried creating a plugin for that, problem was that trying to integrate
makeprgwas not possible because the args can be anywhere in that option using$*
I just run make in the job and capture output to the special buffer (not specific to make, any shell command):
https://asciinema.org/a/A99clJGwpf7PRlduC2p125JZY
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Wouldn't ++hidden be the same as a job? It just creates a terminal buffer but doesn't actually open it.
Somewhat, but the difference is in buffer creation. Job doesn't create one by default.
So if you ran your make with hidden buffer 100 times you'll have your next buffer created with 100 something bufnr. And then you would need to clean up those hidden terminal buffers too.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I just run
makein the job and capture output to the special buffer (not specific to make, any shell command):
That looks cool, Adding the exit code as the exit message is something I didn't think of
Somewhat, but the difference is in buffer creation. Job doesn't create one by default.
So if you ran your make with hidden buffer 100 times you'll have your next buffer created with 100 something bufnr. And then you would need to clean up those hidden terminal buffers too.
So with a ++job option, it would create a job, that you cannot view the progress of (in terms of output) and then updates the quickfix/location list when its done?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
So with a ++job option, it would create a job, that you cannot view the progress of (in terms of output) and then updates the quickfix/location list when its done?
yes!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
FWIW, here is the :Make command that runs using a job, populating quickfix along the way:
def Make(args: string = "")
if exists("g:make_jobid") && job_status(g:make_jobid) == 'run'
echo "There is a make job running."
return
endif
var makeprg = &l:makeprg ?? &makeprg
var qf_opened = false
setqflist([], ' ', {title: $"{makeprg} {args}"})
g:make_jobid = job_start($"{makeprg} {args}", {
cwd: getcwd(),
out_cb: (_, msg) => {
if !qf_opened
qf_opened = true
belowright copen
endif
setqflist([], 'a', {lines: [msg]})
},
err_cb: (_, msg) => {
if !qf_opened
qf_opened = true
belowright copen
endif
setqflist([], 'a', {lines: [msg]})
},
close_cb: (_) => {
echo "Make is finished!"
}
})
if job_status(g:make_jobid) != "run"
echom $"FAILED: {makeprg} {args}"
endif
enddef
command! -nargs=* Make Make(<f-args>)
If would be great if this could be simplified to almost no config, but if not I can live with it :).
https://asciinema.org/a/XWwYA2wLYlvGmbNcMS5eUpGam
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I have charged vim's terminal with additional mappings to detect errors and jump over them. So my personal need in this shades away.
https://asciinema.org/a/ACJHdl0pSQza7AakJXULOrVIX
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 2 commits.
You are receiving this because you are subscribed to this thread.![]()
With the
++joboption, it would create a background job whose output cannot be viewed in progress, and then update the quickfix/location list once it finishes.
I suggest the output still loads into the quickfix list but remains hidden by default — this could better accommodate different use cases. Additionally, once the job completes, some form of user notification would be helpful — for example, a bell or a status indicator (like “running” / “done”) that could be integrated into a statusline plugin.
Regarding jobs and terminals: is it possible to run multiple processes simultaneously?
Also, apart from :make, are :grep and :addgrep also planned for implementation?
You may want to refer to this plugin: skywind3000/asyncrun.vim.
Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()