-1

The question is asked here:

If I intend to actually implement this change, which library / program do I need to investigate? Which part of the 'terminal stack' is responsible for the behavior of appending new lines to the terminal buffer?

I used to think it would be within a Terminals source code, and then the shell and now it looks like it's possibly VTE?

Any pointers?

closed as primarily opinion-based by andcoz, schily, msp9011, Toby Speight, Isaac Aug 29 '18 at 1:54

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I am fairly sure that people have asked the same on Unix & Linux, too. I vaguely recall such a question. – JdeBP Aug 27 '18 at 19:28
  • 1
    It isn't unix.stackexchange.com/questions/35627 that I vaguely recall. (-: – JdeBP Aug 27 '18 at 19:53
  • @JdeBP Well, this question is somewhat different as OP clearly states he's willing to implement this feature, just asks for some pointers; rather than looking for a solution :) – egmont Aug 27 '18 at 20:13
  • The same as those questions pointed to. – JdeBP Aug 27 '18 at 20:16
2

Terminal emulators are not implemented identically. What you need to change depends very specifically from what terminal emulator you intend to modify.

In general terms, this can be implemented in two places: in the emulation part that interprets and enacts print and control sequences as modifications to some form of in-memory representation of the terminal display state, or in the realization part that renders that display state onto some kind of output device.

The former would be a highly complex task. Applications softwares, both those that provide full-screen textual user interfaces and those that merely do things like provide an editable single line, make assumptions about the direction of progress. They assume all sorts of things, like the directions of , , , , RI, IND, CUD, CUU, and so forth. (In theory, in an ECMA-48:1991 conformant device, the directions of line progression and implicit movement are switchable. I know of no Unix or Linux terminal emulator that actually implements this. The world has mostly operated on the premise that it isn't.) In the end, I suspect that one would get all of the way through the various consequences and knock-on effects to find that one had implemented the latter method the hard way.

Because the latter is a comparatively fairly easy task. For kicks, I just implemented it in my terminal emulator. It was a command-line switch for a boolean flag in two of the realizers, and some conditional expressions to perform coördinate transforms in several places. Admittedly, the visible realized window is always an integer multiple of the character cell size in those realizers, which avoided some extra complexities.

That said: having used it and fought against the habit of years of reading from top to bottom, and then experienced just the initial problems with applications that expect little things (such as a caret being a Poor Man's up arrow and tilde being a Poor Man's underline), I then put a cautionary note in the manual page. I am considering leaving the mechanism in for the next release just so that people can from now on actually try a wrong way up terminal and come to the conclusion that they do not want this, despite what they claimed, after all. ☺

Further reading

0

What is the exact behavior you'd like to achieve?

First I assume that you wish to have all the lines in reverse order all the time.

Note that in my opinion in most of the cases this would result in a terribly unusual and counterintuitive (if not straight broken) behavior, possibly something you'd give up using pretty soon.

cat'ing a text file would show its lines from the bottom to the top, not the direction in which you normally read text. In your favorite text editor and viewer the lines would also be reversed. In applications, their top bar would be at the bottom and their bottom bar would be at the top. In alsamixer the volume controls would hang down from the top. Box drawing characters (e.g. in alsamixer, midnight commander etc.) would fall apart at the corners. The Up and Down keys would walk the cursor in opposite direction in many apps.

This can be achieved by modifying your favorite terminal emulator's source (or VTE in case you use a VTE-based emulator like GNOME Terminal).

Basically the terminal emulator tracks the logical contents (which character cell contains what letter with what graphical attributes), and converts them to user-visible pixels (nicely rendered glyphs). This would need to go upside down. I'd look for the places where conversion between the character-based and the pixel-based coordinates happen, which is all the places where a multiplication or division by the cell's height occurs. These formulas would need to be adjusted. For example, if you see a y_pixel = top_padding + row * cell_height, it would perhpas become an y_pixel = top_padding + (number_of_rows - 1 - row) * cell_height, or something like this.

In VTE, super smooth scrolling (per-pixel scrolling with the touchpad), plus the way the extra bottom padding (in case of non grid aligned, e.g. maximized window) is filled with contents upon smooth scrolling will cause you extra headache.

Once you get the basic rendering done, you'd also have to make sure that mouse events that are sent to the apps are properly flipped, and so are the mouse events that track the selection. The scrollbar should also be flipped.

As a second step, you might want to either add a menu entry, or introduce a new custom escape sequence (probably a new DEC private number) that lets you toggle between the standard and this upside down behavior. Note that changing the mode would immediately flip everything (all the onscreen contents and history) upside down or back. It's handy to be able to restore the original behavior, especially if it can be done automatically in a wrapper script in front of let's say your preferred editor. In case of VTE and a VTE-based emulator, a graphical menu entry would require a new API between the two components, so it's one more reason to go for an escape sequence instead.

If you want to have something more fine grained than this, e.g. each command's output to appear in "normal" order while the sequence of commands is "upside down", then it becomes a magnitudes more complex story which cannot be done in the emulator on its own, it would need to get help (via newly designed escape sequences) to know which logical parts to flip. My personal recommendation is to forget it, I don't find it reasonably doable.

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