#musicbrainz-devel

I wonder what counts as open

I can see it in finder, but I'm in one of the parent directories (using the tree view)

yeah

if I use the tree view like that, it doesn't count as open

only when it's the directory in the window title, I guess

Wow. That sounds like some FS breakage. :P

oh, it's not that I have the window open. It's whether I drag the file into Picard specifically, or just the folder that contains it

as long as I don't actually select the file, it triggers the bug

it gets weirder every minute ;p

Hmm. I thought Linux filesystems used NFC to store filenames.

most linux software uses UTF-8 with NFC, but there's no requirement for that.

Well, tend to use.

the same text encoded with NFC and NFD on linux could create two completely separate files on the FS :)

Could, yeah.

anyway, http://paste.pocoo.org/show/454212/ fixes it for me

linux filenames are just series of bytes

though I wonder if that's ideal if someone is saving to a filesystem other than HFS+ on darwin

I guess it wouldn't cause any problems

bitmap: good test would be a fat32 external drive

but if I remember correctly, the HFS normalization is not exactly NFD

it has some specifics

can't remember what's different though

Oy. Reading an article about some guy encouraging using normalized filenames and having FUD and misinformation thrown at him.

One guy responds that one of the advantages would be that "a" and "A" would be equivalent. Guy obviously knows nothing about normalized forms. :P

hmm. wikipedia's reference link for the HFS+ normalization is dead :/

Other people saying it would break 40+ years of Unix programs running on Linux. (If they're treating filenames a bytestream, how will normalizing filenames break them?)

*as a

hmm. that doesn't actually say any differences.

I remember testing nfc/nfd on fat32 in osx

but I don't remember what happened :/

no usb sticks?

most modern Linux applications use UTF-8 encoded NFD, but make no particular requirements for normalization when reading files, and can even read files using other character sets (it'll print junk characters and a note saying that the filename wasn't properly encoded)

I have three or four USB sticks but they always dissapear when I need them

kepstin: nfd? it's always been nfc for me

aha, found it

er, NFC. yes. the names are too confusing :)

s/dissapear/disappear

I might even still have my test files on there

hehe

I do :D

I don't know why, but for some reason I prefer NFC for filename storage. One of those totally insane preferences.

NFC uses fewer bytes :) save a couple bytes per filename.

Heh, another article says that all four normalization forms should be tried when opening a file on Linux.

a) That won't work. Who says it's normalized?

b) NFKC/NFKD? Really? No.

it doesn't matter what normalization form something's in when you're just /reading/ it...

as long as the encoding's correct, just read it and re-normalize it to what you want to use internally.

Especially if he's assuming something would be stored in NFKC/NFKD.

To hell with equivalence!

on fat32, osx reads nfc filenames, but displays them as nfd. nfd filenames appear if there's no nfc version, but vanish when you try and select them

so you can only use nfd with hfs+ and nfc with fat32

to be awkward

Clearly.

Now, someone find me a nice Android notetaking app with both keyboard input and a draw function. :P

nikki: so OSX lets you write NFD filenames to fat32 but they don't work?

I suspect it automatically converts them to nfc

I only tested creating the files in linux and looking at them in osx

well, when storing filenames on fat32, it has to reencode them to legacy windows 'codepage' character sets, iirc...

ah

so weirdness may result :/

I believe that there's a codepage for UTF-8, though.

I mean... I originally used a fat32 external drive with osx and never had any problems with picard

then I used an ext3 formatted drive mounted via a vm and didn't have any problems either (it seemed to automatically convert to nfc there too)

nikki: if I made an app bundle with that patch applied, would you be able to test saving to the fat32 drive? :)

sure :)

hmm. so there is, codepage 65001 is UTF-8.

luks: so do you think that patch is okay to commit?

if nikki agrees with it :)

okay, I'll make this app bundle first

nikki: http://users.musicbrainz.org/bitmap/MusicBrainz... sorry that VMWare was so damn slow >:(

no problem :)

I do not like python for loops. I do not like them, Sam-I-Am.

huh, what about them do you not like?

I don't like that I have to go out of my way to iterate over a list and keep an index on hand.

if you're using enumerate() you shouldn't have to keep track of an index

I'm matching something based on regex. I want to modify that match based on a function call and then replace it. There may be more than one match.

So to iterate over all of the groups in the MatchObject while still being able to get start and end indices, I have to keep track of index.

I probably shouldn't say anything without seeing the code, then

bitmap: it writes a precomposed character in fat32

bitmap, I'll pastebin it in a bit. It's turning out a bit dirtier than I'd like, but I blame that on me not knowing python too well.

nikki: ah, thanks for testing that!

I'm glad it does that instead of completely breaking

heh, and finder still shows it as nfd

I wonder if it *always* provides nfd filenames to programs

nikki: let me know if you're happy with the patch later too (i.e. no unintended side effects)

Oh gdi... I can't do m/foo/g with re.search()?

what does m/foo/g do?

Match all instances of foo.

re.findall?

I want the MatchObject, though.

finditer, apparently.

more sad times: Error downloading http://musicbrainz.org:80/ws/2/release?release-... - server replied: Bad Gateway'

I keep trying to use semicolons. :P

you can if you really want, it's just a waste of space ;)

Okay, this isn't going to be exactly pretty, but it'll work.

Yay. My guess mix case script works. :P

So ugly.

Got some tweaking to do, but it'll all work out eventually. :P