Undo in Mathematica
fd
I was wondering if and how I could do any useful "undo" in
Mathematica. The one I get from the edit menu just allows me to undo
the last step (if it is not evaluated). This is pretty unsatisfactory,
even more for a program with this complexity.
I've tried navigating in the Option Inspector without luck, maybe
someone found something?
F.
David Reiss
This has been covered many times on this group. Do a search in the
archive: simply look for "undo"s...
--David
David Bailey
because of the complexity of the environment and potential size of the
files, but I would claim they could do a LOT better than the current scheme.
For example, the could restrict the UNDO mechanism to cells that are not
generated (i.e. not output), and possibly the undo stack would only go
back as far as the previous evaluation.
I would have thought a multi-level undo is pretty vital in an
interactive program!
David Bailey
http://www.dbaileyconsultancy.co.uk
John Fultz
> fd wrote:
>
>> All,
>>
>> I was wondering if and how I could do any useful "undo" in
>> Mathematica. The one I get from the edit menu just allows me to undo
>> the last step (if it is not evaluated). This is pretty unsatisfactory,
>> even more for a program with this complexity.
>>
>> I've tried navigating in the Option Inspector without luck, maybe
>> someone found something?
>>
>>
>> F.
>>
>>
> WRI claim that a general (multi-level) undo is impractical in notebooks
> because of the complexity of the environment and potential size of the
> files, but I would claim they could do a LOT better than the current
> scheme.
To set the record straight, WRI does not make that claim.
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
Yuri Kandrashkin
use the "preserving" function of the Sidebar tools. This is not a real
multiple UNDO but it helps me to return to the previous changes. The package
is available at
http://sites.google.com/site/qstate/
2009/11/19 David Bailey <da...@removedbailey.co.uk>
> WRI claim that a general (multi-level) undo is impractical in notebooks
> because of the complexity of the environment and potential size of the
> files, but I would claim they could do a LOT better than the current
> scheme.
>
> For example, the could restrict the UNDO mechanism to cells that are not
> generated (i.e. not output), and possibly the undo stack would only go
> back as far as the previous evaluation.
>
> I would have thought a multi-level undo is pretty vital in an
> interactive program!
>
> David Bailey
> http://www.dbaileyconsultancy.co.uk
>
>
--
Sincerely,
Yuri Kandrashkin, PhD
David Bailey
>
> To set the record straight, WRI does not make that claim.
>
I do apologise for the confusion here - I was quoting a post made here
many years ago - possibly as far back as version 3.0 (which suffered
from the same problem with UNDO!) - not describing a recent
communication with WRI.
David Bailey
http://www.dbaileyconsultancy.co.uk
brien colwell
thorns my team has with developing in M. The other major thorns are with
the IDE/notebook editor itself, which would benefit from listing the
source file and line number where error messages are generated, linking
symbols to their source-code declarations, listing available symbols for
"smart completion," and tighter integration with the debugger.
The Eclipse-based workbench seems a promising replacement for the
notebook editor, but my understanding is that the workbench currently is
not as interactive as the notebook editor.
I am really curious how people develop large libraries in M.
John Fultz wrote:
> On Thu, 19 Nov 2009 05:23:42 -0500 (EST), David Bailey wrote:
>
>> fd wrote:
>>
>>
>>> All,
>>>
>>> I was wondering if and how I could do any useful "undo" in
>>> Mathematica. The one I get from the edit menu just allows me to undo
>>> the last step (if it is not evaluated). This is pretty unsatisfactory,
>>> even more for a program with this complexity.
>>>
>>> I've tried navigating in the Option Inspector without luck, maybe
>>> someone found something?
>>>
>>>
>>> F.
>>>
>>>
>>>
>> WRI claim that a general (multi-level) undo is impractical in notebooks
>> because of the complexity of the environment and potential size of the
>> files, but I would claim they could do a LOT better than the current
>> scheme.
>>
>
> To set the record straight, WRI does not make that claim.
>
> Sincerely,
>
> John Fultz
> jfu...@wolfram.com
> User Interface Group
> Wolfram Research, Inc.
>
>
>
Vince Virgilio
>
> The Eclipse-based workbench seems a promising replacement for the
> notebook editor, but my understanding is that the workbench currently is
> not as interactive as the notebook editor.
Rather, it's not as hyperactive. Though it does display certain
tendencies.
>
> I am really curious how people develop large libraries in M.
>
Workbench and an occasional escape to Vim has sufficed for the
development of an ~ 9800 line package. I had to move its development
out of the Front End a long time ago.
Vince Virgilio
TWJ
> I am really curious how people develop large libraries in M.
People use all sorts of different tools and practices.
But a lot of people do use Wolfram Workbench -- this includes
a lot of developers at Wolfram Research who use it for Mathematica
development, and Mathematica is full of huge Mathematica libraries.
The same is true for Wolfram Alpha.
For large (and small) library development, the Workbench gives
a tremendous number of useful features, completely too many
to list in a posting like this. It has a project based approach,
so you can work with multiple files, this is useful to separate
different components.
One example, of its functionality is that all the syntax/semantic
warnings and errors (and there are very many classes of these)
found in any files are all summarized in one report. This is
much more useful than only seeing just those problems in the
part of the file you happen to have open.
Also, you get an integrated debugger, unit tester, profiler and
source control.
And it does have a nice multi-stage undo.
You can get more idea of its features from the website
(there are a bunch of screencasts)...
http://www.wolfram.com/products/workbench/
When you say:
'but my understanding is that the workbench currently is
not as interactive as the notebook editor'
I'd be curious to know what you mean. Usually the types
of things that the Workbench is not so good for is free-form
mathematical explorations that mix typesetting, visualizations,
etc... The FrontEnd is very good for this.
But for producing Mathematica packages, applications etc...,
the Workbench is very appealing.
Tom Wickham-Jones
Wolfram Research
David Bailey
> Just my 2 cents ... the practical lack of undo is one of the major
> thorns my team has with developing in M. The other major thorns are with
> the IDE/notebook editor itself, which would benefit from listing the
> source file and line number where error messages are generated, linking
> symbols to their source-code declarations, listing available symbols for
> "smart completion," and tighter integration with the debugger.
>
> The Eclipse-based workbench seems a promising replacement for the
> notebook editor, but my understanding is that the workbench currently is
> not as interactive as the notebook editor.
>
> I am really curious how people develop large libraries in M.
>
with .m (package) files, which can be edited within Mathematica. It is
possible to split the code into sections with headings, just as if
editing a notebook, and when the result is stored to disk, the heading
information is stored as comments. This editing experience is remarkably
good (despite the lack of a proper UNDO!).
If I get an error when the package is read in, and the location is not
obvious, I open the .m file with a regular text editor to locate the
line from the number in the error message. This is not ideal, but I
don't find I need to do this often. Alternatively, it is possible to
execute the .m file from within the FE and look for the message.
One of the biggest problems with Eclipse, is that it does not show all
the extra Mathematica characters. I feel WRI have rather split their
effort between the FE and Eclipse - which is unfortunate.
David Bailey
http://www.dbaileyconsultancy.co.uk
David Park
with code development and debugging (rather nerdy things!) and that is as a
method for organizing and consolidating your work.
Consider an "Application" that has one or more packages with documentation,
and sets of "finished notebooks". In addition there may be "developmental
notebooks" of various types that are associated with the application but not
part of its permanent content.
Examples of such applications might be: writing a dynamic book using
Mathematica; college courseware; a major research project; a study project
of some book or subject. Don't think of an Application as a package, but
think of it as some kind of unified project.
It is difficult for me to conceive of any such projects that would not
involve writing special routines and putting them in a package. If one is
going to do that, one might as well give them paclet documentation. This may
seem like a lot of work (when many users would balk at even writing a usage
message) but is your work important or not? If it is important, it should be
consolidated, preserved, documented and put in an accessible place.
In the deployed application, in addition to the packages, style sheets,
palettes, documentation and finished notebooks, you can add a Workbooks,
say, folder to contain the developmental notebooks. You can do most of your
work in regular Mathematica using the deployed application. When some
developmental notebook becomes finished, or some new routines have been
developed and tested, you can make a trip to Workbench and incorporate them
into the permanent part of the application. This won't be horribly time
consuming because most of the content, including routine examples, should
already exist in the developmental notebooks and can be copied in. Once the
basic structure is there everything is incremental. When the application is
redeployed from Workbench it will not disturb the Workbooks folder so you
can just continue working in Mathematica. If you send the application to
another person you can just delete the Workbooks folder from the zip file.
I've been using this for several project and it works very smoothly. Again,
if your work is important (and I'm certain it is) then this is a way to
consolidate and preserve it. It also uses standard WRI programs and meshes
with standard Mathematica usage.
If you want to take advantage of the Workbench code editing and debugging
features - all the better. I tend not to use Workbench for initial code
development but I do use it for fix-ups and it has many nice features. You
can also edit code using the frontend editor (where you can add sectional
grouping and Text cells) or in the Workbench editor and easily switch
between them.
Anyone doing major projects with Mathematica should definitely consider
using Workbench.
David Park
djm...@comcast.net
http://home.comcast.net/~djmpark/
From: TWJ [mailto:t...@wolfram.com]
> I am really curious how people develop large libraries in M.
People use all sorts of different tools and practices.
brien colwell
> When you say:
> 'but my understanding is that the workbench currently is
> not as interactive as the notebook editor'
>
> I'd be curious to know what you mean. Usually the types
> of things that the Workbench is not so good for is free-form
> mathematical explorations that mix typesetting, visualizations,
> etc... The FrontEnd is very good for this.
>
>
> But for producing Mathematica packages, applications etc...,
> the Workbench is very appealing.
>
>
global context, with visualizations or interactive components.
Because Mathematica doesn't come out of the box with a comprehensive IDE for
all cases, I just need to adjust to the best practices. Thanks for the help.