Are you the same guy who posted this, or is this just a coincidence? :)
http://askubuntu.com/questions/806076/how-to-make-text-not-wrap-in-gnome-terminal

I don't think it can be done. Quoting myself from that page: "The concept is inherently broken. Apps running inside terminals do have the notion of terminal width and often paint stuff accordingly (e.g. text editors), and might legally "overflow" to the next line (print stuff spanning across the right margin and expect to appear in the next row). So I cannot imagine reasonable behavior of these apps inside such a terminal."

Also, on a personal note, I think it's usually much harder to consume content if you have to scroll along 2 axes rather than just 1.

You mentioned command editing (whether it should wrap or horizontally scroll), it's another great example why this feature is troublesome.

You say there could be a separate option. Well, the behavior would be defined by your shell, not by the emulator.

If it prints an explicit newline where it wraps the text, there's nothing else the terminal could do than to follow it and wrap to the next line. (Overriding not to print a newline would absolutely lead to an uncontrollable disaster.)

If it doesn't print an explicit newline and just lets the terminal handle overflowing to the next line, the new behavior by definition would require that it scrolls horizontally rather than wrapping. However, upon further editing the command, you might e.g. press a shortcut that modifies one single letter that is 80 characters behind the cursor in the command line. (Assuming the default window width) your shell might just emit a shortcut: the "up" sequence and then print the new letter there, expecting the expected letter to be overwritten. With a long, horizontally scrollable line going upwards would break big time.

(I don't know which one bash/zsh/etc. do, we could easily check, but it really doesn't matter.)

In terminal emulators, the cursor is always onscreen. (There's a bit of magic near the right margin, xterm has a special bit whether overflow's about to happen, whereas vte thinks in terms of the cursor being just right of the rightmost cell (effectively width+1 possible vertical positions), but eventually it's the same.) E.g. trying to move it to the right beyond the terminal's right edge is a no-op. I don't see a good way of defining offscreen cursor movements, which would definitely be required for your feature.

I believe that in order to have what you wish for, terminal emulators as well as libraries and applications running inside would have to be built up differently from scratch.

We should/could(?) study some of the emulators that claim to have done it, but I don't expect to see anything remotely usable there. I mean there's sure a reason why none of them became popular.

Agreed, this is not going to happen.

I recently came across this feature request in the bugtracker of two other terminal emulators:

- xterm.js: https://github.com/xtermjs/xterm.js/issues/1617
- konsole: https://bugs.kde.org/show_bug.cgi?id=62380

Thinking about it a bit more: I think it _could_ be reasonably well implemented as a strictly view-only property. That is, terminal emulation would remain unchanged, applications couldn't see any difference. Wherever there's a "soft wrap" (no explicit newline character at the end of a line), the "view" would flatten it out to one line.

As such, the view would show more content than what's currently writable, it would show part of the scrollback too. Jumping to coordinate (1,1) would visually move the cursor to column 1 of some intermediate row. Mouse click positions etc. would all have to be mangled accordingly.

The behavior could be made one mode only at a time for the entire session (e.g. a menu entry to toggle), or per-paragraph (an escape sequence would control it).

In order to know the correct height and position of the old vertical scrollbar and to scroll to any location in O(1) time, in addition to row_stream we'd need another paragraph_stream.

In order to know the correct width of the new horizontal scrollbar, we'd need to always know the width of the widest line. Due to content potentially scrolling out from the top of the scrollback at any time, I think this requires a histogram (mapping from each possible width to the number of lines having that width), probably with some cheating above extremely large widths. 

Certain features, such as forthcoming bash-5.0/readline-8.0's previous/next-screen-line, would of course not make too much sense to the user in this new mode.

It's also unclear to me how and when exactly the horizontall scrollbar should scroll on its own to make the cursor visible.

Probably there are plenty of other small issues (such as how to adjust the vertical scrollbar when a soft-wrapped line becomes hard-wrapper, or the other way around), I haven't properly thought it through. We'd need a demo implementation to evaluate its overall usability.

All in all, it's quite a lot of work, and I still don't think it's worth it, I retain my "wontfix" opinion.

The view-only approach, outlined in the previous comment, has another truly problematic aspect: how would it co-exist with (forthcoming) BiDi support?

If a LTR line can overflow to the right then an RTL line can overflow to the left. How would two such lines be positioned relative to each other?

I can think of two possible approaches, and neither of them sounds good.


1. Lay our LTR lines from the left edge of the viewport (= terminal window) according to the horizontal scrollbar's default position, and RTL lines from the right edge of the viewport at the scrollbar's default position. That is, the first letter of an LTR line and the first letter of an RTL line are as far from each other horizontally as the terminal window's width.

This is mostly what Firefox and Chrome do with <pre> text, except that they crop the overflow in one of the directions (e.g. to the left if the page's / container's overall direction is LTR, and vice versa) (presumably properly implementing the HTML specs). You can reveal that text by widening the window.

This wouldn't be acceptable for us, we'd need to be able to scroll in both directions, meaning that the scrollbar's "default" position could be somewhere in the middle. There'd need to be convenient means of restoring that position, such as snapping the scrollbar there, or a shortcut key.


2. Lay out LTR lines from the left edge of the logical canvas, and RTL lines from the right edge of the canvas. That is, their initial letters would be as far away from each other horizontally as the widest line present on the screen + in the available scrollback buffer.

The relative offset of LTR and RTL text would jump back and forth depending on other irrelevant lines appearing, or scrolling out at the top. Not good.

It's unclear how the scrollbar position would be maintained as new data appears, e.g. would it stick to the left, or stick to the right, or what exactly. Also, how could we make sure that new piece of text appearing with opposite directionality is discoverable.


It may easily be that users wishing for this feature probably don't care about BiDi, still, we developers would have to think about all combinations of the features we have, and come up with a resonable solution. Of course yet another approach to consider is to make BiDi and horizontal scrolling mutually exclusive, but that isn't nice either.


Conclusion: Still a strong "wontfix" from me. Use command line utilities such as "less" to achieve the requested functionality.