Can makeprg (or equivalent) be locally file-customised?

[dva...@internode.on.net]

When Vimming a number of wildly disparate textfiles, each with a single custom processing requirement, it would be absolutely ideal to set makeprg (or equivalent) in a modeline. But for makeprg that is verboten: "This option cannot be set from a |modeline| or in the |sandbox|, for security reasons."

Mind you, here there is no such security concern - whether any command is run by ":!" or makeprg makes no real difference, so I'm not entirely sure why one would impose the clumsiness of having to insert ":!groff -k -Tpdf -ms -m hdtbl -dpaper=a4 -P-pa4 % > /tmp/vde.pdf" or whatever another file needs?

So is there a file-local way to just alias e.g. ^m to a shell command, **in the modeline**? That would be much faster to invoke, and not muck with makeprg.

Vim can do everything; it's finding the clue in the :help that is the challenge, even going in with a packed lunch.

Erik

[Salman Halim]

You could set up an autocommand that reads the first few lines of the file and sets any option you like from there. Maybe you'd need to put it on a one second timer or something.

The security problem comes because you might have makeprg set to something for your project and then you open a new file that sets it to, say, 'rm -rf /' or some such. You try to build your project innocently and end up deleting your system.

Salman

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/d896d28d-744e-4f17-a397-6032c2e0db34%40localhost.

[dva...@internode.on.net]

Many thanks, Salman, for your suggestions - they are thought provoking:

On 17.04.25 21:11, Salman Halim wrote:

> You could set up an autocommand that reads the first few lines of the file

> and sets any option you like from there. Maybe you'd need to put it on a

> one second timer or something.

Ah, I'd dismissed autocommands, as a multitude of them would be a

maintenance burden. But I get your point; I could try to synthesise a

makeprg substitute which instead reads a custom othermodeline. Then one

autocommand suffices. It could even map more than one key, perhaps.

It's tedious that a modeline can't do an nmap either, as that would be

even more directly effective.

It might be necessary to find a vimscript primer, as executing a :nmap

from a tagged line read from the file is beyond my current ken. My take

is that there would be no delay risk - the tag is found or not, the :nmap

is executed or not - instantly?

> The security problem comes because you might have makeprg set to something

> for your project and then you open a new file that sets it to, say, 'rm -rf

> /' or some such. You try to build your project innocently and end up

> deleting your system.

> Salman

Hmmm, that type of problem is created only if the program is *not* read

from the file, i.e. the file doesn't customise to suit. Thus it is more

the current modeline exclusion which could create that problem, I

figure.

I'll look for processing commonality, as I extend the workflow. Then it may

well be OK to typify the source files by extension, and allow one common

cross-task makefile to differentiate processing. That is (for me) a high

level of organisation in an exploratory phase, where I'm still

assembling / building the toolset and forging the workflow. But using filename

extension might be best in the long run. Then we're back to make - nice and simple.

Erik

[Eli the Bearded]

On Fri, 18 Apr 2025, dvalin via vim_use <vim...@googlegroups.com> wrote:
> Ah, I'd dismissed autocommands, as a multitude of them would be a
> maintenance burden. But I get your point; I could try to synthesise a
> makeprg substitute which instead reads a custom othermodeline. Then one
> autocommand suffices. It could even map more than one key, perhaps.

I use autocommands like:

" Set up macros for Rnmail
autocmd BufRead .letter.* :so ~eli/.lettervimrc
"
" Set up macros for Pnews
autocmd BufRead .article.* :so ~eli/.news_vimrc

so that I get different specific macros for replying to Usenet
via mail or posts. I think that was the suggestion here. I
want slightly different versions of certain macros for each.

If you can identify which makeprg you want for a file based on
a glob, then that's an easy fix.

> It's tedious that a modeline can't do an nmap either, as that would be
> even more directly effective.

I've done some research into modeline security holes in the past, and
"drive a truck through" is a good description of how they used to be.
If you can nmap on the sly, you can own the user. Consider editing
any untrusted content, like a reply to a message on a mailing list.
Is there some nasty modeline lurking in the .sig?

> It might be necessary to find a vimscript primer, as executing a :nmap
> from a tagged line read from the file is beyond my current ken. My take
> is that there would be no delay risk - the tag is found or not, the :nmap
> is executed or not - instantly?

Yes, nmap is instant. Let me suggest my simple but powerful solution, a
mapping that can turn a line in a file into a command.

:map * "yyy@y

That makes "*" run the line currently under the cursor. In my own files,
for my own use, I embed vi commands all the time.

:r! head /tmp/update
# set a copied name
# :map ` k0f\|yt\|jp0s ==> <ESC>A<CR><ESC>
# set a flag
# :map \ 0i --> copied = 2<ESC>A<CR><ESC>
# :map z 0i --> ignore = 1<ESC>A<CR><ESC>
# delete an entry (note colon)
# !!! path : /path/to/bad/file


# to copy (17G)

Note that :r! is a line for the * macro. The above are commented out,
so I uncomment them when loading the file, * them, and then undo my
changes. (The /tmp/update file is | delimited text produced by one
program for another. 90% of the cases I have scripted to automatic,
but I still need some manual entries, and the maps help me.)

In sh scripts, I sometimes use an uncommented form:

: new $HOME/reference.file

This relies on ":" being a valid command in sh, but one that ignores
it's arguments.

In other contexts, I use multiline comments that don't need per line
annotation (think the C style /* ... */) or ignored multiline strings:

$_ = "
:! perldoc perlvar
";

> I'll look for processing commonality, as I extend the workflow. Then it may
> well be OK to typify the source files by extension, and allow one common
> cross-task makefile to differentiate processing. That is (for me) a high
> level of organisation in an exploratory phase, where I'm still
> assembling / building the toolset and forging the workflow. But using filename
> extension might be best in the long run. Then we're back to make - nice and simple.

You could create a script for makeprg that examines the file and then
builds a command line for the makeprg you want.

Elijah
------
ex: /sig virus!$/w!>>~/.signature : Eli's vi modeline sig virus!

[Marc Chantreux]

Hi Dvalin,

this usecase illustrate what I said in misc@openbsd about the appliance
of vi to the vim culture because most of the solution is outside vim to
me.

A shell script will be much easier to maintain and extend as well as
resusable (from a makefile or a shell script).

wanabe is somewhere in $PATH and its content is

#!/bin/sh -eu
sed -E '/^W\($/,/^\)$/!d' "$1" |
sed '1d;$d' |
${SHELL:-} -s -- "$@"

so now I can write a roff file with

.ig

the W() script is hte way to get a document from the current file

W(
d="$1"; shift
dformat "$d" |
eqn |
pic |
soelim |
groff -Tpdf -Kutf-8 "$@"
)
..

and from vim

let &mp='wanabe % > /tmp/vbe.pdf'

regards

--
Marc Chantreux

[Marc Chantreux]

hello Eli,

On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:
> > autocommand suffices. It could even map more than one key, perhaps.
>
> I use autocommands like:
>
> " Set up macros for Rnmail
> autocmd BufRead .letter.* :so ~eli/.lettervimrc
> "
> " Set up macros for Pnews
> autocmd BufRead .article.* :so ~eli/.news_vimrc

you're so close to a package you can share with the community:

~/.vim/pack/start/Pnews/ftplugin/pnews.vim # your news_vimrc
~/.vim/pack/start/Pnews/ftdetect/pnews.vim #
autocmd BufRead .article.* setf pnews

regards

--
Marc Chantreux

[Marc Chantreux]

hi again,

On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:

> :map * "yyy@y

this is an old vi trick, vim can just source a range:

:.so

> That makes "*" run the line currently under the cursor. In my own files,
> for my own use, I embed vi commands all the time.

then you lose the awesome "next occurence of the current word" (see :h *, :h #
and :h g*)

regards

--
Marc Chantreux

[dva...@internode.on.net]

On 18.04.25 00:08, Eli the Bearded handed down much to be considered:

> I use autocommands like:

>

> " Set up macros for Rnmail

> autocmd BufRead .letter.* :so ~eli/.lettervimrc

That is not just a neat makefile target alternative for my simple case,

but can set up several key mappings ... and I will find patterns once

I've produced more than two sourcefiles.

...

