- Adventures in Independent Development

Another Update; Responses to Comments

Some comments have come up since my last post that I wanted to address. Mostly because they’re spot on.

I do realize that the swag is secondary to the project itself. I’m working on getting a good demo together, just with editing, saving to dropbox and copy/paste. These features are spread across a couple versions of the code, each focusing on a different aspect so that I could bounce between them with different stubs in place to mimic unfinished but necessary components. I’m working on combining them, and writing new stubs to mimic necessary pieces, and then I’ll have a demo to present. It’s likely that it won’t work on many configurations. As cross-platform as writing apps in the web-browser can be, there’s a surprising number of gotchas to be found in the implementations on the cards themselves. Yes, there is a reason Google uses a massive blacklist to restrict which cards it actually uses for WebGL.

Yeah. It’s a text-editor. They tend to be fairly monumental projects. I started this thinking that if I kept my scope limited, and tried to learn from existing projects (as well as reuse the massive set of vim macros) so that I could avoid reinventing the wheel. It was nice in theory, but I didn’t do a good job at sticking with that. The result is that my work was perhaps less than efficient.

As for releasing the code, I would like for it to be in a useful form by the time I release it. I used to think that integrating a core set of vim macros would be that mark. I’m now ready to greatly rethink that idea and push the mark towards something more easily reached.  At this point, I’m going to make sure that the graphics card code is ready for syntax highlighting. I’ll make a couple of simple examples, perhaps just keyword based, that show that as long as you can tell it what to color, that it can do the rest. I might find and integrate an existing javascript library for highlighting as an alternative to the macros that are used by vim.

Once those features are complete, I think the release of the code will be reasonable. I’ll still work on the project to either get that feature complete vim macro parser worked in… or to at least get some core set of alternatives that provide the same functionality. I really want this to be something that can be easily used alongside customized vim, with little to no effort required to move all of that customization over. There are various things that are near impossible, such as some of the filesystem integration that is in vim, but everything else… I still want that to work. It’s time to admit though that it might be best to put those into the list of features not required to get the code out.

As for the swag, I was trying to work through the weeks after I posted that last update, not knowing just how occupied my time would be with other things. I am working on collecting all the things that I need to be aware of to ask so that I can get everything made and sent appropriately. I’m hoping that the arrival will be a pleasant surprise for people.

Current Status


The display has been working for some time now. The method is relatively straightforward, text is mapped into an image texture usings the colors of the pixels to represent the characters. This allows for rather large files to be displayed and scrolled smoothly at 60 fps with no apparent lag. I loaded in a 100mb text file and everything worked fine. So, all in all, I’m happy with the way it’s able to load in fonts (from Google Web Fonts at the moment, but any browser loadable font should work), and then display

Vim Macros - Syntax Highlighting

This… this has been the struggle for the last long while. One of the decisions I made when starting this project was to make sure that my macro system was compatible with Vim macros. I’ve cycled through iteration after iteration of bad designs to attempt to make this work. Digging into the vim source code for how the macros work has been elucidating. It’s fairly obvious that it all grew organically based upon needs. There isn’t really an overarching structure. This is visible in the changing structure of the various commands. I haven’t been able to write a consistent grammar to parse these pieces.

If anyone has some insight into ways to approach this I would love to hear it. At the moment it’s looking to me like the best way to approach it would be to mimic the way Vim evolved. Because of the difference in levels between the code bases this will end up being fairly horribly inefficient, so I welcome alternative thoughts.


Rudimentary editing works. As does fairly primitive copy-paste. It’s not efficient at all. Currently when a change is made I need to update the texture entirely on the CPU side and then resend it to the GPU. For each and every key stroke. I’ve been working on overhauling this, but I’ll make a video in the coming weeks to demonstrate.

Really, this needs to be done by sending only the changes and then modifying the texture on the GPU itself. I’ve spent some time prototyping how this might work, but have yet to integrate the ideas into the project code. The entire chain should be stored in the browser, with the only communication being the changes to be made. So undo and redo will all be sent to the GPU anew.

