Re: Viewing packages in mathematica

Skip to first unread message

John Fultz

Aug 26, 2009, 7:43:06 AM8/26/09
On Mon, 24 Aug 2009 07:55:59 -0400 (EDT), David Park wrote:

> I wasn't aware that all those features are built into the front end
> package editor.
> But how do I find out information on using the .m file and editing it
> because when I search the Documentation Center I find practically nothing.
> If I copy a notebook package contents and paste into a new .m file it
> looks almost like the notebook. Except it has "Input" cells instead of
> "Code" cells. What is the difference between these cell types? I looked
> up Code Cells in the DC but found nothing.

Code cells actually form the package code. Input cells remain evaluatable
in the FE, but are commented out in the package so that they are not
evaluated by Get[].

The styles behind the scenes do this by setting (or not) the
InitializationCell option, so it's basically the same as working with
auto-generated packages in a regular notebook.

> You say the files from the package editor are interchangeable with
> Workbench. How so?

Package files are text files. Since the package editor uses the text
format directly, rather than backing a source notebook file with a
generated package file like auto-generated packages do, this means that
you can edit those package files with anything. The FE adds a small
amount of markup, but that markup is in clearly delineated comments
which often actually help to annotate the file when it's edited with
any other editor. And if you manually remove or alter the markup,
the FE won't (or shouldn't, anyway) throw a conniption.

> I went to one of my Workbench projects, took one of
> the package files and opened with the System Editor and got the front end
> editor. Fine. But after I did that I no longer could properly open the
> PacletInfo.m file. It wouldn't even open after I tried to open with the
> PacletInfo Editor. My whole project is presently messed up! Or maybe all
> my projects are messed up and I don't know what is the best method to
> reconstruct them.

I can't say what happened here. Your description is too vague, and I
don't really know anything about the PacletInfo Editor. But if you want
to send me your files and describe to me in more detail exactly what it
was you did, I'll certainly take a look at it.


John Fultz
User Interface Group
Wolfram Research, Inc.

