GEdit syntax Highlighting for blitzmax - howto

Archives Forums/Linux Discussion/GEdit syntax Highlighting for blitzmax - howto

Jim Teeuwen(Posted 2009) [#1]
In response to a question in this thread I made a BlitzMax syntax Highlight file for Gnome's GEdit.

I'm re-posting it here in the hopes it may be useful to some linux users who want to get away from the default bmax ide in linux.

Here is the file:.


To make it work, do the following:

1) Save the above xml in a file called 'bmax.lang'.
2) Copy the file into the gedit language files dir.
 $ sudo cp bmax.lang /usr/share/gtksourceview-2.0/language-specs/


3) Add the mime type for .bmx files to /etc/mime.types
 $ sudo echo -e "application/x-blitzmax  bmx"  | sudo tee -a /etc/mime.types


4) Update the mimetype database:
 $ sudo update-mime-database /usr/share/mime


5) Close any instances of gedit you already had open.
6) Open a bmx file in gedit.
7) In gedit go to the following menu: View->Syntax Highlighting->Sources and select BlitzMax.

You should now have proper syntac highlighting for blitzmax.


Jim Teeuwen(Posted 2009) [#2]
Here are some additional GEdit tips to make it a fairly decent simple code IDE. By default it's a fairly mundane notepad clone with fancy colours, but with a few clicks it can become quite a nice little development tool.

1) Go to the menu Edit->Preferences.

2) On the View tab, select Display line numbers and Highlight current line.. Optionally click Display right margin as well.

3) On the Editor tab, select Enable automatic indentation.

4) Optional: On the Plugins tab, enable the plugin named External Tools. This one allows you to bind external shell commands/scripts to Gedit menus and shortcut keys. We can use this to call a Build script from inside GEdit.

In order to use a build script, we first have to write one. I use a little Bash script for my blitzmax projects, which automatically configures the build directories and allows a few simple command line switches to be passed. I prefer this over using the standard max IDE, but it does require that you format your Project directories in a specific way.

My Blitzmax projects currently use a directory structure like this:

[MyBlitzProject]
  |--[src]
  |    |--main.bmx
  |    |--morecode.bmx
  |    |--yetmorecode.bmx
  |--build.sh


The build script, when run, creates an additional directory in the project root named bin, which contains a debug and release dir. This will then look something like this:

[MyBlitzProject]
  |--[bin]
  |    |--[debug]
  |    |--[release]
  |--[src]
  |    |--main.bmx
  |    |--morecode.bmx
  |    |--yetmorecode.bmx
  |--build.sh


Obviously, the debug/release dirs are used to save the compiled binaries.
This keeps everything neatly separated and clean.

Note though that the script expects the Entry file for your blitzmax code to be called 'main.bmx'. If you do not like this, you can change this in the build script listed below.


On it's own, the build script is versatile enough to make commandline compilation easy and painless, but we can also plug it into GEdit by using the 'External Tools' plugin I mentioned earlier.

To make it all work, let's start by giving you the build script that I use. If you know a little about bash, you can modify it as needed.

Save this as a new text file called 'build' (The .sh extension is not needed).

The One thing you have to change, is the line '
BMAX="/path/to/blitzmax/bin/";'
. Change that path to point to your blitzmax bin directory, so the script can find the compiler.



I have a copy of this file saved in a safe place, and simply copy it over to any new project dir I start to work on.

Now we are ready to hook this stuff up to GEdit.

After you have enabled the 'External Commands' plugin, go to the menu Tools. You will see 3 or 4 new commands listed there. These are part of the plugin by default. We are going to add our own to this. Click the menu External Tools... at the bottom to open the plugin config panel.

This panel let's you add/modify commands for this plugin. We will add 2 new ones. Build Clean and Build and Run. The first one simply cleans your project's source directory of those pesky hidden .o and .a files that blitzmax always creates. The second one is the important one, as it lets you compile your code and run the program with the press of 1 button. Regardless if which code file you currently have as the active tab!

- Click the New button.
- Change the name for the new command to Bmax Build Clean.
- Change the Description field to something like 'Clean Project Directory'.
- Click the Shortcut Key field and press any key combination you want to use for this command. I use <ctrl>F5 for it myself.
- In the Commands we put a short piece of shell script listed below.

