When I reattach to a screen session, it only fills up my current terminal's window size worth of the scrollback buffer. If I enter Copy mode (ctrl+a [) then I'm able to scroll up the buffer (using the up arrow key) and "uncover" the history of this session (one line at a time). I have my scrollback buffer set to 30000 and some of the output that I want to see is very long so this can take a long time.
I tried using the hardcopy command, but that only saves whatever has been uncovered by me. I tried using g within copy mode, but that only jumped to the top of what had been uncovered. The full scrollback buffer is clearly still there because I can uncover it using the arrow key, but I can't figure out how to access the entire thing without holding the arrow key for a very long time.
Ideally, I'd be able to issue a command to store the whole screen session's past output to a file (or at least up to my screenbuffer limit). Which is what hardcopy is supposed to do. But since it is only saving what has been uncovered by my up arrow, this is useless for my situation.
Related
Using neovim version v0.8.2 when pasting multi-line text from the system clipboard (not an internal register), the newline characters get stripped away, undesirably resulting in a single line.
Querying the termpastefilter, the value is on the defaults - "BS,HT,ESC,DEL".
When pasting, neovim asks for a confirmation before pasting due to the fact there are control characters in the pasted string and in the confirmation message, part of the text is revealed with the control characters escaped, where one can clearly see the \n characters, however after pasting the string they get stripped.
The terminal emulator is urxvt version v9.31.
How can one undo this behavior?
I've the same "problem" but sad news:
More information would be needed - what are "incorrect line endings" and have
you disabled the confirm-paste plugin? If not, which option did you chose?
Also for some reason when i open the terminal, half the screen is
flushed. This seems to have been reported here already:
Yes, that is a race condition between your wm and urxvt. It can happen
with all terminals and also older versions of urxvt, but happens much
more commonly in the current version. We have plans to address this,
but are not sure what the right course is, yet, as it is not a bug.
A workaround of sorts is to output some newliens so the prompt is at
the bottom (which is where it will end up anyway, under normal use),
or specify a geometry larger than the screen and let your wm shrink
it, which has pretty much the same effect.
Source is the official mailing list which can be found here: http://lists.schmorp.de/pipermail/rxvt-unicode/2023q1/002650.html
As a workaround I will temporary transfer terminator.
I am running Doom Emacs with the minimap enabled in init.el.
I would like emacs-minimap to show the whole buffer and not just a part of it, so that i can see where i am in relation to the whole file.
However, i didn't find an option to define the amount of lines that the minimap shows.
How can i set emacs minimap to show the whole file?
When I run the script below on a DM EELS spectrum that already contains background and signal ROIs, it is ok if I don't show any images.
ImageDocument imdoc = GetFrontImageDocument()
image i0 = ImageDocumentGetImage(imdoc,0)
image subt = eelssubtractpowerlawbackground(i0,800,900)
//image irrelevant = realimage("irrelevant",4,100,100)
//showimage(irrelevant)
But if I show any image after running the background subtraction command (activate the last 2 lines for example) the pre-existing ROIs on the initial image are changed (sig disappears and bckgd is moved to the new position).
This is despite i0 being in theory a new image, not part of the initial one.
Creating copies within the script and working on them appears in any case not to solve the problem.
More surprising is that if I first make a duplicate of the initial image and run the script on that, then close the new windows and the (modified) spectrum on which the script was run, then try and duplicate the initial image, the duplicate has the modified ROIs rather than its own. A second duplicate seems to be ok. I have no idea what's going on. Grateful for any ideas.
(The problem was initially part of a much bigger script in which I need to show images, I've reduced it to the essentials here). I'm using v2.3.2.
I have tested your script on an EELS Spectrum with ROIs in GMS 2.3.3 and in GMS 3.2.2
GMS 2.3.3:
It does not seem to happen due to the ShowImage() but rather whenever the display of the image the last Background/Signal ROI was used on is refreshing its display. You get the same behavior when you run your script without the last two lines, but then click on another image (to select it) and then the spectrum again. And you get the same if you've used the background-subtraction ROI on a completely different image and then run the script. It messes up that last images' ROIs.
GMS 3.2.2: Doesn't show this. All is fine regardless what you do.
So, from these two tests I would conclude it is a bug in GMS 2.3 which has since been fixed.
The behaviour is indeed very odd, and I see nothing wrong with your code.
The bug seems to be that the command eelssubtractpowerlawbackground() messes with the settings of the last active signal-extracting ROIs, regardless on where they are placed on. It doesn't matter what the input image is. It seems to "reuse" these last ROIs.
Unfortunately, I don't know a good workaround for it.
I am working with Gnuradio-companion, working on a bigger project with a lot of blocks for the first time. The space on the workbench is getting scarce.
Do you know if it is possible to increase the size of the workbench?
Starting with GNU Radio 3.8, this is no longer necessary: the canvas auto-adjusts its size, and you can zoom around in it (usually, using ctrl+scroll wheel).
So, if this is a problem you're encountering, you're using the End-Of-Life GNU Radio 3.7 release series (or older). You should not be doing that. It's time to upgrade your GNU Radio.
To preserve the old answer:
Double-Click on the "Options" block and adjust the "Canvas Size" (it's width, height in pixels).
Another good approach to keep your flow graph manageable is to take groups of blocks and put them into "hier" blocks (select connected blocks, right click, more, Create hier); use "Pad Sinks" and "Pad Sources" to create in- and outputs for your new hier block, and use that hier block in place of the bunch of blocks, to keep your flow graph tidy!
Using EDSDK, I want to programmatically set the white balance (RGGB) values of the LiveView stream, and also for the white balance in both JPG (and RAW) images coming from the cam directly. The process of manual white balancing liveview and off-camera images is not completely clear to me and is not really clear in the EDSDK manual.
Through trial and error, I worked my way through calibrating LiveView by issuing the kEdsCameraCommand_DoClickWBEvf command with coordinates on a grey card. This seems to affect liveview all right:
Liveview switches to "ClickWB" (-1) white balance setting
Camera settings remain unchanged: it doesn't change the as-shot values of the camera.
Note that the "manual WB" icon on the camera disappears when setting to "ClickWB", something appears to be wrong.
Apparently, Canon's EOS utility does things slightly different. Using some tracing and polling of PTP events I see that:
Clicking Whitebalance sends a similar ClickWB command to camera.
When clicking "Apply to shot images" sends a command to camera
The camera White Balance stays on value 6 ("Manual","White Point" or "White Paper" depending on the context).
Liveview is also affected as it switches to 6.
Trace shows evidence of "CPtpCamera::TranslateMWb" command, as if there is a command to set the user balance.
The 'raw' White Balance coefficients can apparently be retrieved as EOS displays a warning about the coefficients not being ok.
For RAW images, I worked around white balancing by storing white balance coefficients from a RAW of grey card, and re-applying these coefficients when converting a new image (without grey card) to TIFF. This does not affect the on-camera JPGs, as-shot White Balance and cannot be recovered after reset.
I am stuck when disconnecting/reconnecting camera and (programmatically) apply the previously calibrated or stored WB values. Is this possible, and if so, how do I copy the original white balance values. Anyone here who has experience in manual WBing with EDSDK, care to share the type/order of sharing?
Note:
Canon provides no official technical support whatsoever for the EDSDK
older SDKs were reported to include commands (e.g. in 2.5 kEdsPropID_UserWhiteBalanceData). There must be a replacement for this?
--- update Dec 17 2014 ---
I am currently (indirectly) in "official" contact with Canon's EDSDK developers and currently there is no official way of setting in-camera custom white balance through the EDSDK.