> So that is what happens with Mathematica. One wants to work on math, or
> on some technical project, but one is always sucked down into a morass of
> undocumented features, and computer science, and guessing. One spends 95%
> of one's time working on Mathematica problems and 5% actually doing
> something interesting!
> David Park
> From: John Fultz []
> I should make it clear that none of your reasons apply to the package
> editor
> in
> the Mathematica front end (available by opening a package file or through
> the
> menu item File->New->Package). You can edit packages directly using that
> editor
> with all of the formatting, syntax coloring, cell types and grouping on
> package
> files which are completely interchangeable with Workbench or any other
> text
> editor you might favor for working with package files.
> There are a couple of things that you don't get which you would get with
> regular
> notebooks. As the original post points out, you don't get line-wrapping
> in
> Code
> cells. This was a deliberate design decision on our part. We wanted to
> create
> a package editor which would be completely interchangeable with Workbench
> and
> other systems. Therefore, two of the design goals were to limit the
> automatic
> formatting changes introduced by the front end when displaying/editing a
> package
> file, and to minimize the markup introduced into the package file by the
> front
> end when encoding cell group structure, cell styles, etc.
> I personally think we've struck a pretty good balance, although there are
> a
> few
> suggestions for features which remain to be implemented. Others on this
> forum
> (and perhaps even within Wolfram) may disagree, and that's fine. There
> are
> many
> options for editing package files. Some people are very happy with
> Workbench,
> some with their own text editors, some with the FE's package editor, and
> some
> with notebooks auto-saved as packages. All will continue to be supported
> for as
> far in the future as I can predict.
> Sincerely,
> John Fultz
> User Interface Group
> Wolfram Research, Inc.
> On Sun, 23 Aug 2009 05:32:59 -0400 (EDT), David Park wrote:
>> I agree with you that I would much prefer to have Mathematica notebooks
>> as
>> the primary source for package code. The reasons are:
>> 1) You get the automatic formatting.
>> 2) You get syntax coloring.
>> 3) You can include Text cells for notes on the code.
>> 4) You can use sectional grouping so you don't have just one long
>> scroll.
>> 5) You're not completely committed to Workbench.
>> One of the major problem with creating .m files in Workbench is that if
>> you Import the code from a regular existing package then the .m code
>> does
>> not line wrap. This makes it very difficult to read and to modify.
>> However, if you copy and paste code from an existing notebook then it
>> does line wrap.
>> Making .m files the primary source of package definitions is a
>> significant
>> obstacle to users who would prefer to stay closer to mathematics than to
>> computer programming.
>> It would be nice if Workbench included a mechanism similar to the auto
>> generated package mechanism that would generate line wrapping .m files.
>> But there is a method that I've found, just in the last two days, that
>> works and is fairly convenient.
>> 1) In your Workbench application folder create package.nb and package.m
>> files.
>> 2) The package.nb notebook will look just like a regular package
>> notebook
>> done outside of Workbench except: don't make it an auto generated
>> package
>> and don't even use Initialization cells. (Making it an auto generated
>> package will get Workbench all confused!) This will be your primary
>> package
>> source file.
>> 3) To create the package.m file: Select all the Input cells in
>> package.nb, and copy them; go to the package.m file select everything
>> and
>> paste. (To select all the Input cells in package.nb hold down Alt and
>> click on one of the brackets.) With this method the code will line wrap
>> in the .m file. You can also just copy and paste a single routine. This
>> 'hand' method is quite quick and easy. You don't have to much look at
>> the
>> .m file.
>> I believe that once the kinks are smoothed out, and there is better
>> documentation and examples Workbench can be a very useful working
>> interface for regular Mathematica users. One advantage is that it is a
>> regular WRI supported feature of the Mathematica system, and it blends
>> with the rest of Mathematica. As I've mentioned before, some of the
>> things it could be used for are:
>> 1) Writing an electronic book.
>> 2) Writing university courseware.
>> 3) Working on a major research project.
>> 4) Self-study of a textbook or some subject matter.
>> All of these things are likely to generate routines that could be put
>> into a package, and if you are going to do that it might as well be
>> documented. It's not that much work if you confine it to major useful
>> routines. Then a Mathematica Application is a good way to organized
>> relatively finished material, package routines and subject matter
>> notebooks, so it is easy to get at it again. It's a lot better than
>> having a lot of loose notebooks with an undocumented routine here and
>> another there. It's a major fruit of your labor so it's worthwhile to
>> have it documented and organized.
>> David Park
>> From: Bill Rowe []
>> Also, there is Wolfram Workbench. Others have found this useful.
>> As for myself, I've not found Wolfram Workbench to be that
>> useful. I much prefer keeping a Mathematica notebook and
>> generating the .m file from it.

Luc Barthelet

Aug 26, 2009, 7:43:28 AM8/26/09
I use extensively the .m files as regular notebooks and as packages in
the Mathematica front end and in the eclipse workbench. In fact I use
the .m files in preference except for when I know I want to keep the

I agree with John that the current balance achieved by the team is a
good solution.
The time invested by the team on this feature was really worth it.

