Looking for suggestions in editing FPro files

[Brian K. White]

On 6/4/2010 2:34 PM, Boaz Bezborodko wrote:
>> Date: Fri, 4 Jun 2010 12:27:53 -0400
>> From: Fairlight<fairlite at fairlite.com>
>> Subject: Re: Looking for suggestions in editing FPro files
>> To: filepro-list at lists.celestial.com
>> Message-ID:<20100604122753.A20820 at iglou.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> When asked his whereabouts on Fri, Jun 04, 2010 at 11:22:39AM -0400,
>> Boaz Bezborodko took the fifth, drank it, and then slurred:
>>
>>      
>>>> While I don't mind working in the regular screen most of the time, I was
>>>> wondering if anyone has an alternate way of editing FPro programs that
>>>> allows you to see a lot more lines at a time without having to
>>>> constantly print out a hardcopy or an unformatted ASCII version in a
>>>> text editor?
>>>>          
>>>
>>>        
>> How much would you pay for a cross-platform GUI editor that had labels in
>> the first cells, If/Then tags in the second cells, and the third cells were
>> editable conditional and action lines.  Think of a mini-Excel type program,
>> but as an editor for fP code.
>>
>> I know I can do this, because I did something -very- similar for a Call of
>> Duty 4/5 weapons editor, and people loved it.
>>
>> But it'd have to be worth it to me to actually rip it apart and make it
>> into an fP editor.
>>
>> There would be no syntax checking, I can say that up front...but then there
>> isn't in a text editor either.  Giving the fP help is probably not going to
>> happen at least in a first version (if at all), but again, neither does a
>> text editor have that.
>>
>> Essentially, I am pretty darned I can make this program go as high as your
>> screen heignt.  Depending on the font size used, you might get
>> significantly more processing in-view while editing.
>>
>> mark->
>> -- Audio panton, cogito singularis,
>>      
> Not enough to justify your writing the program just for me.  I normally
> don't do a lot of programming, but the last few months have been a bit
> different as we started to do a lot of new business that requires new
> programs and modifications.
>
> But I can see spending something like $100 or $200 for something that
> makes the programming easier.  If it could color code variables,
> highlight key commands or selected strings like Notepad++ can do then
> that can be even better.
>
> (Notepad++ has the ability to use plugins, but I that is way past my
> programming knowledge.)
>
> Boaz
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>    

I started to write syntax-highlighting config files for prc tables for 
vim and cooledit some years ago.
I only got as far as this:
http://www.aljex.com/fp/vim
and
http://www.aljex.com/fp/mcedit

I would LOVE to finish the vim one.

I got the syntax highlighting working pretty well, but I could never get 
it to split the lines up into two-line if/then "greenbar" display like 
what Mark has in prc2html. Closest I was able to do was either color 
each of the 4 possible sections with different background colors, or, 
since that made the syntax highlighting hard to see, leave all the 
sections colored the same way, but super-uber-highlight the colons so 
that they popped out of the rest of the line at a glance without having 
to squint & search.

I do believe the vim syntax descriptor language has enough power to make 
a real good prc table editor, but that it probably just requires some 
unusual exotic use of it. (kind of like filepro edits...) The problem is:
* inserting the line-feeds in the display as if it were just another 
color code
* telling vim how to count the display lines

Alternatively, It's practically a guarantee that emacs could do a 
perfect job since the descriptor language is a fully functional generic 
programming language of it's own (lisp). But despite that I was an 
AutoCAD user in drafting & engineering school, I never picked up lisp 
(acad uses lisp as it's internal scripting language just like several 
things do/did including emacs).

The line length isn't really 126 or 127, that's just how long cabe can 
handle for display/edit. cabe can tokenize and clerk/report can execute 
lines up to... 255 chars long?

Bob Stockler had some vim macros he used to do rudimentary syntax 
checking like line lengths (the full runnable length not the cabe 
display length) and hot-keys to check and compile a prc table from 
within vim by loading it in rcabe non-interactively in the background. 
Macros like that plus syntax highlighting is why I think vim is a good 
place to start making an external fp editor since the stuff is already 
pretty close. And there is a gvim for windows so windows users aren't 
left out.

-- 
bkw