filePro syntax coloring

[Brian K. White]

On 5/27/2014 11:43 AM, Jay Ashworth wrote:
> Not bad, Brian, but there are two comments that come to mind, and I don't
> know vim well enough to know if the second is practical or not.
>
> The reverse video on the colons is really jarring, at least to me; where
> can I change that?
>
> And there *is* a time when I'd like them to be in reverse:  if there aren't
> three of them on a line.  Is the engine that smart?
>
> Cheers,
> -- jra
>

The particular color choices were really the last theing I was thinking 
very hard about, since they are easy to change to whatever you want. I 
went through a few different palettes just within the time frame of that 
old page. The hard part is getting the thing to recognize different 
elements reasonably well without being able to do it the only really 
correct way, which would be to have a copy of fp's own actual parsing code.

One reason they are intentionally jarring is just to distinguish them 
from colons that appear in the text, except I didn't get as far as 
magically handling the ^A's or whatever they are to display as : and be 
entered as : yet be ^A in the file. I think the engine CAN do fancy 
things like that, just *I* can't. It's like filepro edit syntax times pi 
hundred. Whatever you can imagine, it probably CAN do it. (we'll pretend 
not to think about something simple like handling a " as text for the 
sake of the joke for now ;)

The main reason of course is just that you need some way to make the 3 
sections really stand out, because I couldn't get the multi-line output 
like I wanted. And there are only so many colors available without 
changing the bg color, and in fact I really wanted to change the bg 
colors too for the different sections, so you run out of unique and 
visibly unambiguous combinations quickly. Plus I was possibly too crazy 
in trying to provide different colors for every little recognizable 
thing, like color and keystroke codes within text strings... or like 
recognizing all the comparison operators, but only when they were 
comparison operators instead of variables with the same names...)

But yes the color values are all easy to change. The syntax files are 
plain text and not too terribly unreadable.

...ahh, I see I did not set any explicit colors but just defined a bunch 
of things to recognize, and then used vim default names for common 
objects and let vim use it's default colors.

So, I define how to recognize a "fileproComment" and then I tell vim 
that a "fileproComment" is a thing of type "Comment" and vim has a 
default color it uses for "Comment". And, a user can load some custom 
theme, which will define some other color for comments, and it'll work 
for prc files as well as any other files that don't set their own 
explicit colors.

So, in this file
http://www.aljex.com/fp/vim/syntax/filepro.vim
you want to change this line near the bottom:

HiLink fileproDelimiter	Todo

to

HiLink fileproDelimiter	<something else>

"Todo" and <something else> are defined I guess somewhere in 
/usr/share/vim/vim73/colors?, with several possible/optional other 
places that override, like /usr/share/vim/site/colors and probably 
something in the users home dir. But default.vim in there says it 
doesn't do anything so I don't know off hand where the default 
:colorscheme comes from.

It looks like now you can ignore the part of the readme about editing 
$VIM/menu.vim Looks like the menu of the list of available file types is 
either automatically generated or not shown at all now.

Also the directions should really be converted to some portable 
equivalent of site-specific local files, or user specific files in their 
home dir instead of editing the vendor/package supplied files in /usr/share

But I just tried it minus the menu.vim part just to see if it even still 
worked, and it colorizes prc files, but damned if I know where the 
colors are defined.

-- 
bkw