It's been a while since last update so I figured I would show instead of tell what's going on. As such, I was preparing a video blog post.

But... for whatever reason, the command line (that is cmd.exe) decided that BEdit command line is not an executable worthy of executing. Remedy has no issue launching and displaying it correctly, nor does my other computer, but it seems this particular computer (which I have done the other videos on) refuses to launch BEdit correctly.

So before I go digging into the details of terminal flags, let me share what's going on at the development front.

Four new features are currently being worked on, this time I decided to first develop the command line version of the features, then the GUI version.

## New Keyword 'load'

First new feature is a rather simple one, the ability to load data directly from the binary file - without the need to create a member. Say for example you have a null-terminated string, previously you had to do something hacky like:

struct CStr
{
var oldAt = @;
var len = 0;
do
{
hidden u(1) dummy;
len += 1;
}
while (dummy != '\0');

@ = oldAt;

string(len) value; // NOTE Includes \0
};


Now instead of declaring the dummy member you can do:

struct CStr
{
for (var len = 0;
load(@(@ + len) u(1)) != '\0';
len += 1)
{
}

string(len + 1) value; // NOTE Includes \0
};


The load instruction takes a scalar declaration (with optional address specifier) to load data directly from the binary file. One of the reason why I added the load instruction is to prepare for stand-alone functions, the above for example could be wrapped to a function called strlen. I'm not sure if functions will be in next update but it's certainly in the backlog.

## New Keyword 'internal'

The second new feature is regarding display of members. One of the issues using BEdit is the nesting of members. As the front-end (either command line or GUI) encounters a nested member it will nest it appropriately.

For the command line viewer this means adding a new line and putting the member name on top as:

// In examples/png.bet
struct(Chunk, "IHDR") IHDR(var size)
{
assert(size == 13);

u(4) width;
u(4) height;
u(1) bitDepth;
....
};


bedit -layout examples\png.bet -data examples\test.png

IHDR (.data)
10h             width                           11
14h            height                            7
18h          bitDepth                            8


Let's say we want to combine width and height to a new struct as:

struct Dim2D
{
u(4) width;
u(4) height;
};

struct(Chunk, "IHDR") IHDR(var size)
{
assert(size == 13);

Dim2D dim;
u(1) bitDepth;
...
};


The display will now change to

IHDR (.data)
Dim2D (.dim)
10h             width                           11
14h            height                            7

18h          bitDepth                            8
...


In the GUI tree view this will produce another tree level.

If this is unwanted, the keyword internal can be added.

struct(Chunk, "IHDR") IHDR(var size)
{
assert(size == 13);

internal Dim2D dim;
u(1) bitDepth;
...
};


Output:

IHDR (.data)
10h         dim.width                           11
14h        dim.height                            7
18h          bitDepth                            8
...


internal will treat the struct member as-if the nested members where named <member>.<nested-member>. This won't produce nesting in tree view for the GUI, and it won't add additional spacing for command line view.

## Colors

As I've been doing a lot of development on Linux, I've familiarized myself more with the terminal. One of the things I've noticed is, some command line applications have coloring! As such I added some coloring for BEdit command line viewer. On Windows this will attempt to modify the terminal settings and at exit restore them. This is an optional feature that you can opt-out of by specifying -nocolor as parameter.

... this is also the first thing I will debug why my terminal is failing!

## Debugger -bdb

One of the reasons to add coloring is for just this feature, an instruction level debugger for BEdit layout instructions.

If you're new to BEdit, the tool takes a layout file and a binary file, turns the layout file into instructions, loads the binary file and executes the instructions. Previously this process has been somewhat hidden, but as your layout code increases in size and complexity, a proper debugger is required for you to find faults in the layout code (or even BEdit itself!).

This is how it looks for command line when debugging examples\png.bet

bedit -layout examples\png.bet -data examples\test.png -bdb

(The l(4) <- !l(4) at start of... a little here and there, is a known bug.)

The GUI version of this is in progress and as always, anything excluding modifying the data file, will be included in the free command line version if feasible.

## Next Steps...

Before next release the above features need a bit more testing, and that brings me to the next feature I would like to add to BEdit - automated testing.

BEdit is moving forward, but testing is a very manual process. As such I'm working on making a bunch of layout files with accompanying test binaries so that I know when I do a boo-boo, and hopefully manage to fix it before releasing an update. I'm not planning on making "unit tests" as I consider BEdit itself to be the unit, but simply to have a bunch of test files that I know doesn't break (or breaks if intentional) when I do an update.

## Oh and...

As this the most recent post I've done since the HMN update, I really like the updates to blog post authoring. The ability to add images and use markdown is really nice, thank you!

## Quick-edit

Although the features are not released, the command line functionality I posted above is available in the public BitBucket repo if you feel like trying it out before that.