The biggest limitation is the interconnection with the desktop environment. The browser limits the things that you can do from javascript to prevent various sorts of trickery. Everyone usually appreciates this because it means that malicious sites can’t pack things into your clipboard. This requires some hacks in order to work cross browser. Eventually, just writing a plug-in for each browser may be the best solution to make cut and paste work in the best possible way. I might just limit myself to Chrome here, making other browsers wait until the appropriate plug-in can be written. Browsers are also moving towards having better permissions for this sort of thing. Eventually I might just be able to ask for it, and once the user confirms have the clipboard access I need. Does anybody have strong preferences on this? I guess the choice is better cut and paste in chrome vs. proper cross-browser compatibility.


It has been far too long for this, and I apologize. Many of the original supporters have likely forgotten or written it off entirely. I hope that everyone is still using their original kickstarter accounts so that I can get things to you. I’d like to get the shirts screen printed locally by hand. The result will be something that looks aged, since the process rarely results in a perfect print. The same process will be used on the bags.

I’ll shoot for getting the surveys out in the two weeks (hopefully next if reality allows) for people to pick what they want and to provide addresses.

The delays on this were all because I wanted to overcome some hurdles before I got to it. I wanted to be able to have it coincide with a nearly complete project. Unfortunately, I put this work into plowing ahead with the idea that once I figure out how to implement a strong subset of the vim macro system that everything else would fall into place. I still believe it’s a true statement, but the implementation is much more daunting that I had imagined… and reimagined… and reimagined.

Anyway, I apologize for my relative silence. I’m used to being rather thick skinned, but somewhere along the line the doubt and criticism sunk in. My usual response… to double down and up the quality enough to shut up naysayers… wasn’t appropriate in this case, and I ended up obsessing over qualities that didn’t further the project at all, to satisfy people that weren’t really interested in things to begin with.

Completed Betwixt Icon

I was able to finish up the final icon this past week. Thanks to everyone who voted and submitted input into the ultimate creation. Here are a couple of size variations so you can get a feel for it. The sizes shown here are 500 x 500, 128 and 32 px.

Betwixt 500 Betwixt 128 Betwixt 32

I think we’re going to attempt getting nicer full on images on the T-Shirts if possible. Actual location of the image is yet to be determined. We might put the icon front and center, on the arm, near the bottom edge or back and center. Not quite sure yet, but we’ll let you know of any adjustments we might make if they happen.

Betwixt Icon Final Font

It’s been another busy week, however much better than last week. I’ve been able to get some work done on the icon. Thanks to our commenter on the blog, the final font type has been selected for the icon…welcome Gentium Basic. I’ll be finishing up any further adjustments this weekend.

As I haven’t received any further comments about coloring or texture, I’ll be going with what Robey and I think is best. On Monday I’ll be posting an entry with an image of the final icon, and any duotone options for printing that are created. Thank you everyone for your opinions, suggestions, and patience.

After this I’ll be creating all of the various loot items that backers are due to receive. Once again, keep an eye out on the blog as I’ll post when I get ready to send things out. I’m expecting at the earliest end of August but most likely sometime in September.

But before then we’ll be sending out emails collecting everyone’s information (addresses, T-shirt sizes and so on). This email will be sent through Kickstarter. We won’t be able to ship you anything if you don’t give us your address, so make sure to respond.

Hope everyone has a great weekend, we’ll see you on Monday!

Betwixt icon image update

Sorry for the late post. I am currently working full time at another job and I am having trouble figuring out how to still have time and energy to work on projects when I get home. Nevertheless here are my other ideas thus far.

Final Betwixt Icon Selected Final Betwixt Icon Selected Final Betwixt Icon Selected

