David,
In response to 1), this is a bug. Notation in subscripts using paired ASCII
brackets works fine, but notation using \[LeftDoubleBracket] and
\[RightDoubleBracket] does not. I'll look at this ASAP.
For your second point, you can omit non-initialization cells when doing Save
As->Package File by clicking the Options... button in the Save dialog and
checking the "Only save Code cells" checkbox. Code, incidentally, refers to thenew style bound to Alt+8 which is, by default, an initialization cell and will
save out to packages. It also has automatic line-wrapping and indentation
turned off so that you can see exactly what the cell will look like when writtenout to the package file.
The behavior of omitting non-initialization cells probably ought to be done
automatically in auto-generated packages. But I think the inclusion of
non-initialization cells is considerably useful when working with Package files
directly (i.e. File->New->Package).
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
On Mon, 4 Jun 2007 03:46:04 -0400 (EDT), David Park wrote:
> I write packages by using a regular notebook with Initialization cells and
> saving it as an AutoGeneratedPackage. I have come across the following two
> problems while converting a 5.2 package to 6.0.
>
> 1) Part expressions in the subscripted form (for example from the
> BasicMathInput palette, 6th row right) do not parse from the generated .m
> file. Packages that contain these expressions will not load correctly.
> Nor are these expressions detected as an incompatibility issued when
> checking the source notebook. I think this subscripted form came in
> with Version 4. For a long time I resisted it but finally decided that it
> was easier to read and was here to stay. If one looks at the .m file,
> these expressions are flagged in red but it appears that the only way to
> correct them is to go back to the original notebook, tracked them down,
> and write them as nonsubscripted Part expressions. I think that these
> expressions should be accepted and parsed in the package files.
>
> 2) All cells in the source notebook are now automatically Initialization
> cells and there is no way to change any of them. This is quite bad because
> there are a number of reasons for having nonitialization cells in a
> package
> source notebook. I often put in Text cell comments that give the date and
> reason that some change was made. I don't want these comments to be in the
> ..m package file. Also, I often make a new version of a routine but do not
> want to immediately throw out the old routine code. I could formerly do
> this
> by making the old code cell a noninitialization cell but can no longer do
> that. This is a serious loss of development capability. I believe this is
> a
> bug because one can select a cell and use Menu -> Cell -> Cell Properties
> ->
> Initialization Cell and this will be either checked or unchecked. It will
> toggle when one selects it. However, it does not affect the Initialization
> character of the cell in the source notebook. And even when the menu item
> is
> unchecked the cell still goes into the .m file and causes problems.