Under Atom 1.23.3 x64, I can see some visual parasites (see picture below), like vertical blue lines. It happens whatever the file format (.py, .tex, .txt...).
I'm under linux Debian Buster/Sid.
Edit : this "thing" apparition seems to be randomness and purely visual, i.e., it's impossible to select and inspect it. It lies in between two caracters. It will move if I zoom in or out, but always be somewhere, as noise.
Related
I render the exact same R bookdown source, but get slightly different results depending on the operating system. This only regards the wrapping of the output width of code chunks when rendering with pandoc to HTML.
If the output is rather large like this
on Windows 10 it adds a horizontal scroll bar, when looking at it on smaller screens.
Running the same code on Ubuntu 20.04 gives me a different result
I checked the output message of bookdown::render_book("index.Rmd", "bookdown::gitbook") and it's the exact same for both operating systems. The pandoc version is the same, too (2.11.4).
Any idea is highly appreaciated.
To inspect options("width") was the right hint from #thothal. I explicitly set the tibble.width but not the width globally.
The lines will break without a horizontal scroll bar, if tibble.width > width. After updating my packages and RStudio I saw the same behavior on both operating systems. Not quiet sure though, what caused the difference in the first place. Maybe something changed for the tibble.width option internally. Or the default width depends on the OS or screen width of the device where it's run (unlikely).
To summarise: The tibble.width has to be equal or smaller than the global width to avoid that ugly line break. It's best to set both explicitly.
I am scrolling back in Tmux using the key combination + [, and as I scroll up, I see this on the right hand side.
What is this feature even called? It's extremely frustrating because it interrupts my data as I see it on the screen.
The line number should remain in the top line only and not appear on any lower lines, if that is what is happening (it is not entirely clear from your picture). If it does appear on lower lines I suggest you make sure your tmux version is up to date, make sure TERM outside tmux is correct for your terminal and perhaps try a different terminal entirely and see if it happens there too.
When Octave draws a plot, I would like it to set that to be the active window automatically, so that it becomes visible and I don't have to click back and forth between windows to see if the code and plot have finished. Is this possible? Since it would require reaching outside of Octave and controlling the OS, I'm not sure; it depends on whether or not that capability is part of Octave but I haven't found a reference for it yet.
I can always tell Octave to close the figure before opening a new one in the code, but that could prevent me from drawing multiple plots on the same axes, and it would require me to code that command in every time. It would be nice if there were a direct way just to bring the plot to be visible and take dominance over other windows.
EDIT: Somehow, although I noted that Octave would be required to control the OS to achieve this, I completely forgot to mention what that was... I'm running Windows 10 with the default window manager; I believe that would be the Desktop Window Manager.
When you plot something on a figure (whether you specify the figure you're plotting to within the plot command explicitly or simply let it plot into the currently active figure implicitly), this does not automatically raise the figure window to the forefront.
To do so, call the figure again using the figure function, along with the handle that you want to raise.
Alternatively, if you're sure that the figure you want to raise is the currently active one, you can simply use the shg command (which is effectively equivalent to figure(gcf))
E.g.
Fig1 = figure; % (or figure(1) if you want to be explicit)
Fig2 = figure; % (or figure(2) if you want to be explicit)
figure(Fig1); plot(1:10); % raise Fig1 to the forefront, and plot.
PS: Note that there was a bug affecting this behaviour until recently (coincidentally submitted by yours truly :p See https://savannah.gnu.org/bugs/?45943 ). This is fixed in the latest version of octave though (i.e. 5.1.0)
I discovered and downloaded Veusz today, and started to use it with several tutorials. After importing my data from a .csv file (that I correctly preview in the 'Import window'), I try to select the data I want to appear along the x and y axis; when I click on the arrow near 'X data' and 'Y data', nothing appears and I cannot choose anything to appear on my xy graph.
I tried several times to close and open the software, nothing changes. Here is a picture of my window:
I got the answer - which is in fact really simple. I just had to select the English style for the numerics (I'm actually on a French computer). It went well after that.
I have following printing code:
void Print(QPrinter *printer)
{
QPainter q(printer);
q.setRenderHint(QPainter::HighQualityAntialiasing, true);
q.setPen(QPen(QColor("red")));
q.drawRect(printer->pageRect());
q.drawLine(printer->pageRect().topRight(), printer->pageRect().bottomLeft());
q.setPen(QPen(QColor("blue")));
q.drawRect(printer->paperRect());
q.drawLine(printer->paperRect().topRight(), printer->paperRect().bottomLeft());
}
The result is different with QPrintPreviewDialog, rendered PDF, output to printers (HP LaserJet, PdfFactory, PdfCreator). Most of time the resulting rectangle is out of paper. What to do so the output is similar to all printers?
This really was asked some time ago, but I took the code from above and it cost me some hours to figure out, what's wrong with it.
First, looking at the Qt source code, I could not find any place which assumes a 5% margin.
Qt reads back the margins correctly from Windows XP and you can completely trust the page margins (Qt 4.5.3 with Windows XP).
The code above contains two issues: for printing a paperrect, the fullPage option must be set. Then the paperRect is printed at least on the preview correctly. Of course not on a real printer, as it is outside the pageRect.
Generally, printing the paperRect makes no sense, as, if printed correctly, it lies exactly on the paper border.
The second major issue stems from printing pageRect without correcting the origin.
If fullPage is disabled (default), then the pageRect origin lies at the paperRect origin thus includes the margins.
But printing starts at QPoint(leftMargin,topMargin), so the margin is added twice.
To fix the issue, pageRect.moveTo(0,0) needs to be called and then the pageRect prints nicely where it belongs.
That different printers show different results comes from different device margins. Only devices with 0-margin will work with the original code.
The Qt code I reviewed assumes 5% of paper as it's margin. Nobody trusts on correct paper margins.