On Fri, 18 Apr 2025, dvalin via vim_use <vim_use@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! -- -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/vim_use/4Zf1V03WGMzfYm%40panix5.panix.com.
