Over the past few weeks I’ve been testing a fairly major change to Logger-TXT OSX that adds autocomplete to the type and project inputs. I’ve spent a while sitting on this change as to make it happen, there were some large, behind the scenes, changes that needed to be made. There’s a few bugs that were caught, like adding extra blank lines to log files, that were uncovered throughout this process.
Autocomplete using OSX’s default system
I looked around for an autocomplete library for Objective-C for a little while before remembering that OSX has autocomplete built in. Just open TextEdit.app, start typing and press ESC. An autocomplete menu pops up with suggested words based on what you were typing. I looked into this and found out that you can provide your own suggestions for when autocomplete is triggered.
Speed and caching metadata
Since the metadata autocomplete data is read from potentially very long log files, it was very important to ensure that the speed of the app wasn’t impacted. After all, the main goal is to get the UI out of your way as fast as possible so you can get back to what you were doing.
Metadata is processed on initial application launch so that when you’re actively using the application, there’s no lag while it fetches possible completion options. The log file is searched and two arrays are created, one for types and one for projects. As the application is used, dictionaries are also used to cache results by typed letter. In theory, the autocomplete should get quicker and quicker as it completes more data. I’m using NSMutableDictionary for this cache though it’s possible I’ll change this to NSCache down the line. I just need to understand better the differences and opted for sticking with hat I knew for now.
Current issues with autocomplete
Right now I’m investigating an odd bug that seems to be a system level bug where
I’m not getting any autocomplete results for the letter S which introduces
noticeable lag. Even though Logger-TXT presents results for S, the system
level autocomplete runs first and since it can’t find any results for that
letter, it beachballs for a second slowing down the whole process. This is an
ongoing issue which is more difficult since it’s not limited to my application.
The same issue pops up in TextEdit.app for the computers I’ve tested on so far.
Below is a GIF of the autocomplete issue using TextEdit.app in plain text mode.
For some reason, S does not work and is the only letter that doesn’t work for
me. I’ve had mixed results on others’ computers with some completing it and
other not.
After using this autocomplete for the past few weeks, I’m pretty happy with it as it means less typing and less time spent within the Logger-TXT interface. In my eye, this is what GUI based apps are for. They can provide features that make things quicker for the user. Autocomplete could be done for the shell script but that would be heavily dependant on what environment the user is using, like ZSH vs BASH. Eventually I’ll write autocompletion for the shell script but for now, this GUI will have to do.