Open juliasilge opened 11 months ago
DavisVaughan
commented
11 months ago I also think "send output to console" isn't a "sticky" option in RStudio, i.e. I have to select it for every Rmd I create. I have a feeling we can probably fix that here.
I think some of us have also discussed our desire for "send output to console" to be the default behavior in notebooks, so we should think about that too
jthomasmock
commented
11 months ago Just x-posting that we probably want to avoid some of the more surprising behavior, albeit most of that may only be present for R users: https://github.com/posit-dev/positron/issues/1418
jmcphers
commented
7 months ago @juliasilge Do you think this is still relevant after discussions at work week? i.e. do we want a "send to console" mode for .ipynb files?
It does seem possible that Python users will want to do this, but having lived in a world where there are two different modes (console/inline) for Rmd/Qmd files in RStudio, it has lead to quite a lot of confusion, complexity, and unforeseen edge cases, so much so that there is widespread rejoicing that we are moving away from having two modes for those files in Positron. Do we want to introduce this feature for .ipynb files?
juliasilge
commented
7 months ago For context, this feedback came out of the Oct 2023 session of our internal monthly Python OSS sync, and was one of about a half dozen specific requests for a desired notebook experience (I'll share the doc with you, @jmcphers).
It does seem possible that Python users will want to do this
I think this is not only possible but just plain the actual situation.
However, I am on board with us deciding it's not the right choice for us. We can decline based on our experience supporting .Rmd as notebooks in the RStudio IDE and affirm we believe this gives users a better experience:
.ipynb.qmdConverting is quite straightforward. It's never fun to say 🚫NO🚫 to something users want, but for sure this is an area where we have experience to draw from.
jmcphers
commented
7 months ago I think we can leave this as we collect additional feedback, but for reference, here are some of the things that have made this hard in RStudio:
I wouldn't say "we'd never do this" but I would say that before we did it we'd want to comb over all these issues and convince ourselves we have a design that learns from them.
juliasilge
commented
5 months ago This came up in private beta here: https://github.com/posit-dev/positron-beta/discussions/59
DavisVaughan
commented
2 months ago Another one
readline(), which doesn't seem great.
clauswilke
commented
2 months ago I was sent here by @juliasilge's comment in a different issue: https://github.com/posit-dev/positron/discussions/3718#discussioncomment-9938783 I'd like to comment on:
As of today,
- If you want an inline experience, use .ipynb
- If you want a send-to-console experience, use .qmd
I feel there are two separate issues here that are muddled together. One is the notebook file format and the other is where and how code gets executed and results are shown. I'd like to use the better file format (.qmd) together with the better execution model (inline, I'll explain below why it's objectively better in my opinion). I don't understand why the file format should be tied to the execution model.
More importantly, however, I've always felt that the notebook implementation in RStudio was broken. It mixes actions and outputs inside the notebook with actions and outputs in the console, and that confuses users and leads at times to unexpected results. You have the opportunity with Positron to fix this and I hope you'll do so.
A simple way to fix the issue is to just send everything to the console, but does this make sense? In particular in a multi-language environment (which Quarto explicitly is as far as I understand), the only way to do this correctly would be to have one console for each language. If I mix five languages in my notebook I need five separate consoles and need to somehow be able to keep track of where they are, what has happened in them, which output I'm currently seeing, etc. By contrast, if output is always shown inline then this problem doesn't exist. I don't need consoles at all. (That's how Jupyter works, and that's why I believe the inline execution model is objectively superior.)
Therefore, I believe the better model for .qmd files would be to separate them completely from the console. Run a separate R process in the console if you like, but have it not be affected by what happens in the notebook and vice versa. This is a logical and consistent approach, and most other parts of the development experience work this way. If I open a terminal whatever I do there doesn't impact the notebook or vice versa either. And if I start R (or python) in that terminal it also is completely separate.
Finally, if you want to have the option of sending commands from the .qmd to the console, you could consider two alternative modes:
I think both of these modes can be useful and are logically consistent. Any mix between the two modes is not. And I would predict that if you offered notebook mode as an option many users would pick it over console mode.
lukerobert
commented
2 months ago I don't understand why the file format should be tied to the execution model.
I agree that having the behavior depend on the file format is confusing as a user. Particularly between file formats that are supposed to be cross-compatible (.qmd and .ipynb) I think it's reasonable to expect the interface for editing them should be consistent. And if there are strong camps of users who prefer console vs inline I feel that should be accommodated as a user-level option rather than forcing users into a different file format. Otherwise, if I'm working on a notebook with a colleague and I prefer in-line and they prefer console does one of us need to convert the file format back and forth each time we open it?
I'd also like to add some more support and hopefully helpful user context for having output displayed inline in notebooks. My personal process when editing a qmd notebook is to frequently jump between sections, using insights from later outputs to readjust how I approach earlier parts of the notebook. Rarely do I find an analysis progresses linearly from start to end, which I think is consistent with the Foggy Garden of Forking Paths metaphor for analysis. Having all the outputs shown inline as I scroll back is hugely useful in this process. True, this does require a bit more cognitive management of the state of the session, but frequent use of the "run all previous chunks" button in RStudio largely addresses this. Personally I only actually render the full document when I'm done editing and am ready to share it.
A point that I haven't seen brought up in some of the other discussions around this issue is whether you as a user are looking for a more WYSIWYG editing experience or something more like a traditional LaTeX experience where you frequently re-render the content to check your work. RStudio has made incremental steps towards supporting a more WYSIWYG style in notebooks, especially with the Visual editor mode. In my mind inline output is vital to a WYSIWYG experience as otherwise all the plots and other output are off somewhere else and you don't see them integrated with the write-up until you render. As someone who frequently uses Visual mode, I hope to see a similar experience available eventually at least as an option in Positron. And on the other side I suspect some of the distaste for inline execution is from folks who are not looking for a WYSIWYG experience.
danieltomasz
commented
1 month ago Therefore, I believe the better model for .qmd files would be to separate them completely from the console. Run a separate R process in the console if you like, but have it not be affected by what happens in the notebook and vice versa. This is a logical and consistent approach, and most other parts of the development experience work this way. If I open a terminal whatever I do there doesn't impact the notebook or vice versa either. And if I start R (or python) in that terminal it also is completely separate.
I disagree with this (separate processes in notebook and console by default) , this make really hard working with data and iterating, one of main reasons editor like Rstudio or (Spyder) were appealing to the users ( to scientists, maybe less for programmers) was that they can write code in notebook, preview the variables in the data viewer and try to manipulate it within the same environment/userspace) ;
Where the output should be displayed (separate console vs inline) is a separate question
rmflight
commented
1 month ago Sooo, as I can see from @clauswilke comment above, this is a rather contentious topic. And I get it, we all get used to particular workflows.
In the beginning, there was sweave. And there, the text editing was decoupled from the generation of the final document.
Then, Yihui brought us knitr. And again, text editing was still mostly decoupled from the generation of the final document.
At some point, ipython came along, with their notebooks that were really neat, but also somehow bundled the javascript for display with the underlying computations, and everything was kept together, with no way to access the kernel outside of the notebook environment.
Then RStudio brought us inline editing, which was a neat way to be still editing a raw text document, but see the results next to the code. Unfortunately, it came with assumptions about where execution was starting from, and how to access things in the file path. I (and I'm sure @clauswilke) started coding in R so long ago, having the console coupled to the text editing was a revelation. I somehow never really grew out of that, and always preferred my output in the console, because I felt like inline never gave me the flexibility I wanted to query the data I was generating, and try different things out without writing in the text document.
Which is weird, because I often start working in a qmd document than a straight R script when I need to prototype something (maybe because it's easier to send an html doc or word doc when I have graphs to share? I don't know).
And now of course we have visual editing, which feels like a very close analogue to a notebook.
As much as it pains me to think about (and probably is a pain to support), I think that qmd files should continue to have the options of either output to console, or output inline (similar to notebook). Users should be able to use either one. Either that, or bring back the "notebook" format that is powered by qmd underneath, but everything is shunted to the kernel driving it.
Some people really like notebooks / inline output, with all the output shown in the notebook editing area. Some of us are not fans, and want all the outputs elsewhere while we are writing. I know the options to support both of us make your all jobs more complicated, and that sucks.
petrbouchal
commented
1 week ago Just to add that on a purely ergonomic note, it is hugely valuable to have chunk output sitting around in a quarto document as I work. I can refer back to tables, figures, plots etc. as I work in other parts of the document.
Having this available in qmd files is useful because (unlike in ipynb files)
This makes the qmd format with inline output more practical to me than Jupyter Notebooks (and why I am so far sticking to RStudio over Positron) - so the logic of "if you want inline experience, use ipynb" does not really work for me.
Whether or not that output also turns up in the console is not that big of a deal to me. Having a console ready with the same environment is helpful but not essential - rather something I appreciate and got used to because of how RStudio works with Rmd/qmd docs, but I see how that can be confusing coming from Jupyter.
RStudio users can choose whether to have their notebook output go to the console or get printed out in their notebook space. We'll want to support this option in Positron as well, and it will pretty much be the first time Python users can set up their work this way. (Spoiler alert: they want this option a lot.)