[Openmcl-devel] mac filetype association

Arthur Cater arthur.cater at ucd.ie
Thu Feb 4 11:17:34 PST 2016

Thank you Paul, you generously give an enormous effort to helping out.
I very much appreciate it, when I succeed I will let you know - privately.


> On Feb 4, 2016, at 4:41 PM, Paul Krueger <plkrueger at comcast.net> wrote:
> On Feb 3, 2016, at 2:19 PM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>> Thanks Ron and thanks Paul,
>> Yes I’m on a mac, sorry I thought I’d said but I see I didn’t.
>> Plenty of homework for me huh. I’ve barely started.
>> Can anyone hint where I’d find how it is arranged that a double-click on a file
>> causes ccl to invoke the Hemlock editor? I actually want a development system
>> but there’s a particular kind of file I’d like treated other than by Hemlock.
>> (Yes I’d done the Get Info thing, I’ll look gratefully at what Paul provided)
>> Arthur
> To understand all that happens when you double-click you have to understand how the OS X runtime works. Apple provides a wealth of information about this in their developer library (https://developer.apple.com/library/mac/navigation/index.html), but there is so much that it can be difficult to find exactly what you want and you may have to read several things to get a real handle on exactly how it works.
> The simple explanation in response to your question is that when you double-click on a file the runtime determines what class should be created to represent it by information that is in the info.plist file in the "Clozure CL64.app” bundle (i.e. the CCL IDE executable). To see that file you first need to have Xcode loaded on your system. Assuming you have that you can ctrl-click on the app and select “Show Package Contents”. Then open the Contents folder and you’ll see the info.plist file. Double-click that and Xcode will open and show you the contents of that file. You can even edit it, but I wouldn’t advise that unless you know what you’re doing. 
> Inside that property list you can click on “Document types” and then on “item 0” and you’ll see an entry labelled “Cocoa NSDocument Class” withe a value of “HemlockEditorDocument”. That is the name of the class that will be automatically created when a file with a .lisp extension is double-clicked (other extensions are shown in different document type entries). CCL has defined an objective C class of that name in cocoa-editor.lisp. Actually CCL defines the class with the Lisp name hemlock-editor-document and some name translation occurs when that class is instantiated so that the runtime knows that class by the name HemlockEditorDocument. Note that this is an NSDocument subclass. After that class instance is created the runtime will invoke the objective-c method readFromUrl:ofType:error: on it to actually read the data out of the file and do whatever it wants with it. That method for the hemlock-editor-document is also defined in the cocoa-editor.lisp file. 
> In my developer tools code, I do things slightly differently. I always store a representation of lisp data (i.e. a set of lisp class instances and slot values) as one big NSData object. On open I allow the default version of readFromUrl:ofType:error: to run and eventually it calls readFromData:ofType:error: which I override in order to unpack that NSData instance and translate it into appropriate Lisp class instances and their slot values.
> My developer tools support creating your own file types within the IDE environment. You can explicitly open them there. And you could theory create a stand-alone extension of standard CCL that just adds your file type by creating a new application and beginning with a copy of CCL’s info.plist and then adding your own information to it. 
> To allow you to double-click on a file and have the standard CCL IDE open it and do what you want with it you would have to edit the info.plist in the CCL bundle so that it instantiates a class that you specify when a file with your new extension is double-clicked. It’s possible that OS X would detect that change and not allow you to run the IDE. I suppose the other alternative is just to add your code to the CCL source, modify the info.plist and then rebuild the CCL IDE. Then it would do what you want with your new file type as well as doing what the standard CCL IDE does. You might also want to add new menu items to support opening and closing and other manipulations of your new files, but that’s another topic (also supported in my contrib).
> That’s about as simple as I can make the explanation. Good luck.

More information about the Openmcl-devel mailing list