The few improvements I would like to see are:
- Open files faster. since v7 opening a .m became really slow.
- Enable tab and shift tab to work on code cells to indent multiple
- Enable tab to work even if the cursor is not in the left most position
of the line (as long as there are only tabs or spaces to the left).
- Fix the bug where *) and (* are found inside strings and confuse the
.m reader. (it seems to be a tough one, I am not sure it has anything to
do with this discussion though)
- Add a source formatter for code cell in the front end so we get a
'standard' display of Mathematica code
- Images in code cell are transformed into text on save, I am not sure
why there are not transformed back on open.


Bill Rowe

Aug 27, 2009, 6:33:07 AM8/27/09
On 8/26/09 at 7:43 AM, (AES) wrote:

>In article <h6tv7b$drf$>,
>"David Park" <> wrote:

>>So that is what happens with Mathematica. One wants to work on
>>math, or on some technical project, but one is always sucked down
>>into a morass of undocumented features, and computer science, and
>>guessing. One spends 95% of one's time working on Mathematica
>>problems and 5% actually doing something interesting!

>My God, David! It seems to me you have suddenly started to sound
>exactly like me, before I more or less gave up on posting on these
>issues and tried to get refocused on "actually doing something
>interesting" myself.

>Let me just say again: I believe the core lesson in this saga -- or
>to phrase it differently, the core cause of this disaster -- is the
>attempt (one might say, if one wanted to be nasty about it, the
>megalomaniacal attempt) to have one single massive app that will be
>all things, provide all tools and capabilities, to all users, rather
>than some kind of much more modular approach.

How so? The complexity of Mathematica arises from its
capabilities. If a modular approach had the same capabilities
how could it not have the same complexity? And with that
complexity comes issues of documentation etc. That is the more
complex a product, the more documentation is needed and the more
likely some aspect fails to get documented appropriately.

Perhaps your thought is Mathematica should come as separate
modules that users could obtain on there own to add capability
as they need. With this approach, you have whatever complexity
is inherent in the modules the user gets and associated
documentation issues. There will also be the additional overhead
of managing the modules. I don't see this as being less effort
for users.

And consider the feature being discussed in this thread, the
ability of the FE to nicely open .m files for editing. I too was
unaware of this feature and I am unaware of it being documented
somewhere. But so what? Why should I or anyone let this feature
distract from getting work done?

If you were not aware of this, surely you had a means of dealing
with .m files which have been present for all versions of
Mathematica. Whatever method you used, it still works right? So,
why let a new way of dealing with these files distract you?

John Fultz

Aug 27, 2009, 6:38:44 AM8/27/09
The window size issue is easy to fix. With any file open, choose File->Save
As... and switch the file filter to "Mathematica Package". Press the Options...
button. In the resulting dialog, check the box to "Save window size and
position", then press the "Use Settings as Defaults" button.

From now on, all packages that you save will remember their window size and
position. You may wonder why we didn't do this by default. There was some
discussion internally over whether saving the window size/position was more
desirable, or whether it was more desirable to minimize the amount of markup
which is added to package files by default. The latter position won the day.
I'm not personally fully convinced by this, but compromise, like sausage, is
never pretty when it's made.

Concerning the line-wrapping issue, it is possible to change this, but
considerably more difficult. But here's a canned procedure for you.

* Copy the notebook expression below. Paste into Mathematica, and choose to

Cell[StyleData[StyleDefinitions -> "Package.nb"]],
Cell[StyleData["Code"], PageWidth->WindowWidth, LineBreakWithin->Automatic,
LineIndent->1., LinebreakAdjustments->{0.85, 2, 10, 0, 1}],
Cell[StyleData["Code", "Printout"], PageWidth->PaperWidth]
}, Open ]]

* Click the "install Stylesheet..." button at the top. In the "InstallName"
field, type
pressing Enter, then click the Finish button.

* Restart Mathematica.

To undo the effects of this, track down the file pointed to by evaluating this

ToFileName[{$UserBaseDirectory, "SystemFiles", "FrontEnd",
"StyleSheets"}, "Package.nb"]

and delete it. Make sure you're not editing any packages when you attempt to
delete the file.


John Fultz
User Interface Group
Wolfram Research, Inc.

On Mon, 24 Aug 2009 07:55:26 -0400 (EDT), Yves Klett wrote:
> Benjamin,
> since Version 6, .m files can be handled quite nicely, including syntax
> highlighting and everything. Also, headings and some other formats are
> retained.
> All previous initialization cells have a different cell style if you
> open the .m directly: They are rendered in "Code". This cellstyle
> obviously does no linewrapping. If you format long lines as "Input",
> wrapping is done immediately.
> I presume there must be some option to turn linewrapping for certain
> cell style, but I did not find it (not that I've been searching hard).
> So the question is: how to turn on linewrapping for cellstyles?
> Also, .m files are always opened in a small window and do not remember
> changed window size etc. - also quite annoying.
> Any tips would be appreciated.
> Regards,
> Yves
> Benjamin Hell schrieb:
>> Hi,
>> this is a real beginner question for packages in mathematica. When I
>> view a package (.m) file in mathematica, the mathematica editor doesn't
>> show any indentation nor does any automatic line breaks when scaling the
>> window. So whereas my code can be read quite well in a standard
>> mathematica notebook, it looks ugly in a package file. Is there any way
>> to setup some viewing options to change that behaviour?
>> Thanks in advance,
>> Benjamin


Aug 28, 2009, 12:42:15 AM8/28/09


A tangential question: Is there a way to make the Front End substitute
spaces for tabs, when I press the Tab key? I'm looking to imitate the
same behavior available in the Workbench editor (I prefer to format
the whitespace of package files with spaces instead of tabs).

Thank you,

Vince Virgilio

John Fultz

Aug 31, 2009, 6:35:18 AM8/31/09

No, but we can certainly consider that for the future feature list.

Reply all
Reply to author
0 new messages