Pluto.jl: Feature Request: Watch for updates to the underlying .jl file

Created on 30 Jul 2020  路  7Comments  路  Source: fonsp/Pluto.jl

One thing that would be nice is if I have a Pluto notebook, Foo.jl, and then if I opened Foo.jl in my editor, changed and saved something in the editor, I would want the Pluto notebook to automatically update.

enhancement help welcome one day

Most helpful comment

It's not part of my overall goal of making computing more accessible, but it is something that I (as an experienced programmer) would like to experiment with.

I feel there is a bit of a false dichotomy here - that experienced programmers want this kind of features, but novice users should not interact with text any other ways than through a plain text box. Inputting text is a serious business, one to which entire projects have been dedicated, and which is not easy to replicate in a project such as Pluto (and indeed Jupyter as well). Anybody serious about computing (in the broadest sense) should spend at least some time learning the tools of the trade (any good editor, as long as it's not a plain text box), and hybrid solutions (eg a notebook that allows users to use a text editor) are a productivity boost for any user. Attaching Pluto notebooks to a particular file and having two-way synchronization seems to be a very good way to achieve that. I understand it's not a priority though.

All 7 comments

It's not part of my overall goal of _making computing more accessible_, but it is something that I (as an experienced programmer) would like to experiment with.

I am also reluctant, I feel like it is a lot of work to get this right, because there is no obvious bijection between Julia files and Pluto notebooks. See my comments here about why this is difficult: https://github.com/fonsp/Pluto.jl/issues/131#issuecomment-636764311 . One thing that I would like to emphasize is that _Pluto is a project to design an IDE_, this is what I find fascinating to work on!

One thing that was annoying to me is if I have a notebook open, and do a git pull which applies a change cleanly to the notebook, I still see the old notebook until I restart Pluto (refreshing the page also doesn't change it.)

It's not part of my overall goal of making computing more accessible, but it is something that I (as an experienced programmer) would like to experiment with.

I feel there is a bit of a false dichotomy here - that experienced programmers want this kind of features, but novice users should not interact with text any other ways than through a plain text box. Inputting text is a serious business, one to which entire projects have been dedicated, and which is not easy to replicate in a project such as Pluto (and indeed Jupyter as well). Anybody serious about computing (in the broadest sense) should spend at least some time learning the tools of the trade (any good editor, as long as it's not a plain text box), and hybrid solutions (eg a notebook that allows users to use a text editor) are a productivity boost for any user. Attaching Pluto notebooks to a particular file and having two-way synchronization seems to be a very good way to achieve that. I understand it's not a priority though.

Thanks for your input! I did not look at it that way :)

PRs welcome as an experiment, but it's not a priority, and it will not be implemented if it gets too complicated.

Could this be extended to include watching external files on which the notebook is dependent? A lot of workflows involve generating a file with some external tools that is the primary input for a notebook, and/or use files as intermediate steps. Not being able to watch these "breaks" reactivity in a sense.

It looks like a basic version of this could be implemented using Clock from PlutoUI.jl, but AFAICT that would trigger downstream cell updates whether or not the file contents have changed. Actually more generally can Pluto prevent this kind of needless downstream updates and/or is there a way to implement such a thing? Even if it wasn't automatic--it would be nice to be able in particular to prevent longer running cells from recomputing, or at least to be able to mark certain cells for manual recomputation. Wow, this comment has gone really OT 馃檭.

Good suggestion! But could you move it to #115?

Was this page helpful?
0 / 5 - 0 ratings