withoutboats / notty

A new kind of terminal
GNU Affero General Public License v3.0
2.3k stars 41 forks source link

implement or document text reflow #38

Open flying-sheep opened 8 years ago

flying-sheep commented 8 years ago

a common feature request is to reflow all text when the window is reszed.

that’s not trivial and involves a bit of guesswork, but very useful if it works

withoutboats commented 8 years ago

Reflow is a non-trivial but important feature! notty is intended to be designed so that it 'just handles' text for most use cases, like REPLs, shells, and text editors. It needs to reflow text correctly when windows are resized for this to be the case.

However, there are obviously times when it is not correct to reflow text. A roguelike, for example, certainly doesn't want to be reflowed as if it were text when the window changes shape.

How much awareness do we need to have about the meaning of a grid's content in order to reflow it properly? Is there a single reflow algorithm that applies to pretty much all text? Can this be as simple as a flag on CharGrid which says whether or not to perform this algorithm on the content of the grid when it is resized, or do we need to be aware of the grammar of the text in the grid in order to reflow it?

flying-sheep commented 8 years ago

i think a bit of both. you can distinguish text and fullscreen, but in some cases text doesn’t want to be reflowed either.

i think the gnome virtual console thing does it well

withoutboats commented 8 years ago

I'm not sure what gnome's terminal does, but on my current system (which is a Mac), I have two terminals: iTerm2 and the terminal that comes with Mac OS X. I've tested both to see what they do.

Note that this is a little complicated because when a terminal is resized, it sets its window dimensions for the controlling process (using the TIOCSWINSZ ioctl, which has a wonderful name), and then the controlling process may perform reflow. Its possible what seems like good reflow is actually being implemented in the controlling process. Our goal is for the controlling process never to have to perform reflow if what its displaying to the user is just text.

iTerm2 does its own reflow as you are resizing its screen, and sets the tty winsize with TIOCSWINSZ at regular intervals but infrequent enough to see it happen. Its own reflow is just to wrap around to the next line - you can see this by opening a vertically split vim window and then resizing it to be smaller along the horizontal access - the right buffer's content will wrap into the left buffer, and the middle bar will fall out of alignment. Then it will be snapped back to correctness when vim reflows itself.

The built in terminal seems to do no reflow of its own, but sends the TIOCSWINSZ ioctl frequently enough that reflow just happens, unlike in iTerm2.

Nothing that I can see does anything more complicated than wrapping your text to the next line, including vim. However, vim is smart enough to recognize a wraparound line from another line, and so you will skip those lines as you navigate up and down.

In any event, if vim's reflow is the best there is, it can definitely be implemented in the terminal layer in notty. It doesn't rely on any semantic understanding of what the text inside the window means.

ysangkok commented 8 years ago

Maybe @flying-sheep is talking about the dynamic reflow of scrollback buffer output (i.e. the process that made the output has already died, e.g. ls). This is a feature I noted exists in gnome-terminal but not e.g. lxterminal.

flying-sheep commented 8 years ago

jup, that

withoutboats commented 8 years ago

That feature is actually the same as vim's - it means recognizing the difference between reflow lines and regular lines, and then making sure the reflow lines are shifted back onto the end of the original line as the screen grows wider.