Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Anyone test it to see if it has reasonable undo/redo support yet?

That alone would almost be reason enough to upgrade.



Dito. This is a total show stopper. Only undoing your very last action and with no redo really sucks. I repeat that as it might sound like a joke to most people. There is no redo. And you can only undo one thing, where "one thing" might be typing a massive formula with all the correct mathematical notation or one full page of text.

So if you undo your last 5 minutes of work because you thought you would undo one line or something there is no way to get it back. T________T

If you deleting something inside that one thing you are currently typing, that deletion is also completely impossible to undo because if you do you will undo typing that entire block. (Undoing a small accidental delete is usually the cause of the scenario i described above)


Yeah, it kinda sucks -- mostly one learns to create new copies of definitions/code when doing substantial changes, which the notebook interface makes quite convenient. Or use a full blown editor like Eclipse.

The holy grail as I see it would be storing the entire edit history of the document as a git-like tree of modifications, which is entirely possible because Mathematica notebooks are themselves built out of Mathematica expressions (see for example Cell http://reference.wolfram.com/mathematica/ref/Cell.html). This would be similar to Rich Hickey's work on language-aware version control (http://blog.datomic.com/2012/10/codeq.html)


You're right, huge problem. At the very least I want to be able to undo/redo up to my last shift+enter.


I almost forgot about this. Can someone please explain why this is so hard to implement?


I think partly the reason is that the document model of notebooks is quite complicated. Each notebook is a hierarchy of Mathematica expressions (technically, the box versions of the original Mathematica expressions) and an associated set of cascading style sheets that tell the frontend how to format things. There are some nice advantages that stem from this meta-homoiconicity, but also some disadvantages.

One of these disadvantages is that editing the notebook does quite weird things to this hierarchy, like embedding new cells inside existing ones, merging cells, and changing mutable state in the frontend in various ways. Figuring out how to intelligently support multiple levels of undo without leading to rapid garbage generation and/or corruption is I imagine a Hard Problem.

For the record, another disadvantage is that source versioning and diffing is nigh on impossible (unless it takes place at a higher level, which is an interesting idea I think the company should pursue).


> For the record, another disadvantage is that source versioning and diffing is nigh on impossible

I can attest to that! I have directories full of -v1.nb, -v2.nb, -v3.nb, -v3-fixed.nb files. Here's to hoping someone figures it out anyway :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: