Documentation: Temporary compiler arguments

[hseg]

I've been looking for a way to volatilely set makeprg to some combination of a base program and arguments. That is, I'd like something like

:Compiler pylint --disable=C0116 %:S

to have the effect of

:compiler pylint
:let &makeprg.="--disable=C0116 " . expand("%:S")

or at least have

:Oneshot pylint --disable=C0116 %:S

with the effect of

:compiler pylint
:make --disable=C0116 %:S

Of course, I could just write a command to do that, but I was looking for something built-in first. Reading the README, I initially thought :Dispatch or one of its variants would do so, however the docs suggest :Dispatch prog args uses args to identify the particular plugin to use. (Incidentally, the comment about using the 'errorformat' to construct the :Make invocation doesn't make much sense to me, I'd appreciate clarification). In particular, my initial thought to use :FocusDispatch to set the current argument combination wouldn't've worked.

I then found plain :make does work for the second option I wanted, but of course it foregrounds the process. Then I tried :Make. To my delighted surprise, it behaves like the first option -- i.e. invoking :Make args will have the side effect of setting makeprg to makeprg . args.

Is this intended? If so, it is undocumented. If not, please keep this behaviour around in some capacity -- at least in my workflow it is currently useful.

[tpope]

I then found plain :make does work for the second option I wanted, but of course it foregrounds the process. Then I tried :Make. To my delighted surprise, it behaves like the first option -- i.e. invoking :Make args will have the side effect of setting makeprg to makeprg . args.

The way I would phrase this is that :Make is a drop-in replacement for :make. Hence the name.

Is this intended? If so, it is undocumented. If not, please keep this behaviour around in some capacity -- at least in my workflow it is currently useful.

The existing documentation seems clear enough to me, but I'll tweak the wording a bit.

[hseg]

I was pointing out that :Make and :make have differing semantics - `:Make args` is equivalent to ``` :let &makeprg=makeprg . args :make ``` In particular, unlike `:make args`, it persists the choice of arguments, so that a subsequent `:Make` runs with the same arguments. El 1 de septiembre de 2024 19:28:47 GMT+03:00, Tim Pope ***@***.***> escribió:

…

Closed #350 as completed via 63e4570. -- Reply to this email directly or view it on GitHub: #350 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[tpope]

In particular, unlike :make args, it persists the choice of arguments, so that a subsequent :Make runs with the same arguments.

It does not do this.

[hseg]

I don't know what to tell you, but on my machine

:compiler pylint
:set makeprg
makeprg=pylint --output-format=text --msg-template="{path}:{line}:{column}:{msg_id}: [{symbol}] {msg}" --reports=no
:Make %:S
<makes>
:set makeprg
makeprg=pylint --output-format=text --msg-template="{path}:{line}:{column}:{msg_id}: [{symbol}] {msg}" --reports=no %:S

whereas the same with :make does not change makeprg

[hseg]

I'm currently trying to set up a temp config to confirm this is due to Dispatch, and not a poor interaction with something else

[hseg]

OK, it seems to be an interaction with something in my .vimrc, bisecting to find it

[tpope]

You can check :verbose set makeprg? to find what last changed the option.

[hseg]

Ah, OK -- it appears to be due to these lines in my vimrc, though I have no idea why:

augroup tooling
    autocmd!
    autocmd QuickFixCmdPost [^l]* cwindow " open quickfix if errors exist
augroup END

[hseg]

You can check :verbose set makeprg? to find what last changed the option.

With my autocmd restored, this blames dispatch/autoload/dispatch/job.vim line 112

[hseg]

67a49fa now makes :Make throw errors after any compiler is set (i.e. on initial startup, `:Make` successfully tries running `make`, but if the compiler is changed with `:compiler`, any subsequent invocation of `:Make` errors): ``` Error detected while processing function dispatch#compile_command[162]..function dispatch#compile_command[158]..<SNR>51_set_current_compiler: line 4: E121: Undefined variable: a:bufnr E116: Invalid arguments for function setbufvar ``` In re my request to keep the current behaviour, I guess I can work around it by instead using `m<Space><Up>` and history editing, though that's a little more annoying.

[tpope]

67a49fa now makes :Make throw errors after any compiler is set

Fixed in aeb5242.

In re my request to keep the current behaviour, I guess I can work around it by instead using m<Space><Up> and history editing, though that's a little more annoying.

Note that even by your own requirements the behavior I fixed wasn't very helpful. Repeated calls to :Make <args> would make the argument list longer and longer.

In particular, my initial thought to use :FocusDispatch to set the current argument combination wouldn't've worked.

There actually is an undocumented incantation to use :FocusDispatch to build on the currently active compiler plugin:

:FocusDispatch -- --disable=C0116 %:S

[hseg]

On Mon, Sep 02, 2024 at 07:47:17AM GMT, Tim Pope wrote: > [67a49fa](67a49fa) now makes :Make throw errors after any compiler is set Fixed in aeb5242.

Still not the case here: ``` Error detected while processing function dispatch#compile_command[162]..function dispatch#compile_command[102]..<SNR>53_set_current_compiler: line 4: E121: Undefined variable: a:1 E116: Invalid arguments for function setbufvar ```

> In re my request to keep the current behaviour, I guess I can work around it by instead using `m<Space><Up>` and history editing, though that's a little more annoying. Note that even by your own requirements the behavior I fixed wasn't very helpful. Repeated calls to `:Make <args>` would make the argument list longer and longer.

Right, my hack was to `:Make args` once, then use the `m<CR>` keybinding to `:Make` until I needed to edit. Though I hadn't tried the workflow long enough to run into the circumstance you're critiquing, and must admit it'd have that problem.

> In particular, my initial thought to use `:FocusDispatch` to set the current argument combination wouldn't've worked. There actually is an undocumented incantation to use `:FocusDispatch` to build on the currently active compiler plugin: ``` :FocusDispatch -- --disable=C0116 %:S ```

That works! I initially dismissed it because it would eagerly expand `%:S`, making it somewhat less useful for multi-file projects, but along with the `m<space>` workaround I found, this gives me enough options to live with at the moment.

[tpope]

Still not the case here:

Gah, I keep forgetting to I need to test it with an existing compiler plugin already enabled. Should be fixed now.

[hseg]

OK, that fixed it! Is that last commit (permitting :FocusDispatch :Make) supposed to be a more readable spelling of the undocumented `:FocusDispatch --` ? Thanks for adding it! Suggested documentation for this new feature: ``` :FocusDispatch [options] {program} [arguments] Set a global default command for |:Dispatch| with no arguments. Overrides |b:dispatch|. If {program} is *:Make* or *--*, the program used will be set to *&makeprg*. ```