Whenever i evaluate a cell (Shift+Enter) jupyter moves the screen down so that the output is shown, assuming the cell is to big to fit on the screen entirely.
I find this feature rather annoying as it jumps so fast that i sometimes lose track where i just was when debugging.
Is there a way to modify this behavior or to disable automated screen adjustments entirely?
I use a standard jupyter installation without any modifications.
The version of the notebook server is: 5.2.0
The server is running on this version of Python:
Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34)
[GCC 6.4.0 20170704]
Current Kernel Information:
Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34)
The Shift+Enter command is run cell, select cell below, so if you are debugging a cell this is probably not what you want. If you use Ctrl + Enter, that is just run cell and should not move your cell cursor.
This may be what is causing your issue, as jumping to the next cell would also show you your output, misleading you on the cause of your issue. Using Ctrl + Enter in my 5.2 notebook does not move my screen position at all.
Related
I cannot select multiple (adjacent) cells (in order to e.g. delete them)
I have tried
Shift +up/down arrows
Shift + J/K
Both of the above in both Edit mode and Command mode
Running a javascript keyboard tester to make sure shift J/K not being intercepted
Windows on-screen keyboard for shift +up/down/J/K
Online searching for same symptoms
Question: any ideas why this is happening and how to resolve it or how to perform a more detailed investigation/diagnosis?
Environment: Windows-10 Home 64-bit 20H2; Jupyterlab 3.0.5; Python 3.8.6 | packaged by conda-forge | (default, Dec 26 2020, 04:30:06) [MSC v.1916 64 bit (AMD64)]; IPython 7.18.1
Browsers tested Chrome, Opera, Edge (Chrome has security extensions, all disabled/allowing localhost, but Edge is vanilla and behaved exactly the same)
Starting jupyterlab from Anaconda Navigator launcher
The problem is not with selection per se, as all selection actions failed (e.g. select all cells from menu), but rather with the display
The CSS value for var(--jp-notebook-multiselected-color) was #e3f2fd - invisibly faint on my monitor; it was declared in the index.css file as "md-blue-50" (Google's Material Design blue) but the colour displayed did not match an online sample of md-blue-50 (so I guess the value for md-blue-50 declared elsewhere was not found).
The issue was identified by switching to to dark mode, where selection highlighting was clearly present.
Solution (because I can't find the source of the md-blue-50 value) was simply to use Stylebot to override the background color - in fact, using Stylebot scoped to localhost is better for me because I don't have to fix the css in every installation of jupyterlab in every Python environment.
try to open the jupyter-lab from the cmd, type this command :
jupyter notebook
it will open the same lab you can open via anaconda. then all of shortcuts will work as usual
Every time I try to plot a function using GNU Octave, I have issues with the background. For instance, see the images at the end of this question. First, I opened a black window, then "plot" command was executed in the shell, giving "1_black.png" as the result. Second, a pdf file mostly white was opened and the same command was executed in the shell, as before. "1_white.png" shows what happened. In both of these cases it is the grid that doesn't look as it should, but sometimes even the curves are not properly shown in the plot. Does anyone have this same issue?
Relevant system info:
Fedora 33 workstation Ed. (It also happened with previous Fedora versions).
64-bit
GNOME version 3.38.2
Graphics NVD9
I'll appreciate any guidance on this!
Additional info:
The exact code to reproduce it is the following:
plot(1:10) , grid minor
Both images were saved by doing screenshots. Although these may not be strictly identical to the screen output, the problem is seen even before saving them.
Output of "graphics_toolkit()":
octave:3> graphics_toolkit()
ans = qt
Output of: ver Octave
-------------------------------------------------------------------
GNU Octave Version: 5.2.0 (hg id: eb46a9f47164)
GNU Octave License: GNU General Public License
Operating System: Linux 5.9.11-200.fc33.x86_64 #1 SMP Tue Nov 24 18:18:01 UTC 2020 x86_64}
----------------------------------------------------------------------
The scroll bar in Emacs 24 is missing. Scroll-Bar mode is enabled.
Emacs 24 was installed from the PPA and I am running Ubuntu 12.04.
I found a recommendation to set scroll-bar-mode but mine is already set and does not produce the desired effect.
I should be seeing GTK scroll bars but their absence seems to be a known bug. One workaround suggested in a comment last year on the bug report is to launch Emacs as follows
LIBOVERLAY_SCROLLBAR=0 emacs24 &
which works for me. I am wondering if there is a fix from within Emacs by now.
Below is a screenshot of the problem. Note the missing scroll bar in the upper buffer and the information on the scroll-bar-mode variable and Emacs version in the lower ones.
I have a long calculation running (for days). I can stop it and restart it as desired, as I can save the output and start from where I left off, but I would appreciate the option of doing so without quitting (or force quitting) R, i.e. by just pressing the red stop button in the GUI. However this seems to be impossible in some instances of running the exact same calculation (or sort of calculation): the stop button is greyed out. I would like to know if there's a criterion determining when and why this happens, and a solution to avoid the force quit option.
I'm running R version 3.0.1 (GUI Cocoa 1.61) on a Mac OS 10.7.5,
Thanks
UPDATE (April 2013): As per answer below, RStudio no longer jumps cursor on selection.
I'm running RStudio 0.97.168.
I like to use the script editor in RStudio like a console. Thus, I run a line of code and then edit it a little bit and re-run it. I often also explore objects by selecting some of the code and running the selection and then progressively altering the selection. At present RStudio always moves the cursor after running a line of code. The cursor can move to a variety of places. Typically the cursor moves to the next line of R code, but depending on the context, it could move to the end of the code block or the next line. It's really frustrating having to constantly move the cursor back to where I want it.
While I often appreciate the default cursor movement behaviour, I'd like to have the option to run the selection or the current line without the cursor moving.
I've raised this as a suggestion on RStudio support.
I'd like to be able to have a shortcut key like "Cmd+Alt+Enter" that runs the current line or selection and does not move the cursor in the script editor.
I realise that this is not currently supported, but I was wondering whether there might be some creative hack that could enable the cursor not to move after running a command or even a patch or perhaps some sort of external macro.
For anyone who ends up here in 2020:
Ctrl(or Cmd) + Enter: Will run current line and jump to the next one. If a code portion is selected, run the selected code without jumping further.
Alt + Enter: – Will run the current line of code without moving the cursor to the next line, useful if you want to run it multiple times.
(Source)
For this kind of flexibility, I suggest you use the editor Sublime Text 2, add in the package installer by Will Bond and then install the SublimeREPL package which will allow you to use an R interpreter within ST2 (or BASH prompt, Python / Ruby / whatever interpeter, concurrently if you wish).
You can then alternate between your code and the interpreter without lifting your fingers from the keyboard and your cursor will be at the same point every time when you want to switch back.
Sublime Text will also allow you to write a custom keybinding to automate this task.
I cannot recommend using Sublime Text 2 highly enough when coding for R. You can even pass files directly from ST2 into RStudio very easily if you like using the plot panes (very easy to do with the SidebarEnhancements package in ST2).
RStudio is awesome for many things -- especially now with Knitr, builds etc etc. But ST2 with an R REPL is many orders of magnitude more powerful for general code writing / editing than RStudio.
Sorry it's not RStudio specific, but it is a nice workaround!
I updated to version 0.98.83 of RStudio using the daily build section.
It appears that at some point in recent versions of RStudio, the cursor no longer jumps when code is run from a selection in the script window.
That's great news.