In modern web browsers and other software with text content, Space scrolls down more or less a screenful. ShiftSpace scrolls up in everything but less.

How can one use ShiftSpace to scroll up in less? Or alternatively, is there another pager (POSIX compatibility is my only requirement) that could do the job?

I was told some terminal emulators, and some terminal UI libraries (ncurses?), don't recognize ShiftSpace. Is that a valid issue?

  • What's wrong with your PgUp button? Not big enough? – goldilocks Aug 28 '13 at 19:16
  • @goldilocks: There's nothing wrong with wanting to use Shift-Space, especially if you're used to using it with other tools. It just happens to be impossible for less to distinguish between Space and Shift-Space. – Keith Thompson Aug 28 '13 at 19:55
  • You could configure your terminal (emulator) to send b or ^B (0x2) upon <shift-Space>. Note that b is just above the space bar in many keyboard configurations – Stéphane Chazelas Aug 28 '13 at 20:05
  • @KeithThompson : Just a friendly jibe I hope. I do empathize; I'd like / universally adopted as "search text" ala various common tools, but at the same time I am wary of imposing excessive meglomaniacal standards which make it even easier to do something that can be done with one (universally recognizable) keystroke anyway. Interesting to learn that in this case it is a technical limitation (see 200_success's answer) and not curmudgeonly design that explains. – goldilocks Aug 28 '13 at 20:12
  • 1
    @KeithThompson, see the translations resource for the VT100 widget. – Stéphane Chazelas Aug 28 '13 at 20:25

I think you've brought up a culture clash caused by a technical limitation. Since Shift+Space generates the same output as Space, the Unix terminal model treats them identically. To distinguish between the two, you need a programming environment that supports key up / key down events. That is possible in X11 and in terminal emulators that support remapping keys. An example of remapping Shift+Space to PageUp:

# For [u]rxvt, in ~/.Xdefaults:
URxvt.keysym.Shift-space: \033[5~
| improve this answer | |
  • 1
    Most terminal emulators support remapping keys, so it's possible to do it with most terminal emulators (xterm -xrm 'XTerm.VT100.translations: #override Shift <KeyPress> space: string(0x2)' in xterm for instance, or you send the same sequence as sent upon <PageUp>). Of course, that would make entering text while holding the shift key awkward. – Stéphane Chazelas Aug 28 '13 at 20:21

Terminal emulators send the same character upon Space and Shift+Space. If they didn't, then it would make it awkward to type text while holding the Shift key (see @egmont's answer that expands on that argument).

However, you could work around that by mapping Shift+Space to a sequence of characters that would end up inserting a space by default, and for which you could configure applications like less to scroll up upon such a keypress.

For instance, such a sequence could be ` DEL SPC (change the DEL to BS on systems where BS is the erase character).

For xterm, add the resource:

XTerm.VT100.translations: #override \
  Shift <KeyPress> space: string("`") string(0x7f) string(" ") 

And configure less with:

printf '%s\n' '#command' '`\177\40 back-screen' | lesskey -
| improve this answer | |

In terminal emulators, this feature would break typing uppercase text with embedded spaces by holding down Shift. E.g. if you wanted to type "It's A Title", you'd have to release Shift between "A" and "T". Keeping it pressed would move away your cursor and misposition the rest of what you type. I believe it would be way more annoying than what you gain with the scroll up feature.

Having the regular behavior when typing text, and scrolling up whenever Space scrolls down would require a redesign and heavy cooperation from apps (e.g. an app being able to toggle what Shift+Space sends), I'm pretty certain it's not going to happen.

The key difference is that a GUI app knows the "context" whether you're editing or viewing content, terminal emulators have no way of knowing this.

| improve this answer | |

less does not currently support this, but it definitely could be added.

If a program uses an xterm control sequence to set modifyOtherKeys to 2 by writing \e[>4;2m to the terminal, then xterm annotates keys with extra information about what modifier keys are active. Specifically for the Space key, with modifyOtherKeys active in xterm, Shift+Space turns into \e[27;2;32~. less would have to properly interpret this as Shift+Space and then trigger a scroll up.

While this would definitely work in xterm, it wouldn’t work in every terminal application. But those terminals that don’t recognize this escape sequence to turn on modifyOtherKeys will just ignore that escape sequence and keep sending programs a normal space character when you press Shift+Space.

There is a quite detailed page on the xterm website that explains how modifyOtherKeys codes are calculated: https://invisible-island.net/xterm/modified-keys.html

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.