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.
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
I tried to use Xcos for any basic simulation, but I obtained a blank/black window, instead the graph.
https://drive.google.com/file/d/1AN78dFcH6eYs5ajpmGj4qtqH40smoghc
I was thinking that maybe I use wrong elements, but after running example from help I saw the same - black window.
At the end I tried to use simple "plot([1,2],[1,2]);" - the same.
https://drive.google.com/file/d/1sKexRkM8ZFB2DsqWEpShiFGgKhViXxCk
I tried to restart computer and to install older version (5.5.2 instead of 6.1.0) -> without changes.
System: Windows (I'm sorry) 7, 32 bit (yes, I used 32-bit instalation).
I have so far no idea of what can procude such a behaviour;
Can you try the following sequence of instructions:
f=gcf(); //what is the color of the xindow?
f.background=5;// does the window background changes (red)?
gca().background=5;// does the drawing area background changes(red)?
I have Hygdrogen installed for my Atom editor. It was working fine till yesterday.
When I run using shift+enter, the output window displays the result as per normal:
However, when I close the output window, the window closes, leaving behind a huge space between code line 1 & code line 2:
After that, all my coding lines are disrupted. Any help is highly appreciated.
This behavior is due to a bug in Atom 1.19.6 and 1.20.0-beta6.
Upgrading to Atom 1.19.7 or 1.20.0 will fix your issue.
What steps will reproduce the problem?
1. wkhtmltopdf.exe --disable-smart-shrinking --print-media-type --page-size A4 --dpi 96 --margin-top 25 --margin-bottom 25 file:///.../debug.html mytest.pdf
What is the expected output?
I expect to see the non-shrinked content in result pdf-file
What do you see instead?
Shrinked content in the result pdf-file
What version of wkhtmltopdf are you using?
0.11.0 rc2
On what operating system?
Windows 7 64-bit
The problem is a little bit wider. I need to insert page breaks before some divs depending on their height. I wrote the appropriate script. But the thing is in "shrinked world" the coordinates analyzed by the script change and it the result is ugly. So I need to disable shrinking to make it work correctly.
On the other hand the documentation says '--disable-smart-shrinking' is "only available using patched QT". Does my version of 'wkhtmltopdf' implement this stuff? How can I find it out? Should I install QT or even rebuild the wkhtmltopdf?
I am using R 2.15.2 on windows XP.
I was used to use Rgui.exe but it was lacking the UNIX standards I like to use like CTRL+R <=>backward research and CTRL+U <=>erase line ...
If I missed something please tell me !
Then I tried Rterm.exe (which looks identical to R.exe to me) which has all those nice features. I found how to tune it right clicking on the top of the window to set height-width (it is like tuning the window you get from cmd.exe).
The problem is that now I cannot see on the window more than 75 characters, with a $ at the end: like this:
R) ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp$
Not sure if it is a R option of a windows one, but if I set options("width"=180) I can see data.frame on the full width of the window...
Not sure what is happening, can I modify this?
We still do not know the answer to that one, so I guess 50 pts goes to Oscar de León... good for him to bad for me...
Sadly, it appears to be built in.
There used to be a problem with R when trying to print long strings. Apparently it was fixed first in Rterm and other versions of R before being fixed in Rgui.
When Rgui was fixed, possibly it was by a different means, since this issue can be fixed in Rgui but not other windows versions of R. You can change the width of the console for output both in Rgui and (later) Rterm.
The prompt is another story. It is actually not the same as the output space, and thus is controlled with a different option; but, this only works for Rgui. To do it, set pgcolumns=180 in the Rconsole file under [R HOME]\etc\. This modifies the width of the internal pager of the Rgui console, and effectively enables you to type up to 180 characters per input prompt.
Possibly there is a way to integrate that behavior into Rterm, and maybe Duncan Murdoch can point you in the correct direction (or prove me completely wrong).
I'm not really sure what is being requested. If what is needed in RTerm.exe is to display the end of a long line (and position the cursor there), then use CTRL-E. You can go back to the beginning of a line with CTRL-A. One can go back and forth repeatedly as needed until the line is use ENTER.
The control character of readline seem to be active, for instance CTRL-P scrolls back one command and CTRL-N brings up the "next" command from history if you hit CTRL-P too many times. (These are the same behavior as the up/down arrow keys.) See link for other expected readline behaviors.
On my machine alt-f and alt-b (which should have been meta-f and meta-b) did not natively move forward or backward by words, but ESC-b and ESC-f did so on a line that exceeded the console width and had the $'s marking either the right or left extents as having further material to look consider.
If you want to wrap display lines, then you need to consider alternatives or additions to readline: link, but that is an untested suggestion and merely the results of a search for: "readline wrap display".
The command should be options(width = 180) (without the quotes around width), but when you run Rterm in the Windows shell, it doesn't respect changes to this value; it just prints output as wide as the console.
The best way of working with R is (almost always) to use an IDE. Try emacs + ESS or one of the many vim plugins (R.vim, vim-R, VIM:r-plugin) if you want something UNIXy.