How often do you use your Caps Lock key? I’ve had it remapped to act as another Ctrl for years, but never actually used it as such. So how about using it for something useful, like keyboard layout switching (e.g., US <-> Bulgarian)?
It’s very common amongst the people I know to map left Ctrl+Shift or Alt+Shift to change keyboard layouts.
However, this can often get in the way especially when working with editors such as Vim or Emacs – one moment you are typing with Latin letters, next you have magically switched to Cyrillic. You then find yourself having to shift from editing to sorting out whatever has gone wrong.
One more thing. The keyboard layout indicator in your OS – doesn’t that just waste space? Call me minimalistic, I prefer my screen free of clutter.
How to use the epic keyboard layout change mode:
Open System Settings. In Unity or Gnome Shell just look for it in the launcher.
Find the Keyboard applet.
Select Layout Settings.
Select Options… under Layouts.
Customise:
Caps Lock key behaviour: leave at Default.
Key(s) to change layout: tick Caps Lock only.
Use keyboard LED to show alternative layout: tick Caps Lock only.
…and there you have it. Whenever you want to use your alternative layout, press Caps Lock and your keyboard LED indicator should light up indicating you are now typing in a different language.
I just need to find a good use for Num Lock now…
Does this work in other OSes? Let me know in the comments below.
I have been using Ubuntu since 10.04. I am running 13.04 at present and have undergone numerous distribution upgrades and not a single re-install. As a result, there is quite a lot of cruft accumulated by now. By cruft I mean packages I have had to install in order to complete a particular task and never got around to cleaning them up afterwards. For some odd reason, I still keep the projects that depend on them around so uninstalling is not an option.
A fair share of those packages also install services. For example, [sudo] apt-get install -y apache2 sets up a web server which is started on every boot. MySQL, PostgreSQL, MongoDB, etc. all come with startup services which are enabled and run on boot by default (something you would want on a server).
As time went on, boot times had increased and the overall performance of the PC slowed down considerably. You can see how many processes are running at any given time on your machine by using ps -e | wc -l. Most of those would be system process (init, session handling, tty, etc.), however many are also started on boot and you most likely don’t need them running all the time.
Ubuntu uses Upstart to start tasks and services during boot… but that is not all. There are packages that use the old System-V shell initialisation scripts in /etc/init.d.
After searching for a while and getting nowhere, I reverted to reading the Upstart documentation in order to find the best way to stop a service. It turns out there is a quick way to keep the job files around (in case you want to start something manually after logging in), but prevent the service from running at boot.
I came up with a combined script which deals with both SysV-style scripts as well as Upstart jobs. The script will attempt to disable a service while preserving the initialisation scripts so you can still [sudo] service name start when you need it.
My results were more than impressive. On a system with an SSD disk my boot times improved noticeably which was unexpected. I had some of the most common packages for a developer installed so I used:
Download using the raw link, chmod +x service-disable.sh and put somewhere on your $PATH. /usr/local/bin/ is usually the right place.
NOTE: Be extremely careful what services you disable. Make sure you are absolutely certain the service being stopped is not essential for the operation of your PC.
Let me know if your boot times improve.
Feel free to post a (common) service in the comments below if I have missed it in the post itself.
If you are running the latest Ubuntu this Summer and are trying to configure your keyboard shortcuts to use the Super key, you may be out of luck.
Up until recently, I was quite happy with my Super+E key launching nautilus in my home directory. I went to Keyboard Shortcuts and played around with the configuration and then restored my original values. To my surprise, I could no longer open nautilus with the key combination Super+E.
It took me all evening to find a solution and as it turns out, there are several issues at play:
If you haven’t mapped your Super key yet, you are advised to do so before you continue.
There is a long standing issue with multiple regressions where Unity is blocking any other apps from receiving the Super key if the Dash is configured to open just by using that key. You should set it to a key combination, e.g., Super+L or similar.
So, at the end, it turns out it’s gnome-settings-daemon being faulty. To get the updated version, which should fix the issue on Ubuntu 12.04, you need to accept packages from the proposed archive.
Start by making sure you have your system up-to-date:
To enable the proposed archive for Ubuntu 12.04 go to Applications→Ubuntu Software Center→Edit→Software Sources→Updates and ensure that precise-proposed is ticked.
You should also make sure to suppress updates you are not interested in as you may unnecessarily install an unstable package. To opt-out of automatic updates from the proposed archive, create a new file under /etc/apt/preferences.d/precise-proposed and put the following inside it:
What the above file does is to ensure the proposed packages are lower in priority than their stable versions from precise-updates.
Before you continue, make sure you don’t have any package updates. If you do, it means something was picked up from the proposed archive and this should not have happened:
$ sudo apt-get update
$ sudo apt-get dist-upgrade
# Confirm you have 0 upgrades.
Finally, install gnome-settings-daemon from precise-proposed:
Unfortunately you would likely need to restart the system for changes to take effect. In my case I killed the daemon, but in the process it didn’t reload with the correct settings and I experienced a nasty crash.
I hope changes would be pushed to stable channels soon which would make this post obsolete, but in the interim, enjoy your Super key combos working again.
tl;dr; This post deals with writing very simple parsers for nested data using recursive regular expressions.
There is a very good reason why regular expressions are called that – they are regular. You can get a lot done with them, but if your data has a complex structure, you’d often be advised to use a parser.
A good example is processing data where parentheses can be nested. A simple regular expression:
/\([^\)]+/
fails quickly when a nested () pair is encountered.
PCRE (the regular expressions engine behind preg_* functions) has support for dealing with those cases where you need to recurse and repeat the pattern.
For example, a very simple CSS parser would need to balance opening { and closing }, i.e., taking into account @media queries also enclosed by a {..} pair. Let’s assume this document:
A non-greedy regular expression like /{.*?}/ would fail as it exits as soon as a closing } is encountered resulting in the following captured groups:
array(0=>'{ color: #888; }',1=>'{ body { color: #333; }',# NOTE: the first opening { is not balanced.2=>'{ color: blue; }',)
To deal with balanced pairs, we need a way to descend into a pair and repeat the pattern. In pseudo Basic-like regular expressions code this would mean:
10: expect an opening '{'
20: read until
21: '{' or '}' is encountered
22: OR end of data, goto 50.
30: if '{', start over; goto 10.
40: if '}', goto 50.
50: expect a balanced closing '}'
PCRE supports (?R) which does exactly what is illustrated above: it repeats the whole pattern recursively.
Let’s go back to the non-greedy pattern (and the sample CSS document):
/{.*?}/
and modify it so it starts a new group for each nested pair:
/{# find the first opening '{'.(?:# start a new group, this is so '|' below does not apply/affect the opening '{'.[^{}]+# skip ahead happily if no '{' or '}'.|# ...otherwise...(?R)# we may be at the start of a new group, repeat whole pattern.)*# nesting can be many levels deep.}# finally, expect a balanced closing '}'/
Let’s convert this to an inline pattern and run it against our sample CSS document:
This is a great start to a simple CSS parser. You can now iterate over the results and run the expression again until you get a flattened list of all the properties.
Note again (?R) repeats the whole pattern. If you want to match all @media queries for example, you’d need to make sure the group is optional:
<?php# [...]$pattern='/(?:@media[^{]+)?'# @media is optional, e.g., when we have descended into it..'{(?:[^{}]+|(?R))*}/s';
Why not a parser instead?
Parsers can be much more complex than a one-line regular expression. You’d most likely also need to include a dependency in your project.
If all you need is a simple solution then I say try and use recursive regular expressions first. I have been hacking on a tool to merge @media queries produced by Sass and I got the job done with no complex parsers or dependencies involved.
One of Vim’s biggest strengths IMHO is it’s quick access to the search and extended support for regular expressions. It can be very frustrating at first as the syntax for the latter doesn’t follow Perl or anything else I have used (grep, etc.), but once you learn more about it, you’ll start to appreciate it.
A feature I recently discovered was negative lookahead. This can be useful in cases where you are looking for a particular string, but only if it’s not followed by another. In my case, I was looking for all references of include, but since this also matches Ruby’s include?, I wanted to exclude and not report it. The search expression I used was:
/include\(?\)\@!
There are all sorts of goodness in the Vim documentation on patterns. If you are using Vim on a daily basis, it’s worth spending a few minutes to learn what’s available. Your next search & replace could save you hours of editing or recording and getting a macro just right.