v6: still no multiple undo?
Will Robertson
I am baffled that technical software is released in 2007 with only a
single undo level. Am I missing something here? Is it because I'm
using a student license? How hard can an undo stack really be in the
notebook interface?
I've been irritated a few times in v5.2 from clumsy keypresses losing
me work that I would expect to be two "undo"s away. Alas not. Still.
Will Robertson
Selwyn Hollis
Undo is even less functional in 6 than in 5.2.
Another shortcoming is the lack of AutoSave or AutoBackup capability.
It's too easy to lose track of time, crash, and then discover that
you haven't saved anything in 2 hours. (Or maybe its just dementia on
my part.) I've created a little palette of my own with an AutoSave
function that saves the InputNotebook[] every few minutes. That works
pretty well, and if anyone would like to test it, let me know. I've
made an attempt at an AutoBackup function, but I don't know how to
make it sufficiently non-intrusive.
-- Selwyn
David
Good point! I've wondered the same thing for a long time. This is the
only app I run that doesn't happen multiple levels of undo. I think it's
time WRI spent some time on this issue.
David Bailey
working, all you need to do is spill the relevant data into a structure
- possibly on disk - and retrieve it as needed!
David Bailey
http://www.dbaileyconsultancy.co.uk
Helen Read
> Ah, that's at the top of my gripes list too. I'm pretty sure that
> Undo is even less functional in 6 than in 5.2.
Undo seems kind of buggy in 6. I've lost things that just didn't go back
to the way they were when I tried to Undo (after e.g. accidentally
pasting when I meant to copy).
> Another shortcoming is the lack of AutoSave or AutoBackup capability.
> It's too easy to lose track of time, crash, and then discover that
> you haven't saved anything in 2 hours. (Or maybe its just dementia on
> my part.)
I'm fairly obsessive about saving frequently, but I cannot for the life
of me get my students to do it. A few times a semester, someone will
crash Mathematica at the very end of a class period when they are taking
a quiz or exam, without having saved a thing. Built-in AutoSave would be
nice to have.
--
Helen Read
University of Vermont
David Reiss
notebook backup and tracking functionality that I include in A
WorkLife FrameWork (shameless plug!). It is sort of a mini CVS in
Mathematica.
I do think though that Undo is tricky in Mathematica. One reason is
that some of what one does and might want to undo can be **very**
large. Another is the question of what one means by Undo and redo.
Does this include evaluations? Does it include formatting changes?
And so on. I suspect that the question is rather more complex than
what one might have to deal with in a simple text editor or word
processor. But, on the other hand, I am sure that some cleverness
could be brought to bear on this...
--David
http://scientificarts.com/worklife
Now Mathematica 6 compatible
Barthelet, Luc
While I strongly support that multiple undo is a feature we need to see
soon, it will take some real work to get there.
The editor, and the kernels are linked in an efficient exchange of messages
and information about what needs to be displayed where and when.
While implementing multiple undo-redo in a stand alone editor usually
requires only to implement a tokenized undo-redo, in the v6 font end, it
will require a more complex model. It is a bit like if you were trying to
implement multiple undo on a wiki site like wikipedia where they are
multiple contributors.
We probably do not want the kernel to "undo", just the front end. So one
solution would be to make the kernel and the user to appear as a single
contributor, and to undo both effects on the front end. So one undo might
remove an output created by the kernel.
Even that is challenging, because Dynamics now create a lot of updates and
you will not want to roll those back.
Anyway, the front end team is obviously smart enough to find a solution for
all those things, but it is not going to be easy.
A cheap thing that I would like to see, is a text buffer of all my input and
all the code I deleted saved as a log on disk. It might be ugly, but it
would be VERY USEFUL.
Cheers,
Luc
On 6/7/07 3:34 AM, "David Bailey" <dave@Remove_Thisdbailey.co.uk> wrote:
> David wrote:
>> Will Robertson wrote:
>>> Hello,
>>>
>>> I am baffled that technical software is released in 2007 with only a
>>> single undo level. Am I missing something here? Is it because I'm
>>> using a student license? How hard can an undo stack really be in the
>>> notebook interface?
>>>
>>> I've been irritated a few times in v5.2 from clumsy keypresses losing
>>> me work that I would expect to be two "undo"s away. Alas not. Still.
>>>
>>> Will Robertson
>>>
>>>
>>
Brett Champion
> Selwyn Hollis wrote:
>> Ah, that's at the top of my gripes list too. I'm pretty sure that
>> Undo is even less functional in 6 than in 5.2.
>
> Undo seems kind of buggy in 6. I've lost things that just didn't go
> back
> to the way they were when I tried to Undo (after e.g. accidentally
> pasting when I meant to copy).
>
>> Another shortcoming is the lack of AutoSave or AutoBackup capability.
>> It's too easy to lose track of time, crash, and then discover that
>> you haven't saved anything in 2 hours. (Or maybe its just dementia on
>> my part.)
>
> I'm fairly obsessive about saving frequently, but I cannot for the
> life
> of me get my students to do it. A few times a semester, someone will
> crash Mathematica at the very end of a class period when they are
> taking
> a quiz or exam, without having saved a thing. Built-in AutoSave
> would be
> nice to have.
Would the NotebookAutoSave option work for you?
http://reference.wolfram.com/mathematica/ref/NotebookAutoSave.html
It saves the notebook after each evaluation, provided the notebook
has been saved once already.
(NotebookAutoSave has been around for several versions.)
Brett Champion
Wolfram Research
David Reiss
the cells that one executes in a mathematica session if that execution
is done though the appropriate palette button. See
http://scientificarts.com/worklife/documentation/evaluationpalette.html
I was wondering last night whether I can, in Version 6, make this an
automatic behavior (toggled according to the user's choice) that is
done whenever an execution takes place, irrespective of whether the
palette button is used.
Functoins such as FrontEndEventActions, NotebookEventActions, or
CellEventActions may well do the trick. I use these for other
purposes in WorkLife, but they are very broad and poserful for other
things. I will look into this and let the group know what I come up
with...
-David
http://scientificarts.com/worklife
Now Mathematica 6 compatible
David Reiss
If one defines a function called, say, EvaluateCellsWithTracking[]
(not a coincidence that that is similar to the name of the function in
http://scientificarts.com/worklife), then if one sets the options for
a notebook nb as:
SetOptions[nb,
NotebookEventActions :> {{"MenuCommand", "EvaluateCells"} :>
EvaluateCellsWithTracking[]}]
this will do the trick. Of course it depends on what
EvaluateCellsWithTracking[] is defined to do, but you could create
your own bit of code within a Module and place it whre
EvaluateWithTracking[] appears in the above bit of code.
There is a bit of trickyness here (which had be restart mathematica
several times when I got into an infinite loop, but it is doable.
One thing though, when I tried something at the level of the FrontEnd
like
SetOptions[$FrontEnd,
FrontEndEventActions :> {{"MenuCommand", "EvaluateCells"} :>
EvaluateCellsWithTracking[]}]
I encountered a nasty bug or two, so I would not recommend this as a
global FrontEnd approach just yet, but rather use the notebook-level
approach in the first snippet of code. As always I will track it down
in a simple example and report it to bu...@wolfram.com.
An example of what you might use for EvaluateCellsWithTracking is
(this is a rarified version of what is in A WorkLife FrameWork--for
this tow rk you will need to create a file on disk to store the
evaluatons and specify the parameter
$CurrentEvaluationTrackingNotebookFile as its file path):
ClearAll[EvaluateCellsWithTracking];
EvaluateCellsWithTracking[nb_NotebookObject] :=
Module[{nbr, currentEvaluationTrackingNotebook},
SelectionMove[nb, All, Cell];
nbr = NotebookRead[nb];
currentEvaluationTrackingNotebook =
NotebookOpen[$CurrentEvaluationTrackingNotebookFile,
Visible -> False];
SelectionMove[currentEvaluationTrackingNotebook, After, Notebook,
AutoScroll -> False];
NotebookWrite[currentEvaluationTrackingNotebook, nbr];
NotebookSave[currentEvaluationTrackingNotebook];
NotebookClose[currentEvaluationTrackingNotebook];
FrontEndExecute[FrontEnd`FrontEndToken[nb, "Evaluate"]];
nb
];
EvaluateCellsWithTracking[] :=
EvaluateCellsWithTracking[EvaluationNotebook[]]
--David
http://scientificarts.com/worklife
Now Mathematica 6 compatible
On Jun 8, 5:50 am, "Barthelet, Luc" <l...@ea.com> wrote:
> While I strongly support that multipleundois a feature we need to see
> soon, it will take some real work to get there.
>
> The editor, and the kernels are linked in an efficient exchange of messages
> and information about what needs to be displayed where and when.
>
> While implementing multipleundo-redo in a stand alone editor usually
> requires only to implement a tokenizedundo-redo, in the v6 font end, it
> will require a more complex model. It is a bit like if you were trying to
> implement multipleundoon a wiki site like wikipedia where they are
> multiple contributors.
>
> We probably do not want the kernel to "undo", just the front end. So one
> solution would be to make the kernel and the user to appear as a single
> contributor, and toundoboth effects on the front end. So oneundomight
> remove an output created by the kernel.
>
> Even that is challenging, because Dynamics now create a lot of updates and
> you will not want to roll those back.
>
> Anyway, the front end team is obviously smart enough to find a solution for
> all those things, but it is not going to be easy.
>
> A cheap thing that I would like to see, is a text buffer of all my input and
> all the code I deleted saved as a log on disk. It might be ugly, but it
> would be VERY USEFUL.
>
> Cheers,
>
> Luc
>
> On 6/7/07 3:34 AM, "David Bailey" <dave@Remove_Thisdbailey.co.uk> wrote:
>
> > David wrote:
> >> Will Robertson wrote:
> >>> Hello,
>
> >>> I am baffled that technical software is released in 2007 with only a
> >>> singleundolevel. Am I missing something here? Is it because I'm
> >>> using a student license? How hard can anundostack really be in the
> >>> notebook interface?
>
> >>> I've been irritated a few times in v5.2 from clumsy keypresses losing
> >>> me work that I would expect to be two "undo"s away. Alas not. Still.
>
> >>> Will Robertson
>
> >> Good point! I've wondered the same thing for a long time. This is the
> >> only app I run that doesn't happen multiple levels ofundo. I think it's
David Bailey
a step forward. Alternatively, a multi-level undo that ignored generated
cells might be a possibility - after all, it is usually (but not always)
the input that is really valuable, the output can be regenerated.
David Bailey
http://www.dbaileyconsultancy.co.uk
Murray Eisenberg
objects would seem to be particularly thorny!
David Reiss wrote:
>
> ...I do think though that Undo is tricky in Mathematica. One reason is
> that some of what one does and might want to undo can be **very**
> large. Another is the question of what one means by Undo and redo.
> Does this include evaluations?
--
Murray Eisenberg mur...@math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2859 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305
Andrzej Kozlowski
in Mathematica one or more of their favourite features of other
programs. After all, we all now have multi-gigaherz processors,
gigabytes of RAM etc, and wouldn't it be great if Mathematica could
do all the things that all these other programs do? You might even
not need them any more.
However, this kind of approach has its price and to see this clearly
I suggest that, before submitting another request for another "great
feature you can't live without", everyone reads this:
http://hubpages.com/hub/
_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
and thinks again if this price is really worth paying.
Andrzej Kozlowski
On 8 Jun 2007, at 18:38, Barthelet, Luc wrote:
>
> While I strongly support that multiple undo is a feature we need to
> see
> soon, it will take some real work to get there.
>
> The editor, and the kernels are linked in an efficient exchange of
> messages
> and information about what needs to be displayed where and when.
>
> While implementing multiple undo-redo in a stand alone editor usually
> requires only to implement a tokenized undo-redo, in the v6 font
> end, it
> will require a more complex model. It is a bit like if you were
> trying to
> implement multiple undo on a wiki site like wikipedia where they are
> multiple contributors.
>
> We probably do not want the kernel to "undo", just the front end.
> So one
> solution would be to make the kernel and the user to appear as a
> single
> contributor, and to undo both effects on the front end. So one undo
> might
> remove an output created by the kernel.
>
> Even that is challenging, because Dynamics now create a lot of
> updates and
> you will not want to roll those back.
>
> Anyway, the front end team is obviously smart enough to find a
> solution for
> all those things, but it is not going to be easy.
>
> A cheap thing that I would like to see, is a text buffer of all my
> input and
> all the code I deleted saved as a log on disk. It might be ugly,
> but it
> would be VERY USEFUL.
>
> Cheers,
>
> Luc
>
>
> On 6/7/07 3:34 AM, "David Bailey" <dave@Remove_Thisdbailey.co.uk>
> wrote:
>
>> David wrote:
>>> Will Robertson wrote:
>>>> Hello,
>>>>
>>>> I am baffled that technical software is released in 2007 with
>>>> only a
>>>> single undo level. Am I missing something here? Is it because I'm
>>>> using a student license? How hard can an undo stack really be in
>>>> the
>>>> notebook interface?
>>>>
>>>> I've been irritated a few times in v5.2 from clumsy keypresses
>>>> losing
>>>> me work that I would expect to be two "undo"s away. Alas not.
>>>> Still.
>>>>
>>>> Will Robertson
>>>>
>>>>
>>>
>>> Good point! I've wondered the same thing for a long time. This is
>>> the
>>> only app I run that doesn't happen multiple levels of undo. I
Chris Chiasson
What are the downsides of storing diffs of the notebook expression in
memory after each event, such as key strokes or the end of an
evaluation, and using those diffs to perform undos?
On 6/6/07, Will Robertson <wsp...@gmail.com> wrote:
> Hello,
>
> I am baffled that technical software is released in 2007 with only a
> single undo level. Am I missing something here? Is it because I'm
> using a student license? How hard can an undo stack really be in the
> notebook interface?
>
> I've been irritated a few times in v5.2 from clumsy keypresses losing
> me work that I would expect to be two "undo"s away. Alas not. Still.
>
> Will Robertson
>
>
>
Chris Chiasson
then everyone would still be using it.
> >>> Will Robertson wrote:
> >>>> Hello,
> >>>>
> >>>> I am baffled that technical software is released in 2007 with
> >>>> only a
> >>>> single undo level. Am I missing something here? Is it because I'm
> >>>> using a student license? How hard can an undo stack really be in
> >>>> the
> >>>> notebook interface?
> >>>>
> >>>> I've been irritated a few times in v5.2 from clumsy keypresses
> >>>> losing
> >>>> me work that I would expect to be two "undo"s away. Alas not.
> >>>> Still.
> >>>>
> >>>> Will Robertson
> >>>>
> >>>>
> >>>
> >>> Good point! I've wondered the same thing for a long time. This is
> >>> the
> >>> only app I run that doesn't happen multiple levels of undo. I
> >>> think it's
> >>> time WRI spent some time on this issue.
> >>>
> >> How much time could it possibly take! Once you have a 1-level undo
> >> working, all you need to do is spill the relevant data into a
> >> structure
> >> - possibly on disk - and retrieve it as needed!
> >>
> >> David Bailey
> >> http://www.dbaileyconsultancy.co.uk
> >>
> >
> >
>
>
>
Andrzej Kozlowski
rather doubtful to me, but is completely irrelevant. I think you
completely missed the point of the article, which does not claim the
older software was better, but only that a lot of new software
(certainly not all) is "bloated" - a completely different thing. Did
you really think that the reason I posted this link was because I
would rather use Mathematica 1 than Mathematica 6?
Andrzej Kozlowski
Chris Chiasson
> The idea that people always run the best software they could seems
> rather doubtful to me, but is completely irrelevant. I think you
> completely missed the point of the article, which does not claim the
> older software was better, but only that a lot of new software
> (certainly not all) is "bloated" - a completely different thing. Did
> you really think that the reason I posted this link was because I
> would rather use Mathematica 1 than Mathematica 6?
Andrzej Kozlowski,
I read the article when it was linked from (I think) Slashdot a while
ago, so I have had time to think about it and form an opinion.
Basically, I do believe that software bloat does exist. However, many
features, while they may be computationally inefficient, are actually
quite convenient and useful. How many times have you lost something
beyond the first undo level in Mathematica? Wouldn't multiple undo
levels have been useful? I understand that the feature will decrease
performance (even further, heh), but I do not think the optimum
balance of features vs. performance has been attained here.
Sincerely,
Andrzej Kozlowski
On 9 Jun 2007, at 20:12, Chris Chiasson wrote:
> On 6/9/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
>> *This message was transferred with a trial version of CommuniGate
>> (tm) Pro*
There are a few features that are useful to everyone, and there are
many that are useful only to some but (unless they are made somehow
optional), will slow down everyone, forcing people either to get new
hardware or give up other features that they really need by having to
stick with older versions.
I agree that a multiple undo would occasionally be useful, but I
certainly would not pay the price of having my computer paralyzed for
a few minutes every time time I save. Besides, I can think of many
other features, more directly relevant to the main purpose of
Mathematica, that I would rather have than this one. Of course a
simple kind of multiple undo, one that only undoes typing and not
evaluation, might not present any problems, though it would hardly be
worth making so much fuss about. Anything that would bring my
computer to a halt is unacceptable to me, however nice it might be
for people who alsways have the latest hardware. All I wanted to
point out is that there is also this aspect to features like this one
and I hope that WRI does not forget about it when designing new
versions.
Andrzej Kozlowski
Chris Chiasson
Murray Eisenberg
be set up, each new version replaces the last. This is dangerous in
that a huge amount of work could still be too easily lost.
A usable substitute is a 3rd party general utility, such as CS-RCS
revision control system or, more simply, a multiple-version backup
imaging utility. (On my Windows system, I use a PC Magazine utility
Insta-Back, where I can specify what folders and files to back up and
how many levels to maintain.)
Brett Champion wrote:
> On Jun 8, 2007, at 4:33 AM , Helen Read wrote:
>
>> Selwyn Hollis wrote:
>>> Ah, that's at the top of my gripes list too. I'm pretty sure that
>>> Undo is even less functional in 6 than in 5.2.
>> Undo seems kind of buggy in 6. I've lost things that just didn't go
>> back
>> to the way they were when I tried to Undo (after e.g. accidentally
>> pasting when I meant to copy).
>>
>>> Another shortcoming is the lack of AutoSave or AutoBackup capability.
>>> It's too easy to lose track of time, crash, and then discover that
>>> you haven't saved anything in 2 hours. (Or maybe its just dementia on
>>> my part.)
>> I'm fairly obsessive about saving frequently, but I cannot for the
>> life
>> of me get my students to do it. A few times a semester, someone will
>> crash Mathematica at the very end of a class period when they are
>> taking
>> a quiz or exam, without having saved a thing. Built-in AutoSave
>> would be
>> nice to have.
>
> Would the NotebookAutoSave option work for you?
>
> http://reference.wolfram.com/mathematica/ref/NotebookAutoSave.html
>
> It saves the notebook after each evaluation, provided the notebook
> has been saved once already.
>
> (NotebookAutoSave has been around for several versions.)
>
>
> Brett Champion
> Wolfram Research
>
--
DrMajorBob
usually; I like layered undo in that situation. Excel is a much easier
environment in which to PROVIDE multiple undo, too.
Overall, though, I agree with Andrzej that good work habits are the best
protection against errors.
Bobby
On Sun, 10 Jun 2007 22:12:49 -0500, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:
> I agree. I think lots of "features" of programs like word-processors,
> spread-sheets etc., would not be needed if people were willing simply to
> adjust sensibly their working habits. They would gain better performance
> and better working habits.
>
> Andrzej Kozlowski
>
>
> On 11 Jun 2007, at 11:58, DrMajorBob wrote:
>
>> If I have useful stuff in a cell, but I need to edit it, and I'm afraid
>> I might delete things I need, add things I don't need, change things
>> that are already perfect... well...
>>
>> I just copy the cell and paste it above or below, and I edit the copy,
>> leaving the original alone!
>>
>> Or, if there's a lot of editing going on, I copy/save the whole file!
>>
>> Later, when I've gotten moronic and made a mistake (it happens!), the
>> original is still there. I can copy/paste between the two versions
>> until I'm happy, the code's happy, and nobody else cares!
>>
>> That's WAY more flexible than multiple undo could ever be, isn't it??
>>
>> I mean, what if the change three layers back was bad, but the last TWO
>> changes were great (and time-consuming)? How can undo help with that?
>> How can I even keep track of which changes were good and which were
>> bad, with undo? I can't!
>>
>> WRI already provided copy, cut, paste, color-codes for missing brackets
>> and undefined symbols, automatic structure-based indentation... haven't
>> they done enough?
>>
>> Really, at some point, you gotta wonder... could it BE any sweeter than
>> this?
>>
>> Bobby
>>
>> On Sun, 10 Jun 2007 06:24:17 -0500, Andrzej Kozlowski
>> <ak...@mimuw.edu.pl> wrote:
>>
>>>
>>> On 9 Jun 2007, at 20:12, Chris Chiasson wrote:
>>>
>>>> On 6/9/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
>>> worth making so much fuss about. Anything that would bring my
>>> computer to a halt is unacceptable to me, however nice it might be
>>> for people who alsways have the latest hardware. All I wanted to
>>> point out is that there is also this aspect to features like this one
>>> and I hope that WRI does not forget about it when designing new
>>> versions.
>>>
>>> Andrzej Kozlowski
>>>
>>>
>>
>>
>>
>> --DrMaj...@bigfoot.com
>
>
Andrzej Kozlowski
DrMajorBob
DrMajorBob
least of our problems, and slow code in the front end is not much bigger.
Multiple undo is a poor use of WRI's time (in the complicated notebook
environment), for a different reason (I'll get to it).
> How many times have you lost something
> beyond the first undo level in Mathematica?
What if the sequence was bad change, good change, bad, good, good. Won't
multiple undo lose more good changes than bad?
There are better ways we can guard against our own blunders and, as
Andrzej says, there are far more useful features WRI can work on.
Bobby
On Sun, 10 Jun 2007 06:23:15 -0500, Chris Chiasson <ch...@chiasson.name>
wrote:
> On 6/9/07, Andrzej Kozlowski <ak...@mimuw.edu.pl> wrote:
>> The idea that people always run the best software they could seems
>> rather doubtful to me, but is completely irrelevant. I think you
>> completely missed the point of the article, which does not claim the
>> older software was better, but only that a lot of new software
>> (certainly not all) is "bloated" - a completely different thing. Did
>> you really think that the reason I posted this link was because I
>> would rather use Mathematica 1 than Mathematica 6?
>
> Andrzej Kozlowski,
>
> I read the article when it was linked from (I think) Slashdot a while
> ago, so I have had time to think about it and form an opinion.
> Basically, I do believe that software bloat does exist. However, many
> features, while they may be computationally inefficient, are actually
> quite convenient and useful. How many times have you lost something
> beyond the first undo level in Mathematica? Wouldn't multiple undo
> levels have been useful? I understand that the feature will decrease
> performance (even further, heh), but I do not think the optimum
> balance of features vs. performance has been attained here.
>
> Sincerely,
>
Chris Chiasson
On 6/11/07, DrMajorBob <drmaj...@bigfoot.com> wrote:
> In Excel, if you copy a cell into another cell, you've also changed it,
> usually; I like layered undo in that situation. Excel is a much easier
> environment in which to PROVIDE multiple undo, too.
>
You are certainly right that it would be very difficult to provide an
undo that operates on the entire environment. However, that is
probably not necessary. Think about Eclipse and Java. Eclipse provides
"continuous" compilation of Java source code, but its undo operates
only on the text of the source code. In Mathematica, the underlying
notebook box expressions (usually?) only change when the user is
editing or evaluating. Why can't notebook diffs be made and stored
after each edit and evaluation? I am sure there is a good technical
reason or two, but I don't think the inability to roll back the state
of the kernel is a deal-breaking problem.
> Overall, though, I agree with Andrzej that good work habits are the best
> protection against errors.
I agree, but that doesn't mean I couldn't use some help.
Selwyn Hollis
of the current InputNotebook -- with output cells deleted -- is
Exported into a backup folder in your $HomeDirectory.
CreateDocument[PaletteNotebook[
Button["Bare Bones Backup",
Module[{filename, thisnb = InputNotebook[]},
If[thisnb =!= $Failed,
CreateDirectory[ToFileName[{$HomeDirectory, "MathBackups"}]];
filename = StringJoin[
StringReplace[(WindowTitle /. AbsoluteOptions[thisnb]),
s_ ~~ ".nb" -> s], "_",
StringJoin[ToString /@ Round /@ Rest[Date[]]], ".nb"];
Export[ToFileName[{$HomeDirectory, "MathBackups"}, filename],
DeleteCases[NotebookGet[thisnb], Cell[_, "Output", ___],
Infinity]]
] ] ] ] ]
(Button is new to 6, but the function inside Button should work fine
in 5.2.)
I've got a version of this that runs automatically every 15 minutes
(you can change the interval, of course). Anyone who's interested
should let me know.
Selwyn Hollis
Szabolcs
> If I have useful stuff in a cell, but I need to edit it, and I'm afraid I
> might delete things I need, add things I don't need, change things that
> are already perfect... well...
>
> I just copy the cell and paste it above or below, and I edit the copy,
> leaving the original alone!
And what if you are a bit tired, and press ctrl-v instead of ctrl-c by
accident? V is right next to C on an English keyboard. Then you are
exactly one keystroke away from loosing the contents of the cell.
Undo is not some kind of version control, it is there for undoing
mistakes. I don't understand why are some people arguing so strongly
against it. Saying that multiple undo (simple *editor undo*, not
something interacting with the kernel) is a waste of resources is simply
nonsense, especially if single-level undo is already implemented.
The Mathematica front end is probably the last editor in the 21st
century that still does not support multiple undos. If you have never
made any stupid mistake that could have been easily undone in 2 or 3
steps then I envy you, but it does not make things better for the rest
of us.
DrMajorBob
Bobby
On Tue, 12 Jun 2007 00:16:27 -0500, Chris Chiasson <ch...@chiasson.name>
wrote:
> Warning: speculation ahead
DrMajorBob
things), but this does:
CreatePalette[{Button["Bare Bones Backup",
Module[{filename, thisnb = InputNotebook[]},
If[thisnb =!= $Failed,
CreateDirectory[
ToFileName[{$UserBaseDirectory, "MathBackups"}]];
filename =
StringJoin[
StringReplace[(WindowTitle /. AbsoluteOptions[thisnb]),
s_ ~~ ".nb" -> s], "_",
StringJoin[ToString /@ Round /@ Rest[Date[]]], ".nb"];
Export[
ToFileName[{$UserBaseDirectory, "MathBackups"}, filename],
DeleteCases[NotebookGet[thisnb], Cell[_, "Output", ___],
Infinity]]]]]}];
Execute the code, and it creates the palette. Now... and this is dumb...
grab the palette and move it. Then close it, and Mathematica asks if you
want to save the palette.
If you DON'T move it, there's no way (I can find) to save the palette.
Using Selwyn's CreateDocument version, even moving the palette doesn't
work.
I discovered the needed changes by trial and error; the documentation was
no help at all. There are dozens of palette and notebook creation
examples, but none of them (that I could find) show how to save the result.
Bobby
On Tue, 12 Jun 2007 00:23:53 -0500, Selwyn Hollis <sh2....@earthlink.net>
wrote:
-- =
Selwyn Hollis
Thanks again for the Windows repairs. On the saveability issue, wrap
SetOptions around it with the option Saveable->True.
-Selwyn
Selwyn Hollis
(which is new in 6).
- Selwyn
David
You're right on. I'm amazed that anyone would argue against a
multi-level undo for notebook input text corrections. Especially, that
it would take processor time away from the CPU or development time away
from the developers. I don't think anyone is suggesting multi-level undo
for input and output. I use some drawing/image processing apps that do
muli-level undo on very complicated images with "no problemo". Seems
like this would be a piece of cake challenge for the wizards at Wolfram.
DrMajorBob
1) Documentation says Saveable->True is the default, and
2) judging from its behavior, the option should be =
"SaveableWithoutMovingItFirst->True".
Bobby
On Tue, 12 Jun 2007 08:55:48 -0500, Selwyn Hollis <sh2....@earthlink.ne=
t> =
wrote:
> Bobby,
>
> Thanks again for the Windows repairs. On the saveability issue, wrap =
> SetOptions around it with the option Saveable->True.
>
> -Selwyn
>
>
> On Jun 12, 2007, at 4:58 AM, DrMajorBob wrote:
>
>> That doesn't work in Windows ($HomeDirectory is read-only, among othe=
r =
>> things), but this does:
>>
>> CreatePalette[{Button["Bare Bones Backup",
>> Module[{filename, thisnb = InputNotebook[]},
>> If[thisnb =!= $Failed,
>> CreateDirectory[
>> ToFileName[{$UserBaseDirectory, "MathBackups"}]];
>> filename =
>> StringJoin[
>> StringReplace[(WindowTitle /. AbsoluteOptions[thisnb]),
>> s_ ~~ ".nb" -> s], "_",
>> StringJoin[ToString /@ Round /@ Rest[Date[]]], ".nb"];
>> Export[
>> ToFileName[{$UserBaseDirectory, "MathBackups"}, filename],
>> DeleteCases[NotebookGet[thisnb], Cell[_, "Output", ___],
>> Infinity]]]]]}];
>>
>> Execute the code, and it creates the palette. Now... and this is =
>> dumb... grab the palette and move it. Then close it, and Mathematica =
=
>> asks if you want to save the palette.
>>
>> If you DON'T move it, there's no way (I can find) to save the palette=
. =
>> Using Selwyn's CreateDocument version, even moving the palette doesn'=
t =
>> work.
>>
>> I discovered the needed changes by trial and error; the documentation=
=
>> was no help at all. There are dozens of palette and notebook creation=
=
>> examples, but none of them (that I could find) show how to save the =
>> result.
>>
>> Bobby
>>
>> On Tue, 12 Jun 2007 00:23:53 -0500, Selwyn Hollis =
>> <sh2....@earthlink.net> wrote:
>>
>>> This is something I've wanted for years. Click the button, and a cop=
y
>>> of the current InputNotebook -- with output cells deleted -- is
>>> Exported into a backup folder in your $HomeDirectory.
>>>
>>> CreateDocument[PaletteNotebook[
>>> Button["Bare Bones Backup",
>>> Module[{filename, thisnb = InputNotebook[]},
>>> If[thisnb =!= $Failed,
>>> CreateDirectory[ToFileName[{$HomeDirectory, "MathBackups"}]];
>>> filename = StringJoin[
>>> StringReplace[(WindowTitle /. AbsoluteOptions[thisnb]),
>>> s_ ~~ ".nb" -> s], "_",
>>> StringJoin[ToString /@ Round /@ Rest[Date[]]], ".nb"];
>>> Export[ToFileName[{$HomeDirectory, "MathBackups"}, filename],
>>> DeleteCases[NotebookGet[thisnb], Cell[_, "Output", ___],
>>> Infinity]]
>>> ] ] ] ] ]
>>>
>>> (Button is new to 6, but the function inside Button should work fine=
>>> in 5.2.)
>>>
>>> I've got a version of this that runs automatically every 15 minutes
>>> (you can change the interval, of course). Anyone who's interested
>>> should let me know.
>>>
>>> Selwyn Hollis
>>>
>>>
>>
>>
>>
>> --DrMaj...@bigfoot.com
>
>
-- =
Will Robertson
> As computers get faster and hard-disks get larger, bloated code is the
> least of our problems, and slow code in the front end is not much bigger.
> Multiple undo is a poor use of WRI's time (in the complicated notebook
> environment), for a different reason (I'll get to it).
Wow. Multiple undo is bloat.
As opposed to a visual representation of a notebook as it has changed
over time, but which can't be used to actually roll back to previous
states.
> What if the sequence was bad change, good change, bad, good, good. Won't
> multiple undo lose more good changes than bad?
What if the sequence was good bad bad bad bad?
The thing is, you want to give people the option -- your example plays
to the workflow that you're suggesting, keeping multiple documents and
cells lying around just to save the progress of your work.
The complaints about implementing undo being complicated because of
the kernel miss the point. I don't really care about rolling back the
state of the kernel. It's cell input *that I make* that I want to be
able to remove. Like the case when I make a mistake and go to hit Ctrl-
Z but type "Z" instead. Bam, there goes my precious undo.
I concede that this would be possibly confusing if you undo an
assignment and then forget about it. But that wouldn't outweight the
convenience of being able to do so in the first place.
Best regards,
Will
Carabe - Fernandez, Alejandro
Plot3D[0.075+0.916*(1/Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let]+(1-(1/Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let])*1/(0.05 t+1),{t,0,100},{let,1,500}]
where I want to plot it so the LET axes appears in logarihtmic scale.
Also, I'd like to add data points to this plot. How could I do that?
Do I have to merge a normal Plot3D with a ListPlot3D? Could I get the
Plot3D transparent so the points under the surface can also be seem?
Thank you for your kind help
Alex
________________________________
From: DrMajorBob [mailto:drmaj...@bigfoot.com]
Sent: Wed 13/06/2007 12:34
Subject: Bare Bones Backup Button
That works, but it maks no sense for two reasons:
1) Documentation says Saveable->True is the default, and
2) judging from its behavior, the option should be
"SaveableWithoutMovingItFirst->True".
Bobby
On Tue, 12 Jun 2007 08:55:48 -0500, Selwyn Hollis <sh2....@earthlink.net>
wrote:
> Bobby,
>
> Thanks again for the Windows repairs. On the saveability issue, wrap
> SetOptions around it with the option Saveable->True.
>
> -Selwyn
>
>
> On Jun 12, 2007, at 4:58 AM, DrMajorBob wrote:
>
>> That doesn't work in Windows ($HomeDirectory is read-only, among other
>> things), but this does:
>>
>> CreatePalette[{Button["Bare Bones Backup",
>> Module[{filename, thisnb = InputNotebook[]},
>> If[thisnb =!= $Failed,
>> CreateDirectory[
>> ToFileName[{$UserBaseDirectory, "MathBackups"}]];
>> filename =
>> StringJoin[
>> StringReplace[(WindowTitle /. AbsoluteOptions[thisnb]),
>> s_ ~~ ".nb" -> s], "_",
>> StringJoin[ToString /@ Round /@ Rest[Date[]]], ".nb"];
>> Export[
>> ToFileName[{$UserBaseDirectory, "MathBackups"}, filename],
>> DeleteCases[NotebookGet[thisnb], Cell[_, "Output", ___],
>> Infinity]]]]]}];
>>
>> Execute the code, and it creates the palette. Now... and this is
>> dumb... grab the palette and move it. Then close it, and Mathematica
>> asks if you want to save the palette.
>>
>> If you DON'T move it, there's no way (I can find) to save the palette.
>> Using Selwyn's CreateDocument version, even moving the palette doesn't
>> work.
>>
>> I discovered the needed changes by trial and error; the documentation
>> was no help at all. There are dozens of palette and notebook creation
>> examples, but none of them (that I could find) show how to save the
>> result.
>>
>> Bobby
>>
>> On Tue, 12 Jun 2007 00:23:53 -0500, Selwyn Hollis =
>> <sh2....@earthlink.net> wrote:
>>
>>> This is something I've wanted for years. Click the button, and a copy
>>> of the current InputNotebook -- with output cells deleted -- is
>>> Exported into a backup folder in your $HomeDirectory.
>>>
>>> CreateDocument[PaletteNotebook[
>>> Button["Bare Bones Backup",
>>> Module[{filename, thisnb = InputNotebook[]},
>>> If[thisnb =!= $Failed,
>>> CreateDirectory[ToFileName[{$HomeDirectory, "MathBackups"}]];
>>> filename = StringJoin[
>>> StringReplace[(WindowTitle /. AbsoluteOptions[thisnb]),
>>> s_ ~~ ".nb" -> s], "_",
>>> StringJoin[ToString /@ Round /@ Rest[Date[]]], ".nb"];
>>> Export[ToFileName[{$HomeDirectory, "MathBackups"}, filename],
>>> DeleteCases[NotebookGet[thisnb], Cell[_, "Output", ___],
>>> Infinity]]
>>> ] ] ] ] ]
>>>
>>> (Button is new to 6, but the function inside Button should work fine
>>> in 5.2.)
>>>
>>> I've got a version of this that runs automatically every 15 minutes
>>> (you can change the interval, of course). Anyone who's interested
>>> should let me know.
>>>
>>> Selwyn Hollis
>>>
>>>
>>
>>
>>
>> --DrMaj...@bigfoot.com
>
>
Andrzej Kozlowski
On 13 Jun 2007, at 20:32, David wrote:
> I'm amazed that anyone would argue against a
> multi-level undo for notebook input text corrections. Especially, that
> it would take processor time away from the CPU or development time
> away
> from the developers. I don't think anyone is suggesting multi-level
> undo
> for input and output.
I'm amazed that anyone would join a thread without reading it. For
example, who is it who argued against "multi-level undo for notebook
text input corrections"? Could you post a quote? I myself wrote
explicitly:
> Of course a
> simple kind of multiple undo, one that only undoes typing and not
> evaluation, might not present any problems, though it would hardly be
> worth making so much fuss about.
Yes, this kind of undo is obviously such a trivial matter that I
would certainly not have wasted any time to argue against (or for it).
Then there is you assertion:
> I don't think anyone is suggesting multi-level undo
> for input and output.
Have you tried reading this thread before sending your response? Have
you looked at the posts by
David Reiss, Luc Barthelet and David Bailey? They all discuss more
than just text-input only undo. They don't necessarily argue clearly
in favour of it, but they all consider it a possibility, which means
that it was an issue considered in this thread.
I will just quote Luc:
> While I strongly support that multiple undo is a feature we need to
> see
> soon, it will take some real work to get there.
Given that the issue of a more than text-input level undo had already
been raised it does not seem to me so amazing that some people,
(myself and Bobby Treat) would wish to point out their own attitude
to it. I clearly indicated that I was not referring to "text input
only" undo.
I suggest to you (and others who have written in a similar vain) that
it is a very good practice to read all the posts in a thread you
decide to join particularly if you are intending to make sweeping
statements of the type "nobody is suggesting" etc.
Andrzej Kozlowski
Jens-Peer Kuska
a)
Plot3D[0.075 +
0.916*(1/
Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let] + (1 - (1/
Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let])*1/(0.05 t +
1) /. let -> Exp[let], {t, 0, 100}, {let, 1, 2.698}]
should do the Log[] Scale of the let axis.
What means "add points" ??
Do you want more PlotPoints ??
Transparency is only possible with Mathematica 6.0
and
Plot3D[0.075 +
0.916*(1/
Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let] + (1 - (1/
Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let])*1/(0.05 t +
1) /. let -> Exp[let], {t, 0, 100}, {let, 1, 2.698},
ColorFunction -> (Hue[#3, 1, 1, 0.5] &)]
would do that ...
Regards
Jens
David
generalization that "nobody is suggesting". My apologies for that
mistake. I should have narrowed that to say that "those that want a
reasonable implementation of multi-level undo is suggesting". My
inference from the OP is that a typical multi-level undo in the "MS
Windows or Apple application multi-level undo" paradigm was the desire.
It's as simple as that. Others decided to make it much, much more
complicated.
I've followed the entire thread. A thread that turned into a mish-mash
of well meaning, but "off the initial point", posts. Some posts are
talking about autosave, which is not the undo that the OP refers to, in
my opinion. Or, some have implied/suggested that the feature might need
to undo kernel states. That just turns multi-level undo into a massive,
unnecessary feature, again, in my opinion.
You asked for a quote... one of your posts is one of those that would
seem to argue against multi-level undo because it might slow down your
computer or the WRI developers from more important tasks. If you're not
arguing against, then I don't understand why you posted to this thread
and why you made the following statements.
---Andjez Koslowski wrote:---
There are a few features that are useful to everyone, and there are
many that are useful only to some but (unless they are made somehow
optional), will slow down everyone, forcing people either to get new
hardware or give up other features that they really need by having to
stick with older versions.
I agree that a multiple undo would occasionally be useful, but I
certainly would not pay the price of having my computer paralyzed for
a few minutes every time time I save. Besides, I can think of many
other features, more directly relevant to the main purpose of
Mathematica, that I would rather have than this one. Of course a
simple kind of multiple undo, one that only undoes typing and not
evaluation, might not present any problems, though it would hardly be
worth making so much fuss about. Anything that would bring my
computer to a halt is unacceptable to me, however nice it might be
for people who alsways have the latest hardware. All I wanted to
point out is that there is also this aspect to features like this one
and I hope that WRI does not forget about it when designing new
versions.
Andrzej Kozlowski
---
I will not reply to any future dissections of my posts by you.
Roger Bagula
>Hello, I am sure this has been asked before but I was wondering if you could help me with ploting the following function in 3D:
>
>Plot3D[0.075+0.916*(1/Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let]+(1-(1/Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01 let])*1/(0.05 t+1),{t,0,100},{let,1,500}]
>
>where I want to plot it so the LET axes appears in logarihtmic scale.
>
>Also, I'd like to add data points to this plot. How could I do that?
>Do I have to merge a normal Plot3D with a ListPlot3D? Could I get the
>Plot3D transparent so the points under the surface can also be seem?
>
>Thank you for your kind help
>
>Alex
>
>
>
>
>
>
Clear[let, llet]
let = Exp[llet]
Plot3D[0.075 + 0.916*(1/Exp[-Exp[-0.075 2]])*0.01 let Exp[-0.01
let] + (1 - (1/Exp[-Exp[-0.075 2]])*0.01
let Exp[-0.01 let])*1/(0.05 t + 1), {t, 0, 100}, {llet, 0, Log[500]}]
Andrzej Kozlowski
On 15 Jun 2007, at 17:29, David wrote:
Everything I wrote still seems very clear to me, but since there is
at least one person who thinks otherwise, I will try to make it even
clearer. T
1. First, let's imagine the most optimistic scenario. A complete
multiple undo of everything in Mathematica, at 0 cost in performance
and all developed by one of WRI's brilliant programmers outside work
hours (just out of kindness or for fun) in order to make a free gift
to all Mathematica users. Would I be against it? No way! I don't
normally refuse free gifts (in case anyone was wondering) and I am
sure I would find a good use for this sort of thing. Even if, instead
fo the above, we were offered only a multiple undo of input text
only, but also at no cost in performance or development time, I would
not have any problems with it (even though I can't remember ever
having found myself missing this feature).
2. On the other hand: even the most perfect multiple undo is
unacceptable to me if it is going to make my computer unusable. I
change my computer (I only work on Mac laptops) approximately every 3
years and I always find that near the end of this period it feels
slower than my ancient Mac Plus (which I still have). I have no
desire and can't really afford to reduce the length of this cycle.
3. As for the feature itself, I would of course like to have it under
the conditions described in point 1, but other than that I can think
of many other features I would rather have instead. I could, at this
point, start listing them, but that would really be off topic and
would require more time and space than I am willing to devote to this
issue.
Andrzej Kozlowski
>
> You asked for a quote... one of your posts is one of those that would
> seem to argue against multi-level undo because it might slow down your
> computer or the WRI developers from more important tasks. If you're
> not
> arguing against, then I don't understand why you posted to this thread
> and why you made the following statements.
>
> ---Andjez Koslowski wrote:---
>
> There are a few features that are useful to everyone, and there are
> many that are useful only to some but (unless they are made somehow
> optional), will slow down everyone, forcing people either to get new
> hardware or give up other features that they really need by having to
> stick with older versions.
> I agree that a multiple undo would occasionally be useful, but I
> certainly would not pay the price of having my computer paralyzed for
> a few minutes every time time I save. Besides, I can think of many
> other features, more directly relevant to the main purpose of
> Mathematica, that I would rather have than this one. Of course a
> simple kind of multiple undo, one that only undoes typing and not
> evaluation, might not present any problems, though it would hardly be
> worth making so much fuss about. Anything that would bring my
> computer to a halt is unacceptable to me, however nice it might be
> for people who alsways have the latest hardware. All I wanted to
> point out is that there is also this aspect to features like this one
> and I hope that WRI does not forget about it when designing new
> versions.
>
> Andrzej Kozlowski
>
Murray Eisenberg
Yes, I'd like to see your auto-backup version.
Murray
Selwyn Hollis wrote:
> This is something I've wanted for years. Click the button, and a copy
> of the current InputNotebook -- with output cells deleted -- is
> Exported into a backup folder in your $HomeDirectory.
>
> CreateDocument[PaletteNotebook[
> Button["Bare Bones Backup",
> Module[{filename, thisnb = InputNotebook[]},
> If[thisnb =!= $Failed,
> CreateDirectory[ToFileName[{$HomeDirectory, "MathBackups"}]];
> filename = StringJoin[
> StringReplace[(WindowTitle /. AbsoluteOptions[thisnb]),
> s_ ~~ ".nb" -> s], "_",
> StringJoin[ToString /@ Round /@ Rest[Date[]]], ".nb"];
> Export[ToFileName[{$HomeDirectory, "MathBackups"}, filename],
> DeleteCases[NotebookGet[thisnb], Cell[_, "Output", ___],
> Infinity]]
> ] ] ] ] ]
>
> (Button is new to 6, but the function inside Button should work fine
> in 5.2.)
>
> I've got a version of this that runs automatically every 15 minutes
> (you can change the interval, of course). Anyone who's interested
> should let me know.
>
> Selwyn Hollis
>
--