Future archaeologists will be racking their brains trying to figure out what that cup rim tool was for.

With more testing I found that the context menu position depends (perhaps solely) on whether my mouse pointer is on the left side or the right side of the horizontal half of the rightmost monitor: if you imagine a vertical line dividing the rightmost monitor’s display area into two equal-sized halves, right-clicking anywhere on the left side of that line brings up the menu on the correct display, whereas right-clicking anywhere on the right side brings it up on the wrong display.

(That is why I first made the mistake of thinking links weren’t affected: the ones I tried first just happened to be on the left side.)

Unfortunately I don’t have a third display to verify that I’m really seeing a different manifestation of the same bug as Nathaniel, of one that depends on the monitor count.

I’m in a UTF-8 environment and a lot of my directories’ names have characters above ASCII in them. For many of those it’d be natural to assign bookmark names that also have characters beyond ASCII. For example, my ”Desktop” directory is localized as ~/Työpöytä, and I’d like to name that bookmark ”työpöytä”.

jani@saegusa:Työpöytä$ s työpöytä
bookmark name is not valid

This fails because bashmarks validates names using the regexp /[^A-Za-z0-9_]/. It’s simple enough to patch to account for the 6 additional characters in my Scandinavian locale, but bashmarks also derives an environment variable name from the bookmark name, and apparently Bash does not support UTF-8 for those:

jani@saegusa:~$ LC_MESSAGES=C export DIR_työpöytä=$HOME/Työpöytä/
bash: export: `DIR_työpöytä=/home/jani/Työpöytä/': not a valid identifier

There may be other obstacles as well, those are just the two I could find at a glance.

Obviously I can work around this by not using UTF-8 in bookmark names, but it needlessly increases the mental effort required to recall the names and also the chances of name collisions.

one day it will happen

Tätä videota!

Ihmettelinkin että oliko se mennyt sinulta muka ohi. Joo, ei minullakaan tuon syvällisempää selitystä sen poiminnalle ole, mutta onhan se hieno otsikko. Toisaalta huomaan itsekin monesti vaihtavani kieltä postauksia otsikoidessani, ja se on vähän sellainen ”siitä missä aita on matalin” -kikka. Jos kirjoittaa vaikka saatananpalvojista, niin ”Saatananpalvojat” tuntuu (toisinaan) ylitsepääsemättömän banaalilta otsikolta. Mutta jos kyse on vaikkapa ruotsalaisista saatananpalvojista, niin saatananpalvojat-sanan kääntäminen otsikossa ruotsiksi antaa sille heti ylimääräisen ulottuvuuden kuin ilmaiseksi.

”Dein ist die Hand die verletzt”, eivätkös ne opet siellä jotain manatessaan noin sanoneet? Siitä se otsikko oli repäisty.

It’s not the same as #590829 after all: despite the similarities, the recipe given at #590829 does not reproduce the issue for me.

Tab completion of directory paths containing single quotes is broken like so:

$ mkdir -p ”a’b/c”
$ cd a\’b/ # pressing tab won’t complete the ’c’ dir

as opposed to:

$ mkdir -p ”de/f”
$ cd de/ # pressing tab here completes the ’f’ dir just fine, to ’de/f/’

I initially thought this was Bug #1485777, but the reason I’m not so sure anymore is that for me, a manually appended \’ does not disappear (unlike for the reporter of #1485777). This does however also seem like a regression back to the issue of Bug #590829.

Just adding a note that this does still occur under 14.04, to which I recently upgraded. Naturally this was to be expected, given that the issue first occurred after switching to the Trusty HWE pack in 12.04.