write_scrollback_file doesn't include what's on the current screen

[Tenzer]

First off, great work on the achievement of this project!

The write_scrollback_file action was suggested in #189 (comment) to be an alternative to the currently missing scrollback search functionality.

When testing this out, I however noticed it's only contents of the scrollback which is outside of the current screen which get written to the file, which means - if you want to search through the scrollback - you will only be able to search through the lines which are not visible on the screen.

Is this intended? Would it not be better to output everything in the scrollback, including what is visible on the current screen?

I can't think of a use case where you'd only want the contents that aren't visible on the screen to be written in the file.

As a quick way of testing this, you can open a new tab, enter for i in $(seq 1 100); do echo $i; done to print out numbered lines, and then perform the write_scrollback_file action by pressing super + shift + j and notice it doesn't include all the lines outputted from the loop.

[mitchellh]

write_screen_file is what you want. write_scrollback_file only writes the scrollback (not the active screen)

[Tenzer]

Sorry! Right after creating this, I noticed the write_screen_file (link) action is available which does include the contents of the current screen.

[jcollie]

FWIW, write_screen_file and write_scrollback_file are absolutely awful names for these operations given what they do. I think that we should re-open this issue as a springboard to rename them and to change the default keybinding.

[mitchellh]

This is the terminology we use internally:

ghostty/src/terminal/point.zig

Lines 6 to 48 in 1fa2e69

	/// The possible reference locations for a point. When someone says "(42, 80)" in the context of a terminal, that could mean multiple
	/// things: it is in the current visible viewport? the current active
	/// area of the screen where the cursor is? the entire scrollback history?
	/// etc. This tag is used to differentiate those cases.
	pub const Tag = enum {
	/// Top-left is part of the active area where a running program can
	/// jump the cursor and make changes. The active area is the "editable"
	/// part of the screen.
	///
	/// The bottom-right of the active tag differs from all other tags
	/// because it includes the full height (rows) of the screen, including
	/// rows that may not be written yet. This is required because the active
	/// area is fully "addressable" by the running program (see below) whereas
	/// the other tags are used primarily for reading/modifying past-written
	/// data so they can't address unwritten rows.
	///
	/// Note for those less familiar with terminal functionality: there
	/// are escape sequences to move the cursor to any position on
	/// the screen, but it is limited to the size of the viewport and
	/// the bottommost part of the screen. Terminal programs can't --
	/// with sequences at the time of writing this comment -- modify
	/// anything in the scrollback, visible viewport (if it differs
	/// from the active area), etc.
	active,
	/// Top-left is the visible viewport. This means that if the user
	/// has scrolled in any direction, top-left changes. The bottom-right
	/// is the last written row from the top-left.
	viewport,
	/// Top-left is the furthest back in the scrollback history
	/// supported by the screen and the bottom-right is the bottom-right
	/// of the last written row. Note this last point is important: the
	/// bottom right is NOT necessarily the same as "active" because
	/// "active" always allows referencing the full rows tall of the
	/// screen whereas "screen" only contains written rows.
	screen,
	/// The top-left is the same as "screen" but the bottom-right is
	/// the line just before the top of "active". This contains only
	/// the scrollback history.
	history,
	};

[00-kat]

This is the terminology we use internally:

In my opinion, expecting users to guess that it's internal terminology is not a good idea.

(I also opened a discussion; would it be a good idea to use that discussion instead of this issue instead?)

[mitchellh]

I’m not trying to suggest it. I’m just posting it as information.