Argument completion should improve developer’s everyday life. Everywhere. That’s why I decided to have argument completion in The Console. To have the best thing – I want scriptable argument completion with already built-in filesystem paths completion.
Giving a few words about the process between hitting a TAB key and performing the magic.
The Console is an app which typical usecase fits within running a single instance. That’s by design. However, we sometimes forget to check whether some the app is waiting for us in the background and try to launch them. That’s when disaster happens. Two consoles placed on top of window and reacting to same hotkey? Cannot be!
Here’s a short story about preventing from having multiple instances of same app made in Java. There’s a note about communication, too.
JavaFX punched me in the face with a feature which I consider as a kind of general over-assumption and as a bug in The Console. When TextField is refocused through other event than click then it auto selects it’s whole content. I want my previous selection or caret position.
A workaround/hack/fix is introduced in this post. Oh, by the way, there’s a bug report.
When I use git VCS, I simply work in a shell. Even more complicated branching can be resolved using git show-branch command. But this time I wanted to compare that again with gitk. Since I work on Windows I use babun which is based on Cygwin. And we know that Cygwin can actually launch gitk properly, right? Well, yes – when you configure it.
This time I present a filesystem module which mimics the simplest cases of shell commands: ls, pwd, cd, cat. The module showcases module commands, scoping, Storage and onload/onunload events.
In previous posts (linked in the Summary) I discussed a topic of implementing modules in The Console. This time I’m going to describe my first step in this direction.
Currently The Console supports simple scripts – one .js file is one script, i.e. scripts/info/currency.js is just a currency command.
But that’s not enough. I want the modules, too. Here’s how I make them real.
The Console started as a small side project that was supposed to automatically perform things I do often manually. Checking exchange rates of currencies is one of amongst those repeated actions.
After a long research I’ve found a site that helps with compiling Xtend using Maven – http://www.eclipse.org/xtend/download.html – pretty straightforward, isn’t it? However, it lacks a few more things.
My goal was to compile and package Java 8 project together with JavaFX, written mostly in Xtend (in place of Java) with unpacked libraries into one Runnable JAR. In the end I’d like it to be compatible with e(fx)clipse IDE. Here’s how.
As I noticed in previous article about script management I’d like to support script sharing in The Console. This topic automatically brings idea of supporting Node.js modules. Nashorn doesn’t provide any kind of module import/export mechanism like CommonJS. However, it’s doable to provide custom require() and module.exports. But is it possible to really import Node.js modules or anything from npm?
Read-eval-print loop is quite useful kind of tool that simplifies both learning and trying some short code ideas. REPLs are always very specific – they can be used for evaluating programming language statements, some math calculation, database management, file processing and so on. In The Console I decided having all those things and even more – way to incorporate custom REPLs.
However, idea have grown much more than expected. In this post I explain what’s the big deal to talk about which shows why the development have currently slowed down.