more rfe heavy lifting

I’d always intended to follow up a big hand for rfe with details of my vim-based LCFG profile / header editing environment – but seven years intervened and apparently it never crossed my mind again.

So, to cut another long story short…

I use snappy aliases “vp” and “ep” to view and edit LCFG profiles, respectively. These consist of a few DNS checks, shortcuts, a backup system, etc. but the crucial bit is the overriding of EDITOR to be a very small bash shim, which assumes you have a full checkout of the DICE LCFG headers at "$HOME/path/to/headers":

#!/bin/bash
# Define paths for "gf" goto-file support
LCFG_WORKING_COPY="$HOME/path/to/headers"
lcfgwcpath="$LCFG_INCLUDE_WC/core/include,$LCFG_INCLUDE_WC/live/include,$LCFG_INCLUDE_WC/core/packages/*,$LCFG_INCLUDE_WC/live/packages"

# rfe doesn't specify a filetype, so we have to force CPP mode.
# Also, set working path above for "gf" support.
/usr/bin/vim -c "set filetype=cpp" -c "set path=${lcfgwcpath}" $*

I activate this via my shell. You could do it, for example, with .bashrc:

function editprofile() {
  local profile args
  for profile in ${*:-$(hostname -s)}; do
    args="${args} lcfg/${profile}";
  done;
  EDITOR="$HOME/bin/pvim" rfe -S ${args};
}

This grants me significantly more useful syntax-highlighting, as well as an understanding of #include directives, which allows me to “gf” to inspect the header under the cursor.

Of course, the highlighting doesn’t understand the embedded Perl-like LCFG bits, but that’s OK, comments and macros are a significant improvement (in particular, no longer treating /^#.*$/ as a comment). On several occasions I have experimented with a special “lcfg” vim filetype but this is 99% based on CPP, and generally the bugs outweigh the benefits.

Leave a Reply

Your email address will not be published. Required fields are marked *