> If you can identify which makeprg you want for a file based on

> a glob, then that's an easy fix.

That'll evolve, I'm sure. You've put me on a profitable path now, toward

a more consistent solution.

> > It's tedious that a modeline can't do an nmap either, as that would be

> > even more directly effective.

>

> I've done some research into modeline security holes in the past, and

> "drive a truck through" is a good description of how they used to be.

> If you can nmap on the sly, you can own the user. Consider editing

> any untrusted content, like a reply to a message on a mailing list.

> Is there some nasty modeline lurking in the .sig?

As I'm doing now. Your argument is succinctly powerful, not least as I

took the question for general conjecture until I got there.

> > It might be necessary to find a vimscript primer, as executing a :nmap

> > from a tagged line read from the file is beyond my current ken. My take

> > is that there would be no delay risk - the tag is found or not, the :nmap

> > is executed or not - instantly?

>

> Yes, nmap is instant. Let me suggest my simple but powerful solution, a

> mapping that can turn a line in a file into a command.

>

> :map * "yyy@y

>

> That makes "*" run the line currently under the cursor. In my own files,

> for my own use, I embed vi commands all the time.

I'm a bit slow - had to read the mapping twice to get it. It automates my

current practice of manually copying that line, at end of file, onto the

ex commandline once, then using a couple of up-arrows for repeats.

...

> > I'll look for processing commonality, as I extend the workflow. Then it may

> > well be OK to typify the source files by extension, and allow one common

> > cross-task makefile to differentiate processing. That is (for me) a high

> > level of organisation in an exploratory phase, where I'm still

> > assembling / building the toolset and forging the workflow. But using filename

> > extension might be best in the long run. Then we're back to make - nice and simple.

>

> You could create a script for makeprg that examines the file and then

> builds a command line for the makeprg you want.

Now that is tempting - hive off to awk, and avoid the vimscript learning

curve, which has scared me off for decades.

Many thanks, Elijah, for the lesson. It'll help me make order out of the

chaos of a new workflow.

Erik

[Christian Brabandt]

On Fri, 18 Apr 2025, dvalin via vim_use wrote:

> When Vimming a number of wildly disparate textfiles, each with a
> single custom processing requirement, it would be absolutely ideal to
> set makeprg (or equivalent) in a modeline. But for makeprg that is
> verboten: "This option cannot be set from a |modeline| or in the
> |sandbox|, for security reasons."

Yes that makes sense. You don't want to run arbitrary commands that you
are not aware of because those are set by the modeline.

> Mind you, here there is no such security concern - whether any command
> is run by ":!" or makeprg makes no real difference, so I'm not

Because this is not potentially run when reading the file. The user will
need to run this manually and hopefully he knows what he is doing.

> entirely sure why one would impose the clumsiness of having to insert
> ":!groff -k -Tpdf -ms -m hdtbl -dpaper=a4 -P-pa4 % > /tmp/vde.pdf" or
> whatever another file needs?

Define a custom command so you don't have to type it manually.

> So is there a file-local way to just alias e.g. ^m to a shell command,
> **in the modeline**? That would be much faster to invoke, and not muck
> with makeprg.

I hope this is not possibly and I won't support such a thing for
security reasons.

Thanks,
Christian
--
Better hope you get what you want before you stop wanting it.

[dva...@internode.on.net]

Awkward apologies for the post without subject. This one is for the thread.

On 18.04.25 09:43, Marc Chantreux wrote:

> On Fri, Apr 18, 2025 at 12:08:56AM -0400, Eli the Bearded wrote:

> > :map * "yyy@y

> this is an old vi trick, vim can just source a range:

> :.so

> > That makes "*" run the line currently under the cursor. In my own files,

> > for my own use, I embed vi commands all the time.

>

> then you lose the awesome "next occurence of the current word" (see :h *, :h #

> and :h g*)

Marc, I took '*' for a placeholder, not a literal, and would likely

substitute ^M, as ":h ^M" shows it to be redundant, and it is mnemonic

for "make".

Erik

[Enno]

If these files reside in a (project) folder, one could define makeprg in a local vimrc https://github.com/MarcWeber/vim-addon-local-vimrc/