[pedevel] Re: keywords.cpp with BeOS API symbols
- From: Christian Packmann <Christian.Packmann@xxxxxx>
- To: pedevel@xxxxxxxxxxxxx
- Date: Sat, 01 May 2004 20:47:15 +0000
Hi there,
On 2004-04-30 17:33:31 [+0000], Oliver Tappe wrote:
> On 2004-04-27 at 20:04:26 [+0200], Christian Packmann wrote:
>> [...] I think that these keyword classes should be supported (with
>> some C/C++ examples):
>> keywords - for, while, continue, break, inline
>> types - int, char, void, short, long
>> global functions - strlen, strcpy, fopen, fread
>> constants - EOF, SEEK_CUR, LONG_MIN, EXIT_SUCCESS
>> class names - vector, map, string
>> class function names - resize, clear, push_back, find
>> [...]
> I believe that this broad approach to highlighting will involve a huge
> amount of work (as there are a lot of keywords).
Nah. Automated extraction is the key. :) I'm currently using C++/STL
programs to do that, and these already have pretty good hit rates. They
spit out an alpha-sorted list of keywords, and I just have to go over the
list and do some corrections by hand. Some keywords will escape for now,
but those be added manually over the course of time.
> Furthermore, I am not sure it will be easy to agree on what constitutes a
> complete keyword set:
> - every declaration/definition in the (posix/cpp/gnu/be) headers?
> - every function defined in libroot/libbe?
We could organize the keywords in modules, one each for C/C++/posix/BeOS
etc. If the new STL parser can be used, the desired modules could be simply
concatened to a single keyword file, depending on the users wishes.
Separate modules would also make maintenance of keyword sets much easier.
> Even if we come up with a complete keyword set, the differentiation
> between class names, functions and methods will prove much too difficult
> for our current C/C++-"parser" (*cough*). In order to get it perfect,
> we'd have to use a full C++-parser that can do namespace lookups for us.
Hmm, I wasn't even thinking about doing correct parsing (I'm insane, but
not *that* insane;), but just doing plain lookups to get the color for a
certain keyword. For this we just need two or three more color fields in
the prefs, a reworked keyword parser which uses more keyword classes, and
changes to the code where colors are assigned to recognized keywords.
Of course this has the disadvantage that class methods may be recognized
incorrectly, but this should happen rarely.
IMHO the benefits of comprehensive syntax highlighting far outweigh the
disadvantages. And as the syntax coloring/keyword sets are optional anyway,
users not interested in it loose nothing.
>[ 8< ]
>> A complete keywords.cpp would have about 4000-5000 words; compression
>> would likely take 2-3 minutes on my machine, and I don't want to think
>> about slower machines...
>
> Argh, I am still using a BeBox to compile Pe for PPC, let's see how many
> days it'll take to start Pe from a fresh settings-folder...
66 or 133 MHz? How about a race with my P-MMX/200? ;)
>[ 8< ]
>> Otherwise a different approach would be required. I've done a few tests
>> with STL maps, and think they offer an acceptable solution. [...]
> I'd like to have a look at that and check things out with the map (and a
> hash, too).
The example program is in your mailbox.
About hash maps: I considered that too but decided against it for the
moment, as the BeOS keyword set will be highly asymmetric, due to the many
B_* constants. I don't know how well a generic hashing algorithm will deal
with that. I think you should postpone hash maps until we've got a
comprehensive keyword set, so that you can test the actual performance.
> Unless the lookup using STL proves to be too slow on older
> machines, I'd rather replace the (somewhat cryptic) DFA-stuff with an
> implementation that we actually understand. Just imagine someone reports
> a bug with keyword-lookup >;o)
Hehe. Let's hope maps work out okay. ;)
Bye,
Chris
Other related posts:
