Remember size and position on startup

[onedr0p]

Is your feature request related to a problem? Please describe. I'm always frustrated when I close wezterm and when I start it back up it doesn't remember the size and location of where it last was

Describe the solution you'd like A default behavior of remembering the position of the window would be nice, not sure how to handle the size since it can be coded in the settings... which takes precedence?

[hgkamath]

.. as well as maximization/tiling mode

• unmaximized - the unmaximized sz/pos needs to be saved regardless of being set to tiling states
• maximized
• left tiled
• right tiled

The difficulty here will be how to make it so that it is OS/window-manager/compositor independent.

[wez]

There's a lot of complexity here; as there can be multiple windows there would need to be a way to somehow identify each of them and remember their individual positions. I can see this feature being annoying if you had a lot of windows open and had them auto-restore.

Another aspect of this is that some people start one wezterm process per window and others run one wezterm process with multiple windows. I'm not sure this feature would be compatible with that workflow.

And finally: what would get restored in the windows? Each window can have multiple tabs running a variety of programs. Would those get restored? Restoration would be weird as there is no session resumption protocol for arbitrary programs, and some of those might be dangerous; say for example something spawned a new tab running rm -rf /some/dir. That would likely be dangerous or at best unwanted if that got run when you opened the terminal!

Such a headache!

Can we reduce the scope of this request? Would it be valid to offer startup positioning options in the config file? We already allow setting the default size. It doesn't seem unreasonable to add some positioning related options. For example, allow specifying x/y position in pixels and/or percentage of screen size, and likewise expand the size options to also allow pixels and percentage of screen size.

[rcaril]

Can we reduce the scope of this request? Would it be valid to offer startup positioning options in the config file? We already allow setting the default size. It doesn't seem unreasonable to add some positioning related options. For example, allow specifying x/y position in pixels and/or percentage of screen size, and likewise expand the size options to also allow pixels and percentage of screen size.

Can you point to the doc (or tell me how) to change the default size in the config? Sorry of this is a bit of a derail, but I searched far and wide and only found this request that was somewhat close.

[wez]

The docs are here: https://wezfurlong.org/wezterm/config/lua/config/initial_rows.html https://wezfurlong.org/wezterm/config/lua/config/initial_cols.html

Would you mind sharing what you searched for so that I can make this easier to find for others in the future?

[hgkamath]

In changelog: 20200406-151651-5b700e4 ( link ) Added initial_rows and initial_cols config options to set the starting size of new terminal windows

Keywords could be: terminal size, window size (though this means something different), terminal-rows, terminal-columns, rows, columns

[rcaril]

The docs are here: https://wezfurlong.org/wezterm/config/lua/config/initial_rows.html https://wezfurlong.org/wezterm/config/lua/config/initial_cols.html

Would you mind sharing what you searched for so that I can make this easier to find for others in the future?

Thx! I searched for "Window Size" and didn't get anything that seemed clear up front.

[wez]

I adjusted the text in those pages so that searches for "window size" now show them as matching results.

[gwww]

Here is another approach. What if the existing API is beefed up just a bit? The config file could "invoke" a layout. A layout might look something like this:

function layout_startup()
  local win, tab, pane1 = SpawnWindow(0, 0, 0, 0, true) -- new window at x,y=(0,0) r,c=(0,0) and true is "maximized"
  local pane2 = pane:SplitHorizontal( .6, .4 ) -- split, pane1 60% wide, pane2 40% wide
  local pane3 = pane2:SplitVertical(.5, .5) -- split, pane2 50% high and pane3 50% high
  local tab2 = win:SpawnTab()
  -- more splits, etc.
  local win, tab, pane1 = SpawnWindow(0, 0, r, 0, false) -- new window at x,y=(50,100) h,w=(24,80) and not "maximized"
  -- more split, tab, windows
end

The beauty is that the API structure is in place. There is clearly some thinking on the params to each of the calls. And, this approach is in line with the Lua as a programming language config approach.

There might need to be additional APIs, perhaps something to StopDrawing and StartDrawing while the layout_startup Lua function is running.

[dsoprea]

Thanks for sharing the links to the configs (https://github.com/wez/wezterm/issues/256#issuecomment-794194416). I ran into this issue, too, because I searched for "width" and "height" on the config page and came up with nothing. I thought I had searched for "initial" too, but I guess I must not have. I had Googled for "wezterm initial window size" and came up with several forum posts but nothing authoritative. However, it got me here.

If possible, it'd be helpful to add these terms as parentheticals following the names/titles of those configurables' names in the index/list.

[eugenesvk]

Thanks for the link to the docs indeed! @wez May I suggest disabling/deprioritizing Changelog in the search results as currently, for example, when searching for new window height out of the top 7 you have 6(!) from Changelog and only one with the correct results initial_rows

[wez]

I'm not sure if mdbook (the technology used to build the docs) allows for that kind of search result manipulation

[cbirchinger]

An "initial_xpos" and "initial_ypos" would really solve all my problems with the missing the old "-geometry" option that old terminals have.

Together with the already present "inital_rows" and "initial_cols" and in my case "colors.background=#xxxxxx", i could switch to WezTerm and continue to use my start scripts that initially place multiple Terminal windows on my desktop with the right dimensions and background colors.

[cbirchinger]

I think this very old issue got a bit derailed from the original request, and the simple positioning solution got buried.

Should i make a new simple request for "initial_xpos" and "initial_ypos", which is all i would need to place the windows with correct position and size?

[wez]

Should i make a new simple request for "initial_xpos" and "initial_ypos", which is all i would need to place the windows with correct position and size?

Yeah; specifying the size/position via command line parameters to wezterm start is a more more constrained problem because it doesn't need to remember anything

[wez]

In main and the currently available nightly builds, the following features tick off a number of boxes here, if you want the ability to control the startup layout:

• wezterm.on("gui-startup") gives you a hook where you can control which windows, tabs and panes are created in the internal multiplexer
• mux_window:gui_window() bridges from the internal multiplexer window to the corresponding gui window
• gui_window:set_position() and gui_window:set_inner_size() give control over gui window size and position
• gui_window:maximize() to set the maximized state
• wezterm.gui.screens() returns information about available screens for you to make decisions about placement/sizing.

Note that Wayland doesn't allow applications to control or even see their own positioning, but does allow control over sizing.

There isn't an ability to save these things and automatically restore them and I'm honestly hoping to avoid getting into that for the reasons I call out in https://github.com/wez/wezterm/issues/256#issuecomment-683319071 above.

[stevenxxiu]

The old thread Add config option to always open window in full screen/maximized · Issue #284 · wez/wezterm got closed. I could never figure out a native way to maximize the window without flickering. Managed to script it myself today. I thought that's quite relevant to this issue, as it's pretty much what I'm doing. Hope this helps out others.

local wezterm = require 'wezterm'
local mux = wezterm.mux

local cache_dir = os.getenv('HOME') .. '/.cache/wezterm/'
local window_size_cache_path = cache_dir .. 'window_size_cache.txt'

wezterm.on('gui-startup', function()
  os.execute('mkdir ' .. cache_dir)

  local window_size_cache_file = io.open(window_size_cache_path, 'r')
  if window_size_cache_file ~= nil then
    _, _, width, height = string.find(window_size_cache_file:read(), '(%d+),(%d+)')
    mux.spawn_window{ width = tonumber(width), height = tonumber(height) }
    window_size_cache_file:close()
  else
    local tab, pane, window = mux.spawn_window{}
    window:gui_window():maximize()
  end
end)

wezterm.on('window-resized', function(window, pane)
  local window_size_cache_file = io.open(window_size_cache_path, 'r')
  if window_size_cache_file == nil then
    local tab_size = pane:tab():get_size()
    cols = tab_size['cols']
    rows = tab_size['rows'] + 2 -- Without adding the 2 here, the window doesn't maximize
    contents = string.format('%d,%d', cols, rows)
    window_size_cache_file = assert(io.open(window_size_cache_path, 'w'))
    window_size_cache_file:write(contents)
    window_size_cache_file:close()
  end
end)

[masud-abdulkadir]

Can you point to the doc (or tell me how) to change the default size in the config? Sorry of this is a bit of a derail, but I searched far and wide and only found this request that was somewhat close.

https://wezfurlong.org/wezterm/config/lua/keyassignment/ResetFontAndWindowSize.html

I adjusted the text in those pages so that searches for "window size" now show them as matching results.

The link above shows up as the 2nd result if searching for "window size", but it's not that clear as it's under "ResResetFontAndWindowSize", perhaps a small addition or separation or direction to initial_rows and initial_cols would suffice this. I ended up here when looking for configuring my window size.

[Struki84]

The old thread Add config option to always open window in full screen/maximized · Issue #284 · wez/wezterm got closed. I could never figure out a native way to maximize the window without flickering. Managed to script it myself today. I thought that's quite relevant to this issue, as it's pretty much what I'm doing. Hope this helps out others.

local wezterm = require 'wezterm'
local mux = wezterm.mux

local cache_dir = os.getenv('HOME') .. '/.cache/wezterm/'
local window_size_cache_path = cache_dir .. 'window_size_cache.txt'

wezterm.on('gui-startup', function()
  os.execute('mkdir ' .. cache_dir)

  local window_size_cache_file = io.open(window_size_cache_path, 'r')
  if window_size_cache_file ~= nil then
    _, _, width, height = string.find(window_size_cache_file:read(), '(%d+),(%d+)')
    mux.spawn_window{ width = tonumber(width), height = tonumber(height) }
    window_size_cache_file:close()
  else
    local tab, pane, window = mux.spawn_window{}
    window:gui_window():maximize()
  end
end)

wezterm.on('window-resized', function(window, pane)
  local window_size_cache_file = io.open(window_size_cache_path, 'r')
  if window_size_cache_file == nil then
    local tab_size = pane:tab():get_size()
    cols = tab_size['cols']
    rows = tab_size['rows'] + 2 -- Without adding the 2 here, the window doesn't maximize
    contents = string.format('%d,%d', cols, rows)
    window_size_cache_file = assert(io.open(window_size_cache_path, 'w'))
    window_size_cache_file:write(contents)
    window_size_cache_file:close()
  end
end)

Works like a charm!

[s0ph0s-2]

There's a lot of complexity here; as there can be multiple windows there would need to be a way to somehow identify each of them and remember their individual positions. I can see this feature being annoying if you had a lot of windows open and had them auto-restore.

Another aspect of this is that some people start one wezterm process per window and others run one wezterm process with multiple windows. I'm not sure this feature would be compatible with that workflow.

And finally: what would get restored in the windows? Each window can have multiple tabs running a variety of programs. Would those get restored? Restoration would be weird as there is no session resumption protocol for arbitrary programs, and some of those might be dangerous; say for example something spawned a new tab running rm -rf /some/dir. That would likely be dangerous or at best unwanted if that got run when you opened the terminal!

Such a headache!

Can we reduce the scope of this request? Would it be valid to offer startup positioning options in the config file? We already allow setting the default size. It doesn't seem unreasonable to add some positioning related options. For example, allow specifying x/y position in pixels and/or percentage of screen size, and likewise expand the size options to also allow pixels and percentage of screen size.

To add some additional context to this request, I read it as a request to enable behavior like what iTerm2 does, and what macOS applications in general are expected to do: remember what you had open and where it was, so that if you restart the computer with the "Reopen windows when logging back in" checkbox checked, everything reappears more or less how you left it.

iTerm2 in particular restores the following:

• Number of open windows
• Window sizes
• Window positions
• The tabs in each window
• The window splits (analogous to WezTerm's multiplexer)
• The current working directory for each tab
• The terminal output log for each tab

It does not restart any processes that were running (other than the shell itself), because as you described above, that would certainly lead to some unpleasant surprises!

This is definitely a lot of work, and I don't know how to resolve the conflict with WezTerm operating with multiple top-level processes that each manage their own set of windows. However, if it's a feature that you'd be willing to support in WezTerm, I'd really love to see it! Session restoration is the only feature I'm missing from iTerm2, and I think I'm going to switch anyway, because I like WezTerm better :)

(Also, I would not miss the terminal output log restoration—just having the windows/tabs reopen in the same spots with the same working directory would be enough for me.)

[s0ph0s-2]

I'm going to try to adapt the config from @stevenxxiu's comment above to satisfy my desires, and I'll report back here if I succeed.

[yxw]

The old thread Add config option to always open window in full screen/maximized · Issue #284 · wez/wezterm got closed. I could never figure out a native way to maximize the window without flickering. Managed to script it myself today. I thought that's quite relevant to this issue, as it's pretty much what I'm doing. Hope this helps out others.

local wezterm = require 'wezterm'
local mux = wezterm.mux

local cache_dir = os.getenv('HOME') .. '/.cache/wezterm/'
local window_size_cache_path = cache_dir .. 'window_size_cache.txt'

wezterm.on('gui-startup', function()
  os.execute('mkdir ' .. cache_dir)

  local window_size_cache_file = io.open(window_size_cache_path, 'r')
  if window_size_cache_file ~= nil then
    _, _, width, height = string.find(window_size_cache_file:read(), '(%d+),(%d+)')
    mux.spawn_window{ width = tonumber(width), height = tonumber(height) }
    window_size_cache_file:close()
  else
    local tab, pane, window = mux.spawn_window{}
    window:gui_window():maximize()
  end
end)

wezterm.on('window-resized', function(window, pane)
  local window_size_cache_file = io.open(window_size_cache_path, 'r')
  if window_size_cache_file == nil then
    local tab_size = pane:tab():get_size()
    cols = tab_size['cols']
    rows = tab_size['rows'] + 2 -- Without adding the 2 here, the window doesn't maximize
    contents = string.format('%d,%d', cols, rows)
    window_size_cache_file = assert(io.open(window_size_cache_path, 'w'))
    window_size_cache_file:write(contents)
    window_size_cache_file:close()
  end
end)

I ended up by removing the if window_size_cache_file == nil then condition, as it seems this only limit the window resizing work for the first time when the cache doesn't exists, it can't remember window size afterwards.

[Achim63]

This is why I went back to iTerm2 which apparently uses standard macOS calls to handle windows. I use multiple windows, some of them in fullscreen mode - and everything is back as it was after a restart of iTerm. And Cmd+Ctrl+f doesn't work as well to toggle full screen mode as it should in all macOS apps, so I cannot get rid of the top window bar as I need the green full screen button. In pop-ups like "Really quit?" the "yes" is on the left - this is typical for Windows, on a Mac it should be on the right. Things like that are important for many of us spoiled Mac users ;-). And wezterm isn't quite there yet, though very promising in most other regards. So sorry for the rant.

[lwbt]

In pop-ups like "Really quit?" the "yes" is on the left - [...] on a Mac it should be on the right. [...] So sorry for the rant.

Be constructive and pragmatic. This sounds like an easy fix. File an issue, you or someone else can find the line(s) in the code and submit a pull request to solve this problem.

[lioneletaba]

The code provided by @Struki84 wasn't quite right for me. The width and height values weren't updated in the cache after resizing. I modified it and now it works. Here is what is looks like:

wezterm.on("gui-startup", function()
    os.execute("mkdir " .. cache_dir)

    local window_size_cache_file = io.open(window_size_cache_path, "r")
    local window
    if window_size_cache_file ~= nil then
        _, _, width, height = string.find(window_size_cache_file:read(), "(%d+),(%d+)")
        _, _, window = mux.spawn_window({ width = tonumber(width), height = tonumber(height) })
        window_size_cache_file:close()
    else
        _, _, window = mux.spawn_window({})
        window:gui_window():maximize()
    end
end)

wezterm.on("window-resized", function(_, pane)
    local tab_size = pane:tab():get_size()
    local cols = tab_size["cols"]
    local rows = tab_size["rows"] + 2 -- Without adding the 2 here, the window doesn't maximize
    local contents = string.format("%d,%d", cols, rows)

    local window_size_cache_file = io.open(window_size_cache_path, "w")
    -- Check if the file was successfully opened
    if window_size_cache_file then
        window_size_cache_file:write(contents)
        window_size_cache_file:close()
    else
        print("Error: Could not open file for writing: " .. window_size_cache_path)
    end
end)

[pablospe]

Is it possible to get the position of a window object? I am missing something like:

wezterm.on('window-resized', function(window, pane)
  x, y = window:get_position()
  ....

I only see window:set_position() in the documentation, but the I don't see the inverse of it.

[shpankau]

I ran into a strange state today related to this issue. After quitting and later restarting WezTerm, I noticed my prompt was disappearing when it reached the bottom of the pane. The only possible cause I can think of is that before I had quit, I was in full screen mode and had been zooming in and out of the window. I may have quit while the window was still zoomed, which may have led to the confusion. I tried clear, reset, tput reset, tput lines 32, as well as the reset menu option, and even closing and recreating the right pane, but nothing worked. Resizing the window only added or subtracted a few lines from the 70-80 row total. I ended up having to terminate all panes but the upper-left and rebuild the tab pane layout.

TLDR; Don't use macOS Window Zoom to increase the font size - it may mess up your row count!

$ wezterm -V
wezterm 20240203-110809-5046fc22