Usually when editors save files, they delete or truncate to 0, thus freeing allocated space, and then write, which allocates new space. This results in the filesystem putting the data in a completely different physical location. So your idea might not work.
You can get the physical location of a file using
hdparm --fibmap, and then use
dd to read that physical location directly. I've described this process in a different context here: https://unix.stackexchange.com/a/85880/30851
In your case it's more likely you need the general approach for finding textual data... something like:
strings -n 12 -t d /dev/partition | grep -F 'text snippet'
strings will look for consecutive ASCII data (also supports some other encodings, not sure about UTF-8. If it's code or English you won't need it) and it will also print the offset where it was found.
text snippet should be an exact, unique text sample you remember being in the part of the file you're looking for [in a single line]. (If you don't know it exactly, you could grep with regular expressions instead.)
-n 12 is the minimum length that
strings will look for.
12 should be the length of your
text snippet. This parameter is optional, if provided it might help
strings | grep to go a little faster.
It will take a long time to read the entire partition but if successful, you'll have an offset you can feed to
dd to grab the general area and then remove stuff that does not belong.
I haven't done anything in that directory since
If your directory doesn't happen to be a mountpoint... most filesystems don't really reserve space "per directory" so... any and all writes in the entire filesystem might overwrite the bit you're looking for.
In a data recovery situation, you usually switch the entire thing into read-only mode.