mirrors/foot
1
0
Fork 0
mirror of https://codeberg.org/dnkl/foot.git synced 2026-02-04 04:06:06 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
foot/commands.c

133 lines
3.6 KiB
C
Raw Normal View History

wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
#include "commands.h"
#define LOG_MODULE "commands"
scrollback: disable debug logging
2019-07-10 14:45:00 +02:00
#define LOG_ENABLE_DBG 0
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
#include "log.h"
#include "grid.h"
selection: handle viewport wrap around correctly When the viewport wraps around, the selection points may be "incorrect".
2020-05-19 18:49:42 +02:00
#include "render.h"
#include "selection.h"
#include "terminal.h"
command: scrollback: don’t allow scrolling in URL mode
2021-02-23 09:28:43 +01:00
#include "url-mode.h"
util.h: new header file defining commonly used macros
2020-05-01 11:46:24 +02:00
#include "util.h"
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
void
scrollback: initial support for mouse scrolling
2019-07-10 09:15:37 +02:00
cmd_scrollback_up(struct terminal *term, int rows)
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
{
scrollback: initial support for mouse scrolling
2019-07-10 09:15:37 +02:00
if (term->grid == &term->alt)
return;
command: scrollback: don’t allow scrolling in URL mode
2021-02-23 09:28:43 +01:00
if (urls_mode_is_active(term))
return;
scrollback: initial support for mouse scrolling
2019-07-10 09:15:37 +02:00
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
const struct grid *grid = term->grid;
const int offset = grid->offset;
const int view = grid->view;
const int grid_rows = grid->num_rows;
const int screen_rows = term->rows;
int scrollback_start = (offset + screen_rows) & (grid_rows - 1);
/* Part of the scrollback may be uninitialized */
while (grid->rows[scrollback_start] == NULL) {
scrollback_start++;
scrollback_start &= grid_rows - 1;
scrollback: fix scrolling outside initialized lines in new terminal
2019-07-10 14:28:20 +02:00
}
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
/* Number of rows to scroll, without going past the scrollback start */
int max_rows = 0;
if (view + screen_rows >= grid_rows) {
/* View crosses scrollback wrap-around */
xassert(scrollback_start <= view);
max_rows = view - scrollback_start;
scrollback: don't scroll past scrollback history
2019-07-10 09:29:36 +02:00
} else {
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
if (scrollback_start <= view)
max_rows = view - scrollback_start;
else
max_rows = view + (grid_rows - scrollback_start);
scrollback: don't scroll past scrollback history
2019-07-10 09:29:36 +02:00
}
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
rows = min(rows, max_rows);
if (rows == 0)
return;
int new_view = (view + grid_rows) - rows;
new_view &= grid_rows - 1;
scroll-up: ensure view is valid after adjusting an overshot scrollback When we scroll up, we need to ensure that we don't scroll too far, "past" the scrollback limit. I.e. we need to ensure we don't wrap around. The code did this. But, in certain scenarios, the resulting view points into uninitialized scrollback history. This happens when we haven't yet filled the entire scrollback, and scroll up enough lines to wrap around the scrollback. The old code would adjust the view for the wrap around, but doing so pointed the view at the not-yet utilized scrollback.
2020-02-21 23:35:43 +01:00
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
xassert(new_view != view);
xassert(grid->rows[new_view] != NULL);
scrollback: in debug, verify all rows in the view are initialized
2019-07-10 16:36:10 +02:00
#if defined(_DEBUG)
for (int r = 0; r < term->rows; r++)
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
xassert(grid->rows[(new_view + r) & (grid->num_rows - 1)] != NULL);
scrollback: in debug, verify all rows in the view are initialized
2019-07-10 16:36:10 +02:00
#endif
scrollback: don't allow more scrolling when already at the top or bottom
2019-07-10 14:42:48 +02:00
LOG_DBG("scrollback UP: %d -> %d (offset = %d, end = %d, rows = %d)",
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
view, new_view, offset, end, grid_rows);
scrollback: use scroll damage to speed up scrolling When scrolling through the scrollback lines, use scroll damage instead of re-rendering the entire screen whenever it makes sense. I.e. when the number of lines isn't a whole page or more.
2019-08-04 19:06:49 +02:00
selection: handle viewport wrap around correctly When the viewport wraps around, the selection points may be "incorrect".
2020-05-19 18:49:42 +02:00
selection_view_up(term, new_view);
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
term->grid->view = new_view;
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
if (rows < term->rows) {
term_damage_scroll(
term, DAMAGE_SCROLL_REVERSE_IN_VIEW,
(struct scroll_region){0, term->rows}, rows);
term_damage_rows_in_view(term, 0, rows - 1);
scrollback: use scroll damage to speed up scrolling When scrolling through the scrollback lines, use scroll damage instead of re-rendering the entire screen whenever it makes sense. I.e. when the number of lines isn't a whole page or more.
2019-08-04 19:06:49 +02:00
} else
term_damage_view(term);
url-mode: store absolute row numbers in start/end coordinates This allows us to update the jump label positions when the viewport changes. This in turn allows us to stay in URL mode while the user is using the mouse to scroll in the scrollback history. Scrolling with the keyboard is currently not possible, since input handling in URL mode does not recognize “regular” key bindings. We _could_ add scrollback up/down bindings to URL mode too, but lets not, for the time being. (Note: an alternative to this patch is to disallow mouse scrolling too. Then we could have kept the URL start/end as viewport local coordinates).
2021-02-06 11:47:59 +01:00
render_refresh_urls(term);
render: add render_refresh()
2019-07-24 20:09:49 +02:00
render_refresh(term);
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
}
void
scrollback: initial support for mouse scrolling
2019-07-10 09:15:37 +02:00
cmd_scrollback_down(struct terminal *term, int rows)
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
{
scrollback: initial support for mouse scrolling
2019-07-10 09:15:37 +02:00
if (term->grid == &term->alt)
return;
command: scrollback: don’t allow scrolling in URL mode
2021-02-23 09:28:43 +01:00
if (urls_mode_is_active(term))
return;
scrollback: initial support for mouse scrolling
2019-07-10 09:15:37 +02:00
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
const struct grid *grid = term->grid;
const int offset = grid->offset;
const int view = grid->view;
const int grid_rows = grid->num_rows;
const int screen_rows = term->rows;
const int scrollback_end = offset;
/* Number of rows to scroll, without going past the scrollback end */
int max_rows = 0;
if (view <= scrollback_end)
max_rows = scrollback_end - view;
else
max_rows = offset + (grid_rows - view);
rows = min(rows, max_rows);
if (rows == 0)
scrollback: don't allow more scrolling when already at the top or bottom
2019-07-10 14:42:48 +02:00
return;
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
int new_view = (view + rows) & (grid_rows - 1);
scrollback: don't scroll past scrollback history
2019-07-10 09:29:36 +02:00
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
xassert(new_view != view);
xassert(grid->rows[new_view] != NULL);
scrollback: in debug, verify all rows in the view are initialized
2019-07-10 16:36:10 +02:00
#if defined(_DEBUG)
for (int r = 0; r < term->rows; r++)
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
xassert(grid->rows[(new_view + r) & (grid_rows - 1)] != NULL);
scrollback: in debug, verify all rows in the view are initialized
2019-07-10 16:36:10 +02:00
#endif
scrollback: don't scroll past scrollback history
2019-07-10 09:29:36 +02:00
scrollback: don't allow more scrolling when already at the top or bottom
2019-07-10 14:42:48 +02:00
LOG_DBG("scrollback DOWN: %d -> %d (offset = %d, end = %d, rows = %d)",
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
view, new_view, offset, end, grid_rows);
scrollback: use scroll damage to speed up scrolling When scrolling through the scrollback lines, use scroll damage instead of re-rendering the entire screen whenever it makes sense. I.e. when the number of lines isn't a whole page or more.
2019-08-04 19:06:49 +02:00
selection: handle viewport wrap around correctly When the viewport wraps around, the selection points may be "incorrect".
2020-05-19 18:49:42 +02:00
selection_view_down(term, new_view);
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
term->grid->view = new_view;
commands: refactor scrollback up/down When moving the viewport in the scrollback (i.e. “scrolling”), we need to ensure the viewport is not moved past the beginning, or end, of the scrollback. This was previously accomplish by first limiting the number of lines to scroll to the number of visible rows (i.e the viewport _size_), and by adjusting the viewport after moving it, to ensure it doesn’t point into an uninitialized scrollback area etc. I.e. the implementation was _reactive_. This patch rewrites the logic to be _proactive_; we now calculate _where_ the beginning (or end) of the scrollback is, and then how many lines there is from there, to the viewport. This is our _maximum_ number of lines to scroll. When done correctly (which I hope this patch does), this allows us to remove _all_ checks after moving the viewport - we already _know_ it’s correct, and valid. As a bonus, we can remove the old limit, where scrolling was only allowed to be at most a single page.
2022-02-23 18:59:06 +01:00
if (rows < term->rows) {
term_damage_scroll(
term, DAMAGE_SCROLL_IN_VIEW,
(struct scroll_region){0, term->rows}, rows);
term_damage_rows_in_view(term, term->rows - rows, screen_rows - 1);
scrollback: use scroll damage to speed up scrolling When scrolling through the scrollback lines, use scroll damage instead of re-rendering the entire screen whenever it makes sense. I.e. when the number of lines isn't a whole page or more.
2019-08-04 19:06:49 +02:00
} else
term_damage_view(term);
url-mode: store absolute row numbers in start/end coordinates This allows us to update the jump label positions when the viewport changes. This in turn allows us to stay in URL mode while the user is using the mouse to scroll in the scrollback history. Scrolling with the keyboard is currently not possible, since input handling in URL mode does not recognize “regular” key bindings. We _could_ add scrollback up/down bindings to URL mode too, but lets not, for the time being. (Note: an alternative to this patch is to disallow mouse scrolling too. Then we could have kept the URL start/end as viewport local coordinates).
2021-02-06 11:47:59 +01:00
render_refresh_urls(term);
render: add render_refresh()
2019-07-24 20:09:49 +02:00
render_refresh(term);
wip: initial scroll back support Can scroll up and down, and stops when the beginning/end of history is reached. However, it probably breaks when the entire scrollback buffer has been filled - we need to detect when the view has wrapped around to the current terminal offset. The detection of when we've reached the bottom of the history is also flawed, and only works when we overshoot the bottom with at least a page. Resizing the windows while in a view most likely doesn't work. The view will not detect a wrapped around scrollback buffer. I.e. if the user has scrolled back, and is stationary at a view, but there is still output being produced. Then eventually the scrollback buffer will wrap around. In this case, the correct thing to do is make the view start following the beginning of the history. Right now it doesn't, meaning once the scrollback buffer wraps around, you'll start seeing command output...
2019-07-09 16:26:36 +02:00
}
Reference in a new issue Copy permalink