Re: command to save as .m file
- To: mathgroup at smc.vnet.net
- Subject: [mg113743] Re: command to save as .m file
- From: John Fultz <jfultz at wolfram.com>
- Date: Wed, 10 Nov 2010 06:28:14 -0500 (EST)
On Mon, 8 Nov 2010 05:40:06 -0500 (EST), Sebastian wrote: > On Nov 6, 10:59 am, David Bailey <d... at removedbailey.co.uk> wrote: >> On 05/11/10 10:11, David Bailey wrote: >> >> >>> On 04/11/10 09:01, Sebastian wrote: >>>> Hi, >>>> I've been searching the newsgroup and the web for an answer for >>>> this, >>>> but all the results were unsatisfactory: >>>> Is there a way to save the currently opened .nbfileto a .mfileby >>>> using a mathematica command and not the "Save as..." menu command? >>>> Please note that I want _all_ the cells to be written to themfile, >>>> not only the initialization cells. Even better would be a way to do >>>> this on every save of the nb, but I have given up hope that such a >>>> thing is possible. All this is part of my effort to find an >>>> effective >>>> version control solution for my mathematica files. >>>> TIA >>>> Sebastian >>>> >>> It would definitely help to explain a bit about what you want to >>> achiev= > e. > >>> However, you could read your notebook with NotebookGet, then write >>> that >>> messy structure to a .mfilewith Save. It would really help to >>> understand how you want to use this. >>> >>> David Bailey >>> http://www.dbaileyconsultancy.co.uk >>> >> Sorry, I realised after I had written this, that you had explained what >> you are trying to achieve. I have a couple of extra suggestions: >> >> 1) I believe Wolfram Workbench supports version control, but I don't >> use this because it seems to involve a steep learning curve and is not >> particularly well integrated with Mathematica. >> >> 2) Notebooks are actually text files - try opening one with a text >> editor. Therefore, it is possible to read a notebook as lines of text >> from within Mathematica. >> >> David Baileyhttp://www.dbaileyconsultancy.co.uk >> > Hi, > thanks for your suggestions but they don't really achieve what I'm > trying to do. Sorry if it wasn't clear what I was trying to do, so > here goes again: By choosing "Save as..." from the file menu and then > selecting "Mathematica Package (*.m)" I can save a real "plain text" > file as opposed to a notebook (.nb) file, which has all these > metainformation and a very "messy structure" as you called it. This I > can easily check into a VC system, easily resolve merge conflicts and > so on. The problem is, that sometimes I want to edit the notebook > files as I want to keep certain output cells and I tend to forget to > save it to a package file. > Hope that clears things up! > Sebastian Yes, you can do this, and I'll show you how...but I'm confused about something. I'm not fully convinced by your revision control strategy. Either your notebooks really are the source document, in which case, you should keep them under source control regardless of the difficulties. Or the packages really are the source document, in which case you should be opening/editing/saving them as packages natively (i.e., using Workbench and/or the front end's package editor...which play very nicely with each other, I might add), and never as notebooks. Putting generated artifacts under source control...and generating artifacts is precisely what Save As->Package from a notebook does...is generally ill-advised and exposes you to either the loss of your source material, or synchronization problems with that source material. All of those warnings having been stated, here's how you can do what you want: MathLink`CallFrontEnd[ FrontEndToken[nb, "Save", {filename, "Package"}]] where nb is the NotebookObject[] (which you might get from, e.g., InputNotebook[], EvaluationNotebook[], Notebooks[], etc.), and filename is the string representing the complete path to the .m file. Alternatively, you could also set the AutoGeneratedPackage option in the Option Inspector for the given notebooks, which could force them to always save a synchronized package file...although this even more greatly magnifies the "generated artifact" problem I outlined above. Sincerely, John Fultz jfultz at wolfram.com User Interface Group Wolfram Research, Inc.