How can I set up GNU screen to allow the mouse's scrollwheel to scroll around in the scrollback buffer? I tried to Google about this, but most hits were on how to allow applications inside screen to use the scrollwheel.
I believe you can just add a line like this to your ~/.screenrc:
termcapinfo xterm* ti#:te#
Where "xterm*" is a glob match of your current TERM. To confirm it works, ^A^D to detach from your screen, then screen -d -r to reattach, then ls a few times, and try to scroll back. It works for me.
What is this magic? Well, let's consult the manual pages.
screen(1) says:
termcapinfo term terminal-tweaks [window-tweaks]
[..]
The first argument specifies which terminal(s) should be affected by this
definition. You can specify multiple terminal names by separating them with
`|'s. Use `*' to match all terminals and `vt*' to match all terminals that
begin with "vt".
[..]
Some examples:
termcap xterm* LP:hs#
Informs screen that all terminals that begin with `xterm' have firm
auto-margins that allow the last position on the screen to be updated (LP),
but they don't really have a status line (no 'hs' - append `#' to turn
entries off). Note that we assume `LP' for all terminal names that start
with "vt", but only if you don't specify a termcap command for that terminal.
From termcap(5):
String capabilities
[..]
te End program that uses cursor motion
ti Begin program that uses cursor motion
In screen, you must first enter "scrollback mode" (or "copy mode") to be able to scroll around in the scrollback buffer: key combo Ctrl-a Esc, or Ctrl-a Ctrl-[. Then you can scroll around the history using Up and Down keys (or Ctrl-b, Ctrl-f to move a page).
In that mode, your mousewheel should also work, if it works in other apps.
You end "scrollback mode" with Esc.
As for scrolling the scrollback buffer without first entering scrollback mode, that is probably not possible without modifying screen. I have never heard of a way to access the scrollback buffer, apart from scrollback mode.
The excellent article that Jon Z is referring to is no longer available, but I was able to fish the text-only version of it from the Google cache. I'm saving it here in case Google drops that as well in the future. Original post was by Mikael Ståldal so credit where credit is due.
--
How to use mousewheel in GNU Screen
GNU Screen has support for scrollback, but by default you have to use awkward keys to use it. I would like to be able to use Shift-PageUp, Shift-PageDown and the mousewheel to scroll, just like you can do in xterm.
It was not easy to configure Screen for this, and it involves cooperation with the terminal emulator. But I finally managed to achieve a solution which works pretty well. Add this to your ~/.Xresources file (you need to log out for this to take effect):
XTerm*saveLines: 0
XTerm*vt100.translations: #override \n\
Ctrl <Btn4Down>: string(0x1b) string("[25S") \n\
Lock Ctrl <Btn4Down>: string(0x1b) string("[25S") \n\
Lock #Num_Lock Ctrl <Btn4Down>: string(0x1b) string("[25S") \n\
#Num_Lock Ctrl <Btn4Down>: string(0x1b) string("[25S") \n\
<Btn4Down>: string(0x1b) string("[5S") \n\
Ctrl <Btn5Down>: string(0x1b) string("[25T") \n\
Lock Ctrl <Btn5Down>: string(0x1b) string("[25T") \n\
Lock #Num_Lock Ctrl <Btn5Down>: string(0x1b) string("[25T") \n\
#Num_Lock Ctrl <Btn5Down>: string(0x1b) string("[25T") \n\
<Btn5Down>: string(0x1b) string("[5T") \n\
Shift <KeyPress> Prior: string(0x1b) string("[25S") \n\
Shift <KeyPress> Next: string(0x1b) string("[25T") \n
Then add this to your ~/.screenrc file:
defscrollback 1000
# Scroll up
bindkey -d "^[[5S" eval copy "stuff 5\025"
bindkey -m "^[[5S" stuff 5\025
# Scroll down
bindkey -d "^[[5T" eval copy "stuff 5\004"
bindkey -m "^[[5T" stuff 5\004
# Scroll up more
bindkey -d "^[[25S" eval copy "stuff \025"
bindkey -m "^[[25S" stuff \025
# Scroll down more
bindkey -d "^[[25T" eval copy "stuff \004"
bindkey -m "^[[25T" stuff \004
This works in xterm. I’m not sure if it works in other terminal emulators.
Note that this disables the normal scrolling support in xterm, you will only be able to scroll when using Screen. You might want to start xterm like this to always use Screen:
xterm -e screen
For OS X (Snow Leopard), the following worked for me:
http://slaptijack.com/system-administration/mac-os-x-terminal-and-gnu-screen-scrollback/
Briefly, it involves adding the following to ~/.screenrc on the remote host (the one you're running screen on):
defscrollback 5000
termcapinfo xterm* ti#:te#
And to use the scrollwheel in a VIM inside GNU Screen:
[.vimrc]
set mouse=a " hold shift to copy xterm
set ttymouse=xterm2 " necessary for gnu screen & mouse
Press Ctrl+a followed by [
The title bar of your terminal should now say Copy mode.
Now the arrow keys and the mouse wheel should work as expected.
To return to normal press Esc or press Enter a couple of times.
The following worked for me in both Cygwin and Putty:
Edit .screenrc and add
terminfo xterm* ti=:te=
Setting TERM variable to vt100 instead of xterm before running screen also works.
I've been using this for a long time, works like a charm.
Add this to your .bashrc:
# make scrollbar / wheel scrolling work when running screen in gnome-terminal (or other)
if [ "$TERM" = "xterm" ]; then
export TERM=vt100
fi
--
For reference, my .screenrc has this (not needed for this AFAIK):
# Extend the vt100 desciption by some sequences.
termcap vt100* ms:AL=\E[%dL:DL=\E[%dM:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC
terminfo vt100* ms:AL=\E[%p1%dL:DL=\E[%p1%dM:UP=\E[%p1%dA:DO=\E[%p1%dB:LE=\E[%p1%dD:RI=\E[%p1%dC
The solution when using "Ubuntu 16.04.2 LTS" is as follows:
a). Update $HOME/.screenrc as previous answers have specified:
termcapinfo xterm* ti#:te#
b). Use "Settings"."Preferred Applications" to alter the default terminal to xterm, by selecting the "X Terminal" one in the drop-down list.
Some superfluous notes
None of the other terminals, including installing "lxterminal",
worked for me, even when I altered the termcapinfo line to "*"
instead of "xterm*".
By clicking the menu button in the top-left corner of the screen, you
can get the Settings dialog using the 3rd icon from the bottom right
corner.
If the answers above don't work for you, make sure you don't have a caption or the alwayslastline option set in your .screenrc. If you have them, this will not work:
termcapinfo xterm* ti#:te#
If you need this information, you can try setting it in the title of your terminal (with termcapinfo)
Related
I found dev-USB-PWR-CTL-00A1.dtbo file. (I think this is source code for it).
Using this file I try to expose USB1_DRVVBUS pin as GPIO (GPIO3_13) with commands:
echo dev-USB-PWR-CTL > /sys/devices/platform/bone_capemgr/slots
echo 109 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio109/direction
I see new cape entry in slots and new gpio files tree.
But when I change value with command
echo 0 > /sys/class/gpio/gpio109/value
I see new value in this file but nothing happens with USB VBUS.
What am I missing?
(Before you ask do I really need this: let's leave the consequences on the side for a moment.)
Have you looked at this? question about exactly this on the Beagleboard Google Group
Please note that there are some differences to back then and current images, e.g. by default CapeManager is disabled and overlays are loaded once in U-Boot
If you are using a recent elinux.org Debian image (the necessary device tree overlay was merged in June 2015), it includes a device tree overlay (with the comment "Unless you know what you are doing, do not load this cape!!!"). This uses a hack to expose the usb1_drvvbus signal as a fictitious LED, which can then be controlled using the led interface in /sys.
Firstly, load the dev-USB-PWR-CTL-00A1.dtbo device tree overlay. For recent setups (where all dtbos are loaded by uboot and then passed to the kernel at boot time), this could be done by adding dtb_overlay=/lib/firmware/dev-USB-PWR-CTL-00A1.dtbo to /boot/uEnv.txt and rebooting (older kernels/uboots will need to use the older config mechanisms as described in /boot/uEnv.txt).
You can then do this:
echo 'usb1' > /sys/bus/usb/drivers/usb/unbind
echo 0 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
sleep 1
echo 255 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
echo 'usb1' > /sys/bus/usb/drivers/usb/bind
... to power-cycle the device attached to USB1.
I'm trying to print a PDF file via GhostScript command and want
to keep alive the default printer settings be done within the system environment (Windows 10 - set paper tray 3 as default).
When is done so without silent mode by using the upcoming printer dialog this works fine (even without setting up paper tray especially)
BUT - as I want the process to be done without dialog - I've also tried it with defining the printer name within the command line.
What works properly, is that the print out happens without dialog - BUT the default configured paper tray doesn't get used - when I print silently - paper tray 1 is used
Is there a possibility to keep the default paper tray settings alive while naming the printer within the command line?
Here is my codeline:
gswin64c.exe -dPrinted -dNoCancel -dBATCH -dNOPAUSE -dNOSAFER -q -dBitsPerPixel=4 -sDEVICE=mswinpr2 -sPAPERSIZE=a4 -sOutputFile=%printer%" + "\"" + printerName + "\"" +" " + "\""+pdfFileName+ "\"";
To the best of my knowledge, the mswinpr2 device always uses the default setup of the printer, unless you get a print dialog, in which case you can override the default.
Perhaps the default tray isn't the one you think it is.
Yes - I'm sure that the paper tray is set correct (tray3)
It is used when printing with other applications and also when I print via Ghostscript using a print dialog but not when I send a print job silently via command line.
Oliwan
I'm using the vim plugin in lighttable.
When I'm in insert-mode and press ESC while a code completion window is shown, it closes that window but doesn't exit insert mode.
I'd like lighttable to do both at the same time when pressing ESC because I got so used to it in plain vim.
I've tried to bind ESC to both of those actions:
[:app "esc" [
:auto-complete.remove
:vim.send-key "esc"
]
]
But this doesn't work. Is this even possible? Is there another workaround for that problem?
You should be able to do this by adding the following to your user.keymap file:
[:editor "esc" :auto-complete.remove (:vim.send-key "<Esc>")]
But this isn't currently possible.
I created an issue for this on GitHub for the LT Vim plugin repo. 'Fixing' this is relatively minor change to CodeMirror upstream of LT. I'll update this answer again if any other progress is made.
Is there a way to set the execution point while debugging Xcode/lldb? To be more specific, after hitting a breakpoint, moving the execution point manually to another line of code?
If you're looking at moving it up or down with in a method you can click and drag the green arrow to a specific point. so if you want to back up a line before the breakpoint. click on the green arrow that is produced and drag it up. If you hit run you'll hit your breakpoint again
In Xcode 6, you can use j lineNumber - see documentation below:
(lldb) help j
Sets the program counter to a new address. This command takes 'raw' input
(no need to quote stuff).
Syntax: _regexp-jump [<line>]
_regexp-jump [<+-lineoffset>]
_regexp-jump [<file>:<line>]
_regexp-jump [*<addr>]
'j' is an abbreviation for '_regexp-jump'
One of the great things about lldb is that it's easy to extend it with a little bit of python scripting. For instance, I threw together a new jump command without much trouble:
import lldb
def jump(debugger, command, result, dict):
"""Usage: jump LINE-NUMBER
Jump to a specific source line of the current frame.
Finds the first code address for a given source line, sets the pc to that value.
Jumping across any allocation/deallocation boundaries (may not be obvious with ARC!), or with optimized code, quickly leads to undefined/crashy behavior. """
if lldb.frame and len(command) >= 1:
line_num = int(command)
context = lldb.frame.GetSymbolContext (lldb.eSymbolContextEverything)
if context and context.GetCompileUnit():
compile_unit = context.GetCompileUnit()
line_index = compile_unit.FindLineEntryIndex (0, line_num, compile_unit.GetFileSpec(), False)
target_line = compile_unit.GetLineEntryAtIndex (line_index)
if target_line and target_line.GetStartAddress().IsValid():
addr = target_line.GetStartAddress().GetLoadAddress (lldb.target)
if addr != lldb.LLDB_INVALID_ADDRESS:
if lldb.frame.SetPC (addr):
print "PC has been set to 0x%x for %s:%d" % (addr, target_line.GetFileSpec().GetFilename(), target_line.GetLine())
def __lldb_init_module (debugger, dict):
debugger.HandleCommand('command script add -f %s.jump jump' % __name__)
I put this in a directory where I keep Python commands for lldb, ~/lldb/, and I load it in my ~/.lldbinit file with
command script import ~/lldb/jump.py
and now I have a command jump (j works) which will jump to a given line number. e.g.
(lldb) j 5
PC has been set to 0x100000f0f for a.c:5
(lldb)
This new jump command will be available both in command-line lldb and in Xcode if you load it in your ~/.lldbinit file -- you'll need to use the debugger console pane in Xcode to move the pc instead of moving the indicator in the editor window.
You can move the program counter (pc) in lldb using the lldb command register write pc. But it's instruction based.
There's an excellent lldb/gdb comparison here that is useful as an lldb overview.
I have the following mapping in my .vimrc.
:nmap <F5> :<C-U>make %:r && ./%:r<CR>
I press F5 in VIM, and it compiles, exits VIM, and runs my code. When the program terminates, it asks me to "press ENTER or enter a command to continue." It then takes me to a blank screen with the text (1 of 5): and the same "press ENTER or enter a command to continue" prompt. I press enter and it finally returns me back to VIM. This behavior is consistent across the board. Is there a way to remove any or both of those occurrences? Perhaps have the mapping press ENTER twice after the program terminates? If so, how?
EDIT: So I realized appending two more <CR>'s doesn't quite solve the problem. As soon as the program terminates, it IMMEDIATELY goes back to VIM and I don't have time to review the output. Can I make the mapping wait for ME to press the first enter, and automatically press the 2nd ENTER afterwards?
Would this work:
nmap <F5> :<C-U>silent make %:r<CR>:redraw!<CR>:!./%:r<CR>
A longer solution but this one also allows you to see errors (reference):
:function! MakeAndRun()
: silent make %:r
: redraw!
: if len(getqflist()) == 1
: !./%:r
: else
: for i in getqflist()
: if i['valid']
: cwin
: winc p
: return
: endif
: endfor
: endif
:endfunction
:nmap <F5> :call MakeAndRun()<cr>
Yes and yes (you answered your own question):
:nmap <F5> :<C-U>make %:r && ./%:r<CR><CR>
For me this works fine:
" Compile
noremap <F4> :<C-U>silent make<CR>:redraw!<CR>
" Automatically open, but do not go to (if there are errors) the quickfix /
" location list window, or close it when is has become empty.
autocmd QuickFixCmdPost [^l]* nested cwindow
autocmd QuickFixCmdPost l* nested lwindow
It compiles, and immediately jumps to vim, showing the quickfix window. No intermediate enters.