They are very basic. This is mainly showing the difference between a solid black or grey background, some different fonts, and various shading differences. I cycled through a fair portion of the different texture scripts for the background but nothing beyond the cubes of the original look anything close to decent. I am a little concerned that this style is not all that uncommon, so I want to make sure I can do something to make it different.

My hope is to find a font that will make the icon stand out more. That is mostly what today’s post is about. If you have any suggestions for good free fonts that might work well here, please put them forward. I have found a couple of free for use ‘B’ examples that I think might work.

Amethysta Anonymous Pro Anton Cousine Dosis Exo Flamenco Gentium Basic Glass Antiqua Iceland

Another aspect of the final image I wanted to mention is that for T-Shirt and other such productions we’ll be going with a duo-tone icon. In two weeks I’ll also be posting along with the final version, a copy of the duo-tone version so those receiving T-Shirts or Bags will have an idea of what to expect.

As I mentioned in my last post, any comments will take high precedence in influencing our final decisions. So, please raise your voice. I’ll see you in two weeks, when I post the final version of the Icon. Thanks again for your support.

I’ll be sticking with this base theme, but going in a couple of minorly different directions for the next two weeks. On July 13th I’ll be posting another entry here on the FLB blog showing my new designs. I’ll make sure it gets posted on the Kickstarter update page and the forum, so everyone gets a chance to see the ideas. At this point you can provide any final input you have, regarding which design I should focus on. Any blog comments will heavily influence our direction, so make sure to watch for the update. We’ll likely not do another round of voting unless a fork in design occurs.

After that I’ll be finalizing the focus and completing any further design adjustments needed such as a duotone version for t-shirts and bags. My current plan, is to have all imagery for Betwixt finished and a final posting about it to happen on the 27th of July. After that I’ll be getting all of the ‘loot’ completed and sent off (this is not including final completion of the project). Current loot delivery date is going to be sometime in August - September.

Thanks so much for your patience. We’ve been really glad that so many people took part in the name selection and icon voting. See you in two weeks.

Final Betwixt Icon creation

Hey everyone, this is @pythonliving. Now that final icon voting is complete and our winner announced I’ll be working on finalizing the icon image. As everyone knows the new icon selected was a basic black box with slightly curved corners and a B in between two brackets [B].

Final Betwixt Icon Selected

I’ll be sticking with this base theme, but going in a couple of minorly different directions for the next two weeks. On July 13th I’ll be posting another entry here on the FLB blog showing my new designs. I’ll make sure it gets posted on the Kickstarter update page and the forum, so everyone gets a chance to see the ideas. At this point you can provide any final input you have, regarding which design I should focus on. Any blog comments will heavily influence our direction, so make sure to watch for the update. We’ll likely not do another round of voting unless a fork in design occurs.

After that I’ll be finalizing the focus and completing any further design adjustments needed such as a duotone version for t-shirts and bags. My current plan, is to have all imagery for Betwixt finished and a final posting about it to happen on the 27th of July. After that I’ll be getting all of the ‘loot’ completed and sent off (this is not including final completion of the project). Current loot delivery date is going to be sometime in August - September.

Thanks so much for your patience. We’ve been really glad that so many people took part in the name selection and icon voting. See you in two weeks.

Betwixt Logo Voting Results

Last week’s voting has given us a basic logo. The clear winner was:

Icon Option 1

Rachael will be working on polishing this up into a finalized logo for use on the T-shirts, bags, postcards and other such assorted items. If she produces some more variations we’ll vote again on those. Once we’ve got final versions of everything we’ll finally be ready to print and ship the various items to everyone.

Call for icon concepts

Rachael’s made a number of concepts for a logo, which I’ve included below. If you have any ideas for a logo to use for Betwixt please send it our way or post it on the forums. I’ve pushed (I know, yet again) the voting for logo concepts to June 12th. So get them to me by Monday and I’ll make sure it’s included on the ballot.

Once a logo concept is decided upon it’ll be refined into a couple of more polished final logos. When we vote on those we’ll finally be ready to make and send out the various reward items.

Icon Option 1

Icon Option 2

Icon Option 3

Icon Option 4

Icon Option 5

Icon Option 6

Icon Option 7

Icon Option 8

Icon Option 9

Icon Option 10

Icon Option 11

Icon Option 12

As a side note, I apologize for my absence as of late. I am going to get this project to a releasable state and I hope to be more active in discussions and announcements regarding my progress.

So if you have any ideas please send them our way. If you send us a concept image we’ll include it on the ballot. If you send us a description we’ll see what we can make out of it but can’t guarantee that we’ll include it. Get them to us by June 11th. Otherwise, expect an update on the 12th.

Actual Voting Dates and Icon Concepts

Alright, we’ve finally decided upon new dates for icon voting to occur. We’re going to roll it up into the surveys for what sort of reward types you’d like along with all of the pledge tiers. This way we can start to get all of the promised items, the totes, shirts, postcards and certificates all sent out.

So, what we’ll do is give you some of the stuff that we’ve come up with as a base. We more than welcome any ideas you might have, feel free to post them to the forums or email them to us at contactus@flaminglunchbox.net. Any ideas that we get from now until voting will be put on the survey and whichever concept gets the most votes will be fleshed out further by Rachael into a more streamlined icon.

Here’s some of the basic ideas that we’ve come up with. They’re a bit rough, so forgive us; the idea is, after all, to vote on a concept not a finished icon. Rae is continuing to work on some ideas, so hopefully we’ll have a couple more from us, in addition to whatever is submitted, to add to the survey.

Icon Option 1

Icon Option 2

Icon Option 3

Icon Option 4

Icon Option 5

Icon Option 6

Voting will be on the 14th of May. We’ll give the surveys to Kickstarter on that day. I assume they’ll be forwarded on the same day and they’ll show up in whatever email you’ve given Kickstarter.

I’m sorry this has taken so long to get started. These will be the dates that we’ll stick to for the voting.

Ready to get this started again

Alright, I apologize for my overly long absence. It’s amazing how much a load of stress followed by a nasty seasonal illness can take out of you. But I’m finally back on my feet and ready to get this started again. Expect icon voting to be re-announced tomorrow and more updates early next week.

Going to have to reschedule icon voting

I’m going to have to reschedule icon voting seeing as the deadline had passed and I haven’t gotten any icons posted for review or created a discussionon the forums. Some stresses came to a head in the last week. I’ll get some new dates and icons out to everyone shortly.

Icon Selection and Rendering Overview

Betwixt Icon Selection

Rachael (@pythonliving) has been busy creating various icon options for voting. At this point we have a couple to share with you. Please feel free to submit your own ideas/creations, as well as ideas you would like us to bring to fruition.


All submissions for icon design will need to be submitted by March 12th. Voting will begin on the 16th and go through the 19th.  Voting will be processed similar to name voting, and so will take a couple of days to prepare.  Once an icon is selected we will begin swag creation. At that time everyone will be getting an email verifying address for mailing and other various questions as necessary (T-shirt size, and so on).

Betwixt Update

Font Bitmap Overview

WebGL does not support fonts at the moment. However, since we’re looking to use monospaced fonts this isn’t too much of an issue.  We do need to somehow create a bitmap font though that can be loaded in as a texture. We can do this by rendering onto a Canvas element using JavaScript.  Sadly there is no standard way for JavaScript to access font information at the moment, with the exception being the width of rendered text.  I have found some tricks to get access to font height but it’s not perfect.  The problem is that we can set the font size, but then to create the bitmap font we need to stuff them all into a gridded picture with each letter remaining in the proper region. Currently the code uses reasonable guesses based on the font size, but a method to caculate the height properly will be needed before it can be considered complete.

Text to Texture Overview

Once we have the bitmap font we could render everything as a sprite.  This could work well.  But it might require more work than is actually necessary. This is because we would need to attach a position and letter to every sprite. Additionally, even those letters that are not visible still need to be kept track of.  This means that either I’m using a static set of sprite objects and am constantly updating the letters on them and their position as the user scrolls or I am storing far more letters on the card than are on the screen.

Instead, we can have the entire document be a sprite with a specialized pixel shader.  This offloads nearly all of the rendering work onto the graphics card once a little preprocessing is done. It does require a little math. The shader does per pixel calculations. This is often used to calculate shadows or transparency. In this case though we can use them to pick both a letter and an area of the letter. The pixel x position mod the letter width gives us the x position in the document and similarly with the pixel y position mod the letter height.

We can transform the sequence of letters into a sequence of pixels. Really this doesn’t require anything other than telling WebGL to assume that it’s a picture and load it in, but a little normalization can minimize the processing required later. It also allows for the creation of a secondary helper texture which stores where the line breaks are. So we create two textures, one with the contents of the text file being edited and another that maps a line number to a position in the text texture.

The mappings go something like this:

pixel y position -> file line number -> texture position

pixel x position -> column in file

column in file + texture position = letter

And once the textures are created all of this can be done on the graphics card. However, all editing needs to be done on the computer side and then transferred again to the graphics card. Currently this is all done in one large chunk, which works at a reasonable enough speed for editing bit isn’t optimal. I will need to change this to work in 16k segments for larger files instead.

Delayed Update

It’s been a stressful week. Lots of non Betwixt things have run through like a herd of rhinos in my china shop of projects. I owe people a demonstration/fleshed out status update and am still working to get something together.

Over the last couple of weeks I’ve put together a Dropbox library using their REST interface for saving and loading files. There was an existing JavaScript library but it required that the application keys be placed in the open. I have a sideproject that I’m using to test the file interfaces that I’ll be able to show soon.

I’ve also made progress on parsing vim files. I now have a regular expression that shouldn’t have been nearly so hard to create that splits the files into individual command and calls a different function for each command. This should also be usable for the in buffer command line. The next step is writing a state object for each buffer that the commands modify and finally each command has to be coded as there isn’t a particularly hard and fast rule as to how they must be formed.

Another aspect that I have worked on in yet another set of tests is keyboard input. I should be able to roll this into the actual OpenGL tests to update the text rendered to the screen in short time.

As said, I need a little more time to get a fully fleshed update out. If Sunday cooperates expect it then but otherwise it will be early next week.

Betwixt Current Status and Musings

We’re trying to work on a method of following the release early, release often method. Our restrictions are the release avenues that we’re obliged to follow from the funding model.

We’ve thought up a couple of different paths to follow for this.

  • Release the code now to the beta crowd under a restrictive license that allows no modifications.

  • Release the code now to the beta crowd under a restrictive license that requires all modifications can be released under both MIT and LGPL.

  • Release demos that consist of compiled Javascript. These would serve for demonstration and testing purposes but would not allow for development of code.

  • Release weekly screenshots and videos documenting progress.

  • Write more articles explaining approach and design decisions with code snippets. This would allow for more abstract community involvement.

I’ve spent a lot of time musing over an efficient, maintainable approach for a parser for the vim runtime files. I’ve got a couple of different attempts, none of which I’m happy with. I still think that this is a good approach as it gains access to a large base of definitions and utilities. These include syntax, keymaps, and autoindent. The problem is that it’s not a scripting language that is all that consistent.

I was hoping to have three pieces: display, editing and syntax highlighting, all working for an initial demonstration. But I’ve spent too much time working and reworking the vim command interpreter. So the first demo will just be display and editing. Whatever is decided I’ll get it to you next week.

December Update

We’ve been up to a fair amount here at FlamingLunchbox. With Christmas drawing neigh we wanted to give everyone a quick heads up as to where we are. Without further ado:

FlamingLunchbox Website

If you haven’t already noticed, we redid our main site. It was published back in late November early December. We’re pretty excited about the look. It matches our business cards. That’s got to count for something surely.

Science Fiction Tower Power

pythonliving has created her first game. It’s a math game she made originally for her nieces and nephews, but is free for all. Solving simply math problems you can explode spaceships and keep your planet safe from alien invaders. There are many updates to come in the future, and we’ll be letting you know as they come along.

Offti.me Cribbage

There has been a fair amount of work put into the next update for Cribbage. We’re hoping to get it out here in the near future. Expect to see sharing tools, in-game notifications if you opponent has left the game, new tools to access and an updated look to the front page. We’ve got a couple of bugs to look into before we publish the new updates, so expect the update sometime after the Holidays.


Some smaller updates have been made to Curvy in HTML5 to allow for play in IE8 with a plugin download, but the big news is that we’ve started developing Curvy for the iPhone. We’re hoping to get that out soon for everyone to enjoy in the New Year. As this is our first iOS game submission however we are unsure how long the approval process can take.

Kickstarter - aka Betwixt

Voting for the name was complete back in early November, with the winner being Betwixt. We’re starting to work on logo and icon ideas. We’ll be posting them as the various ideas become more finalized. In fact, the next post will be the first idea. We’ll continue posting them until there are enough ideas floating around that we can vote.

Programming progress hit a bit of a block as other projects started to need more attention. We’ve been continuing to work on the commands system to create something that is compatible with the existing set of Vim macros and highlighting definitions. We’ll get you a more in-depth progress report shortly and we’ve got some good open blocks of time for development in the near future as well.

Name Voting Results

As many know, voting for our Kickstarter project took place last week, and the results in! After taking into consideration all of the comments and write in options, we have a winner. We at FlamingLunchbox are pleased to announce the official name of our Kickstarter Open Source project as Betwixt with a total of 13 votes. Thanks to everyone who took part in the voting and forums. Close in the running were other names such as Salsa, WEBedit, Radium and Curie.

Now onto the next part of our project; icon selection. We have started up a forum topic where people can discuss their ideas or images. Please note that we’ll be moderating the images. Our hopes are to start voting on icon options within two weeks, with our poll going out during the US Thanksgiving weekend (see last weekend of November). Once an icon is selected we’ll get started creating and sending out your awesome backer gifts!

Voting for the Text Editor's Name is Ongoing


Voting is now live, albeit more awkward than I’d originally imagined. The interest in the Google Group has been good but not enough of the backers joined so I wasn’t going to ask people to join yet another group: I’m still having to send things through the Kickstarter interface. So a form it is. The link to the forms have been sent out to all who picked the tiers that included voting.

Hopefully we caught all of the names that were brought up. If we get suggestions that look like we might have missed.

Progress Update

It’s been a difficult week to program. On top of other stresses, it seems like everytime I need to reference something the network is down (between sharing the wireless, a router that needs an upgrade and a residential cable modem in a college neighborhood); something about the weather change seems to be giving things issues, though I’ve finally found settings that seem to provide a stable connection.

I’m still plodding along with building a working lexer that can apply Vim’s slightly peculiar approach. I’ve resisted just porting over the Vim code to Javascript as it seems to me that there’s a lot of extra baggage that it would bring. But at the same time trying to build things in a consistent style that will allow for things to be extended in a sensical way makes my brain hurt somedays. I’m getting close, it seems to be working and once I’ve got it done enough to get a screenshot you can bet I’ll be bragging about it here.

Oh, and I’ve integrated Disqus comments into the blog if you click on the entry title.

Text Editor Development Update

First of all, let’s start off with a screenshot of what the rendering test looks like in Chrome.

This is a test in which a 4MB file (UTF-32, so equivalent to 1MB of ASCII) is loaded and rendered. It’s able to render at 60 frames per second using requestAnimFrame(), though given that no updates are occuring this doesn’t tell you much other than it’s not horribly inefficient. It could easily render faster, but requestAnimFrame() intelligently throttles it.

Font Rendering and Text Layout in WebGL

The bulk of my effort so far has been here. I’ve built multiple experiments trying to find a good, simple way to offload as much of the work of rendering the fonts to the GPU. I’ve created a good method using primarily fragment shaders. The text is converted to a texture with each pixel representing a letter. An additional texture is necessary to encode the location of line breaks. The benefit of doing it this way is that a pixel provides 32 bits of storage, so I can do UTF-32 as well as highlighting information in the same pixel. This is as UTF-32 only actually uses 21 bits per character.

I then load up a font texture (which is just a standard bitmap font) which I wrote a little library to create on the fly (next section). A text texture, which is basically a copy of the file contents directly into memory and a newline texture, which maps line numbers to positions in the text texture.

All of this loading stuff into textures means that the rendering can all be done in the fragment shader. The first thought, and what many bitmap font renderers seem to do is to store all of the information in the vertex arrays. This means that 6 vertices are needed for every letter and I’d need to duplicate information a lot. It would give me more flexibility as to positioning, but all of that positioning would have to be done in the JavaScript and uploaded to the graphics card for each change. By using the fragment shader I use 6 vertices to outline the page. Then each pixel determines which letter it is, where in the letter it is and what color that location of the letter is.

Font Loading

Since WebGL inherently has support for nothing but numbers and arrays of numbers bitmapped fonts are the most direct way to get font rendering onto the graphics card. I could have just prerendered a couple of fonts, but then we’d be rather limited. So instead I wrote a small library to load a font and render it to a canvas with even spacing. It can then be loaded onto the graphics card as a texture and used by the shaders to render fonts. It can currently load fonts from either the local system or use any of the web fonts available from Google. There are some sizing issues, and since there is quite literally no font metrics other than width built into JavaScript there is some work to be done here. With some baseline fiddling (as in, a little more up… a little more down) this works for now.

Syntax Highlighting

I was originally split between doing more formal parsing of the text, which would allow for things like auto-completion and context aware editing to be based on the actual state of the code, or the more straightforward but less flexible method of heuristics. The thing is, I was not able to find a good set of formal grammars for very many languages. Vim has a very large set of defined syntaxes and writing an interpreter for these is inline with the other project goals. I can use these syntax definitions with a fairly direct state based lexer. I just need some way to read them in.

Vim Commands

Vim has a very large set of runtime files using it’s internal command system. Of primary interest are the syntax and indent files. Then there are also plenty of macros and all of the extras written by others on the vim site itself. In order to use these though the editor needs to understand a subset of the commands used. For the syntax files this is primarily the :syntax and :highlight commands. However, the editor is supposed to be extensible using JavaScript, so here’s the happy medium: line by line conversion from vim commands to JavaScript.

This has the side-effect of meaning that the command mode for the editor will accept either vim commands (assuming that a conversion exists) as well as javascript macros. This will be done through a simple construct + algorithm:

syntax = { 
  keyword: function( groupName, keywords ){ 
    //function to run for command 
  _keyword_arguments: { 
    //regex mappings to arguments 
  1. Start at beginning.
  2. Is current word a valid variable name? Does it exist in our command dictionary? If so go to next word and repeat this step.
  3. Execute command using provided argument translation.

This should allow the command to run using either the traditional vim syntax: :syntax keyword keywordDefinition thisisthekeyword as well as direct javascript: syntax.keyword("keywordDefinition","thisisthekeyword"). Some of the regular expressions for this will end up being complex, but at least their scope is limited and can be done on a case by case basis.

Using the vim command approach I can use the vim definition files to create lexers for a wide variety of file types.


In reviewing existing JavaScript editors I’ve discovered that all of them use a hack of somekind with regards to key input. The problem is that the way this information is provided to JavaScript is inconsistent and incomplete. The most direct hack is to use a textarea and monitor it for changes. For the moment this is the method that I’ve been using for my development.

File Loading and Saving

Local file loading can be done through Chrome by acquiring access to file:/// urls (this is just a permission). Local file saving is a little more difficult. If we’re willing to restrict ourselves to a sandbox we can do everything, but this will require that files we wish to edit must be moved to a particular location. I’ve yet to start work on particular loading/saving plugins for online services.


I’m not entirely happy with the current rate of progress. I was hoping that the state of libraries would be a little further along for this. Unfortunately, while some WebGL libraries do support some text, they expect this text to be rendered in the JavaScript and not to change regularly. Doing it this way would defeat the purpose of the project. Additionally, with syntax highlighting and text parsing, each of the existing editors have not produced a library solely for parsing. I could take pieces, I’ve looked at the code for each, but each seems to define it’s own syntax for defining… syntax. Using a more established standard instead of reinventing all of this syntax files makes the most sense.

So, sadly, things are taking more of a “not-developed-here” tack than I’d hoped. Of course, there are existing approaches to use for inspiration.

  • WebGL text-rendering library
  • Font to Bitmap library
  • Vim Command Interpreter
  • Vim Compatible Syntax Highlighting

There are some things that I will not have to develop libraries for:

  • Regular Expressions
  • Matrix Operations
  • Syntax Files themselves

What I have mostly done and working is text handling in the WebGL shaders as well as the automated generation and loading of the textures needed by WebGL.

My next target is to get Vim command interpretation working primitively, then loading up the syntax files and highlighting some text.

Looking for Names

Oh, and don’t forget, we’re looking for name recommendations over in the Text Editor Google Group. Here in a week or so we’re going to have to start voting on names.


No comments on the blog yet, so to discuss there’s a corresponding announcement in the group.

Know a Good Name for a Programmer's Text Editor?

Forum: Discussions have begun! Chatter is now underway regarding what to name this text-editor. There are several suggestions in there, and we would love to hear your ideas. The sooner we have a good collection of name ideas, the sooner we can come to a vote about what to name it. The sooner we can name it the sooner we can work on logos. Please check out the flbox-texteditor at Google Groups to add your two cents on it.

Chat Room: Nothing new to report from the irc. Make sure to stop by if you have a question or just want to see what we’re up to. Join us at irc.freenode.net, channel: #flaminglunchbox.

Programming: Lots of good work this week. Nothing solid to report at this point, as there is still some testing to be done on it before any comments can be made. We’re still working on font rendering and layout in WebGL. Robey has stumbled into some undocumented interactions from Canvas and WebGL while working on the text rendering. We’ll give you more details about those interactions at a later date.

Next Week: More work with text rendering and layout. We will also be continuing to discuss name ideas in Google Groups.

Updates on the Text Editor Project

Our Kickstarter project is now fully underway. We are currently determining the best method of loading fonts onto the GPU and figuring out a shader to display text with. At the moment arbitrary fonts, including any webfonts, can be used. Currently we are working on syntax highlighting, trying to determine whether to use grammars or regular expressions to implement syntax highlighting.

We’ve had several visitors in both the irc chatroom and at our forum. In case you’re interested in visiting us you can join us at:

irc.freenode.net channel: #flaminglunchbox

Google Groups: http://groups.google.com/group/flbox-texteditor

Next Week: We will be working more on the shader, in our attempt to offload as much as possible onto the GPU.

More Curvy News!

Curvy has been pretty hot on the docket lately. We’ve had several reviews posted and wanted to share them with you; androidworld, The App Informer, and Scripted Genius. Loads of thanks to the authors for their support! As far as we can tell on the Italian website we’re reviewed well, but that’s based on the Google Translate and the random deciphering of someone with partial ability in Spanish. One could say that it’s not the most accurate way to understand another language.

Other News * Soon to come, Curvy for iPhone. As we’ve not developed for an iOS previously, please expect a slight delay as Robey begins the process of learning another programming language.
* If you were a backer or simply interested in our Kickstarter project, you can follow along with our company projects and Kickstarter progress here on the FlamingLunchbox blog.

Until next time!