I'm in the middle of putting together a script that manipulates an OmniGraffle document and saves the result of each progressive manipulation as a PNG. That's all working fine, but at the end of process, I want to close the file without saving the changes.
Naturally, I reached for the "revert" command. Except that "revert" doesn't appear to be a command on Lion. I tried "close saving no," but since it was autosaving as each manipulation was made, that didn't work.
Of course, I can simply leave the document open and manually revert it. Nevertheless....
Am I missing something? Is there truly no way to programmatically roll back changes made to a file using AppleScript on Lion?
Update: it appears to be worse than I expected — on a volume without permanent version storage, at least — after many manipulations with AppleScript, "Revert Document…" was no longer even available in the File menu.
I can only think of a workaround: since you're not interested in keeping those intermediate versions anyway, you could:
make a backup copy of the file prior to opening it in OmniGraffle
do your changes + PNG exports
close w/o saving
overwrite the file with the backup copy (and delete the backup)
Related
I need a custom file format for my application and I thought that I could make a superset of PNG. macOS shows previews of regular PNG files (and APNGs with a .png extension) in Finder. I want macOS to show a preview of my file format even though it doesn't have a .png extension. I need to tell macOS that files with a .px2 extension are valid PNGs that can be decoded by a regular PNG decoder.
I've been reading this page trying to find the right set of keys to use but I'm not having any luck. I thought that NSExportableTypes might be the answer but that doesn't seem to be it.
To test this, I'm changing the extension of an APNG file from .png to .px2. I realise that I could just use the .png but I think that could be a little confusing (both for the user and the OS).
There's a slight chance that what I'm trying to do is impossible!
I think you may be looking at 2 different problems: one is the OS recognizing the file type and linking it to your application, the other is being able to show the preview.
The latter is going to be highly dependent upon the way that the Finder's in-built QuickLook plugin works. You may need to just implement one of those yourself.
Debugging these kinds of issues can be a little tricky, because you need to make sure macOS has assimilated your NSExportableTypes. One quick check is to drop into Terminal and use mdls <file of your type and extension> and see what the kMDItemContentType and kMDItemContentTypeTree are for your file.
If it's not recognizing the extension at all, make sure it's been re-loaded by using lsregister which is hidden away in the LaunchServices Framework of CoreServices.
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister to get the man page
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -lint -f <path> to force reload of your application (the -lint) adds more detail on errors while interpreting the entries.
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -seed will reset the daemon and re-seed the data from the default applications and library locations.
I have been working with two terminal windows in my Mac (dev/prod), both had shown the commands and results history (scrolling up) for the last 6 months of work, which was very helpful to run periodic commands and to check past errors.
Yesterday I turn off my mac and closed both terminal windows manually, but today when opening the terminal it has no history at all. There is a way to recover the windows with all the history for past commands and their results?
I know there is a .bash_history file but it only shows commands typed but not the results.
Thanks in advance.
Bash's history only store executed commands, not their output, and only a limited number of them (usually 500, as defined by environment variable HISTFILESIZE). This won't help in your situation.
From what I can see, it appears that Terminal store save window's state (including console history) inside directory /Users/<user>/Library/Saved Application State/com.apple.Terminal.savedState/. Files in this directory are modified in real time whenever new events occurs in the terminal window, and unless I am mistaken, should be included in Time Machine backups. Therefore, it seems that if you can restore files in this directory from some former backup, you should get back your history. You could even try some "file undelete" tools in that directory, though these tools are rather rare on OS X.
The procedure for this should be that you first quit Terminal, then restore the whole directory (for example using Time Machine), then simply launch Terminal. These saved state files use a custom binary format, that you can't be read otherwise than by the Terminal program itself.
By the way, it might be worth mentioning that you can, at anytime, save the content of a Terminal window to a text file, from the Shell menu. You might consider doing it periodically, in the future, given that your terminal's history appears to have some significant value...
if using zsh check your /etc/zshrc for the history file location, mine has
# Save command history
HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history
HISTSIZE=2000
SAVEHIST=1000
also check your ~/.zshrc incase the defaults for these have been changed
Xcode appears to save files atomically when you save. This seems best practice but when you are listening for file changes atomic saves can dodge a kevent file status change. Im using a library called vdkqueue that listens for file changes. This will work successfully when a make a save on the target file using textedit and sublime text. However when I save this file using xcode the notifcation will not fire. This is due to xcode making atomic saves so a temp file is made on save and the link to the file is lost. Is there any way of disabling atomic save in xcode, or even a mac wide setting would suffice.
If you are observing a file, that might not work (because the file you are observing is never actually modified). Observing the containing directory should work reliably.
I use a combination of ForkLift and Textmate to edit files on a remote server via FTP. it works really well, except for one little quirk: when I hit save on Textmate, Forklift saves the file, and then Forklift takes the focus. So, every time I hit Save on Textmate, I have to wait for Forklift to save, and then hit Cmd + Tab to return to Textmate.
Is there a way this can be avoided? I.e. is there a way that when I hit Save on TextMate, the focus does NOT get taken by ForkLift?
And, by the way, I tried to edit the files with TextEdit instead of TextMate, and the behaviour did not change. So, I'm guessing this is either a ForkLift issue, or a Mac issue.
Either way, help would be much appreciated.
Just tested with Forklift Version 2.0.6 (315) and couldn't find the behavior described by you. The focus wasn't lost by saving the document within Textmate.
Maybe 'already' fixed?
On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. Is that right?
There are a few factors which may affect this.
First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.
set directory^=$HOME/tmp
This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.
Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.
Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.
let g:loaded_matchparen = 1
If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.
Finally, if none of those help you can always copy the file locally and edit it.
Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"
It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".
Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".
Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away.
Then CreateFile on "\server\TestTool\foo" which works right away.
Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.
WHY is it trying bad names for the server and the root directory??? What madness is this?
I fixed this issue after setting HOME path by force in advanced system settings.
(Your current HOME path would be a network directory.)
Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables
Press "New..."
Variable name: HOME
Variable value: c:\Home\ **<-- Type your home directory**
A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc
autocmd BufReadPre //* :NoMatchParen
You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.
Having a similar issue as David Anderson, but no solution yet.
When loading \\ServerName\A$\B\C\File.txt Vim will do:
Open \ServerName\A$\B\C\File.txt
Then it does many loops like:
CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
QueryDirectory \ServerName\A$\B
QueryDirectory \ServerName\A$
QueryDirectory \ServerName\A$\B\C
QueryDirectory \ServerName\A$\B
To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.
Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.
I've no plugins installed as far as I know and followed other tips to speed up network shares loading.
Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.
I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.
Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:
With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:
set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)
For local files that's ok, but for network files this is way too slow.
Now my fix:
set titlestring=
Same effect (filename first), but now gvim runs very fast for remote files as well!
BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.
It all had no effect for me. But the funny titlestring...