This script will fetch the directory of the currently active tab's file. Loop up the directory chain until it finds a file called 'build', then execute this build file and print the result in a neat little Panel at the bottom of GEdit. When we are working on code files in our projects, this just happens to always be our own build script! Lucky us!

#!/bin/bash
EHOME=`echo $HOME | sed "s/#/\#/"`;
DIR=$GEDIT_CURRENT_DOCUMENT_DIR;
while test "$DIR" != "/"; do
    if [ -f "${DIR}/build" ]; then
        DIR="$DIR/build -c";
        ${DIR};
        exit
    fi
    DIR=`dirname "${DIR}"`;
done


- Set the Applicability drop-down to Local Files Only'.

- Repeat all these same steps for the second command called Bmax Build and Run. With the exception of the script in the Commands field. We will make a slight change to the one listed above.

#!/bin/bash
EHOME=`echo $HOME | sed "s/#/\#/"`;
DIR=$GEDIT_CURRENT_DOCUMENT_DIR;
while test "$DIR" != "/"; do
    if [ -f "${DIR}/build" ]; then
        DIR="$DIR/build -tqe";
        ${DIR};
        exit;
    fi
    DIR=`dirname "${DIR}"`;
done


Once done, press close and you should have the 2 new commands in the Tools menu ready for use!

Note that in the second command's script we call our build script with 3 command line options '-qte'. These stand for 'Quick Build', 'Threaded Build' and 'Execute'. Since the option '-r' is not provided, this command will always perform a Debug build.

If you want to change this, you can simply refer to the help in our build script and change the above snippets accordingly. Or add even more commands to Gedit for these other cases. The sky's the limit! :)

Now you can happily type your code in Gedit and hit F5 (or whatever key you bound to it) and have your program compiled and run, just like that!


D4NM4N(Posted 2009) [#3]
Nice hacks. :)
This will be useful.

It would be nice to extend this to have a BMax written "project manager" as the 'main' app, that manages the project's code/media files (create, move, delete, SVN controls perhaps and a release project button) and keeps track of their dir info.

-then that app launches GEdit as it's editor. The gedit mod could be done by the program when first used. Sort of like an IDE that leaves the editing part (the hardest bit to code) up to GEdit.


Jim Teeuwen(Posted 2009) [#4]
I've been looking into writing a fullblown project manager plugin for Blitz, possibly with something like a simple debugger as well, but atm it's just musings in my head.


Angus(Posted 2009) [#5]
Thanks for the info Jim T.

I'll give Gedit a go as my editor for a while, it suits ubuntu's looks more than the original IDE :)

I'd still be interested if you were working on a plugin, or know of anyone else who is?


Jim Teeuwen(Posted 2009) [#6]
I havn't given that any more thought really. I have gotten used to the build script setup as I now use it for all my other code/languages as well. This means that, regardless of the language I am programming in, F5 will always map to the appropriate compiler/interpeter for that particular language.

While this means I don't have a debugger for bmax while I'm programming, it hasn't really given me any trouble.


Angus(Posted 2009) [#7]
I dont use the debugger that much either. My main concern is the docs, but I guess I can navigate them in a browser window.

I am happy enough with the system as it is as well, but would like more commands highlighted. I could make a little program that generates the lang file using info from the commands.txt file in the Bmax docs dir. Would it slow gedit down to have hundreds of entries? Is this a dim idea?


Jim Teeuwen(Posted 2009) [#8]
It's worth a try. I'm not sure how gedit would respond to it. can't say I've tried it myself. Give it a go and see what happens :)


Angus(Posted 2009) [#9]
Here's the same lang file with the keyword section compiled from my own commands.txt file. So it's got the maxgui things in there too.

It's a bit big now, with more than a thousand keyword entries, though there are a handful of repetitions.



Edit: Dunno why it came out double spaced! I didn't copy it out that way...

Also, I notice that the letter "d" has snuck in there somehow, will investigate.


Angus(Posted 2009) [#10]
Have fixed the "d" problem, and a couple of others. This is the proper list:




Brucey(Posted 2009) [#11]
I dont use the debugger that much either.

Sacrilege ! :-p


Angus(Posted 2009) [#12]
I know, I'm a bad man. I do debug compiles when I've stuck a debugstop in somewhere, just to be COMPLETELY certain that the program is reaching a particular point in the code.

I'm so scrappy...