I made a gadget that listens to events from the GtkTextBuffer and tracks the state internally.
Then we use a custom GtkSourceGutterRenderer in to render the changes in the gutter of the GtkSourceView.I've been hacking away like crazy since my last update. So much so that occasionally I forget to leave the house. Focus has still been primarily on the editor, since that is where I'll be spending most of my time during the day.
It's no secret the first language I'm focusing on is C. This is both because I really enjoy C and that I want it to write Builder in Builder. An added benefit is that a lot of other curly braced languages can reuse some of this code (eventually).
If you take a look at how VIM does auto-indention, you'll quickly come across a 3,000 LOC C function with a couple thousand lines of accessory code. What I've put together for Builder isn't quite as robust yet nor is it as configurable. But we will get there eventually. The main insight from the VIM code is how you walk backwards to discover your context. This is how the indention is performed here as well. (I'd like to change how this works eventually to use a very relaxed tokenizer, but that will have to come later).
Right now, this is only really tested with GNU style C (some people love, many people hate). Eventually I'll get to fixing it for more generic formats like K&R. If you file bugs, it will allow me to be more surgical with my time.
The C auto-indenter currently tries to handle:
for, if, else, else if, switch, case an goto labels.) in a function declaration, the arguments will be reformatted to GNOME style where the Type, *, and names are each aligned. This saves me so much time.( in function calls or declarations, automatically add it if not typed.* at the beginning of the line in multi-line comments./.There is still a lot more to do here, but I'm generally pretty pleased with using it so far. The corner cases are where things get complex, but I'm progressing.
Here is a short example of auto-formatting function parameter lists.
In previous prototypes, I relied on git diff --minimal to tell me what has changed in the editor.
This was handy because it was always correct with what the git commit will see.
However, it resulted in lots of subprocesses being created that in my opinion are unnecessary.
You also end up implementing anti-hysteresis so you don't shell out too often.
I made a gadget that listens to events from the GtkTextBuffer and tracks the state internally.
Then we use a custom GtkSourceGutterRenderer in to render the changes in the gutter of the GtkSourceView.
There are essentially four states, each with slightly different rendering in the gutter.
Representing deleted ranges is a bit tougher to both track and render in a useful way, so it's not high on my priority list.
Don't worry, keybindings will be configurable, although currently you need to edit src/resources/keybindings/default.ini.
<Control>E scrolls downwards in the editor.<Control>Y scrolls upwards in the editor.<Control>L selects the current line.<Control>Home jumps to the beginning of the buffer.<Control>End jumps to the end of the buffer.All default accelerator choices are up for debate. Although I'll probably wait to have that debate until a lot more of the system is implemented.
There is a live markdown preview now when you are editing a markdown file.
<Control><Alt>P will bring up the split-view with HTML preview.
Currently this is using a modified GsMarkdown from GNOME Software.
It was purpose driven so lacks some of the features we will need to support.
I hope to move to CommonMark in the future for this.
One slightly annoying thing about this for large documents is that every edit causes the preview to scroll back to the top of the file. I'd like to see that change but requires some plumbing to track the cursor position in the output HTML.
I just landed the framework for global navigation.
VIM users are likely familiar with the <Control>O and <Control>I sequence to move to your last save point.
Builder does the same (with the same key combo for now).
However, where this get's interesting is that any workspace within Builder will be able to use this global navigation.
That means you can jump between the documentation you last read and where you are editing a file with a single keystroke.
Eventually, this is going to be one of the core features that makes Builder a pleasure to use. I anticipate it will go through lots of refinement as we figure out what that is.
Just a small tool to remove trailing space from the editor. Sébastien Wilmet had a great idea of only trimming modified lines when saving the buffer. This would help avoid those pesky patches that change half the file every time you save. Some time needs to be spent thinking about the right way to plumb this.
-- Christian Hergert 2014-09-25