Content offset a couple lines

[ianyepan]

After the commit titled "Fix #226 #198 #227", the cursor position seems to be correct, but there are always a few lines of offset (as if someone scrolled down explicitly a couple of lines) that messes up the content. Please let me know if this description is unclear, I can provide some screenshots.

[jixiuf]

screenshots please . and I suggest you use monospace font. (等高等宽字体，尤其一些中文字的高度比英文字体高，会导致屏幕开头的几行显示不全） for example https://github.com/be5invis/Sarasa-Gothic

[ianyepan]

Sure! Screenshots with explanation:

Here's a brand new vterm buffer with the command "ls -la", this is how it was supposed to look like:

However, vterm seems to automatically scroll down a few lines, to become so:

Another example would be "top -u". Here's how it should look like:

But this is how it's presented in emacs vterm, again with the top couple of lines missing (the sumary title, PID, %CPU etc.), as if someone scrolled down by hand.

[jixiuf]

can you reproduced this with make run in emacs-libvterm/build/

[jixiuf]

65b76502d6503e197662f506d6d4212fb333b972 should fix this problem you set

  (setq-default line-spacing 3)

https://github.com/ianpan870102/.personal-emacs.d/blob/master/init.el#L60

[ianyepan]

I really appreciate your time, even going into my personal config to help me find the problem! After your commit with (setq-local line-spacing nil), the content scroll-off problem disappears and everything's smooth. I'll let you know if similar problems resurface, but I'll close this issue for now. Again, thanks for making this package happen, it's a wonderful terminal emulation.

[ianyepan]

Hi @jixiuf sorry to break this to you, but the problem with "a few lines of offset" seems to have reappeared.

Here are a couple of screenshots to illustrate the issue:

How my screen looks after executing the "clear" command.

How my buffer looks when running "top". (Notice the first 4 lines of content is wrong)

My investigation: found a pattern

I tried to find a pattern and here's what I got: the vterm buffer will behave normally (i.e. clear the screen cleanly) if the bottom of terminal buffer is never physically reached. That is, if we always remember to clear screen before the terminal buffer content touches the bottom edge, we're good. But as soon as we have one or more command(s) that prints content for more than 1 buffer height (page), then clear screen no longer works as expected, leaving the uncleared couple of lines on top.

Other notes

I remembered to set line-spacing to nil, and I'm also using a monospace font (Consolas to be precise).

For your reference, this is the vterm-related config I have:

(use-package vterm
  :hook (vterm-mode . (lambda ()
                        (setq-local global-hl-line-mode nil)
                        (setq-local line-spacing nil))))

(use-package vterm-toggle
  :after (projectile vterm evil)
  :config
  (setq vterm-toggle-fullscreen-p nil)
  (setq vterm-toggle-scope 'projectile)
  (with-eval-after-load 'evil
    (evil-set-initial-state 'vterm-mode 'emacs))
  (global-set-key (kbd "C-`") #'vterm-toggle)
  (add-to-list 'display-buffer-alist
               '((lambda (bufname _) (with-current-buffer bufname (equal major-mode 'vterm-mode)))
                 (display-buffer-reuse-window display-buffer-at-bottom)
                 (reusable-frames . visible)
                 (window-height . 0.5))))

This issue occurs with or without loading the vterm-toggle package.

[ianyepan]

@Sbozzolo @jixiuf Friendly ping.

[Sbozzolo]

Thanks, I can reproduce with the following steps:

1. Get a vterm buffer with full scrollback (you can set vterm-max-scrollback a small number)
2. Press RET until the prompt reaches the end of the buffer
3. Fire up top.

In my tests, the problem is not there if the scrollback is full. Can you please verify this?

[ianyepan]

Hi @Sbozzolo thanks for reaching back. My vterm-max-scrollback value is the default 1000 (checked with C-h v).

In my tests, the problem is not there if the scrollback is full. Can you please verify this?

Could you please explain how I can "verify the issue when the scrollback is full"? I don't quite understand what you meant. Cheers!

[Sbozzolo]

Could you please explain how I can "verify the issue when the scrollback is full"? I don't quite understand what you meant. Cheers!

Yes, if vterm-max-scrollback is set to 1000, it means that 1000 lines can be printed on screen before vterm starts removing the oldest ones to make room for new lines. I found that the bug you reported is not triggered with a fresh vterm that has seen fewer than 1000 lines.

To test this, just open a new vterm, ls a couple of times, and try to reproduce the bug.

[ianyepan]

I see what you mean now, thanks! Actually, the bug I reported occurs once "the bottom of the buffer is reached"; it doesn't need to have seen > 1000 lines. That is, I can reproduce it just by opening a new vterm buffer, ls a couple of times until it reaches the end of buffer page (which is around 40 lines?), then clear or top to trigger the offset bug.

[ianyepan]

Upon further investigation

@Sbozzolo I have a break-through. The problem seems to stem from my line-spacing definition in my init.el. I prefer to (setq-default line-spacing 3), and apparently setting vterm's local line-spacing value to nil isn't enough (I thought it was resolved earlier in Feb's thread) -- the global line-spacing value must be nil too. This is the only way that the bug ceased to show up on my end. In fact, if I never set line-spacing in my init.el and leave it as default nil, this bug will never be reproduced, even when an old vterm buffer has seen > 1000 lines.

[pjones]

I'm seeing something similar. When I clear the screen I still have a small number of lines at the top of the terminal from previous commands. Calling vterm-clear-scrollback followed by clear fixes the problem.

I have vterm-max-scrollback set to 10,000 and line-spacing is the default (nil).

Otherwise I absolutely love vterm. Thank you for working on this project @Sbozzolo!

[ianyepan]

Calling vterm-clear-scrollback followed by clear fixes the problem.

Thanks for the tip! In which case, perhaps we can bind vterm-clear to simly vterm-clear + vterm-clear-scrollback? Btw the keybinding for that would be C-l followed by C-c C-l. (Or even better: hold down Ctrl and type l c l)

[ianyepan]

To use C-l to clear screen 'and' scroll back, here's the easy solution I came up with:

(define-key vterm-mode-map (kbd "C-l") #'(lambda ()
                                           (interactive)
                                           (vterm-clear)
                                           (vterm-clear-scrollback))))

This workaround fixes the issue of offset line bug after clear screen. However, the bug persists when running commands like top

[pjones]

@ianpan870102 the only problem with that solution is that I don't want to delete the scrollback buffer as I use it quite often. I'd rather have a more permanent solution that prevents this from happening in the first place.

[ianyepan]

@pjones Fair enough, let's leave this issue open and hopefully we can see a fix in the future :)

[Just-Insane]

I think I'm running into the same issue. I'm currently only noticing it in tmux, but when I first attach to a tmux session or clear the terminal, everything looks fine. However, every time I press enter or issue a command from that state, the tmux status bar at the top goes off the screen.

top/htop appear to display fine however.

I've tried the workaround of setting (setq-default line-spacing nil) and (setq-local line-spacing nil) in init.el and .spacemacs respectively, and the issue persists.

Interestingly, I've also noticed that if emacs is full screen on my Mac and I switch to another window then go back to emacs, the tmux status bar reappears for about a second and then disappears again.

To add to this, changing the font to the Spacemacs default (Source Code Pro, 10pt), and the issue only happens after 4 line returns, not after the first one. This leads to me believe it's to do with not correctly sizing the terminal for the window size?

[gmoutso]

@Just-Insane did you find the answer? second edit: I have deleted my details until I am sure how to replicate it.