emacs-libvterm
emacs-libvterm copied to clipboard
re-wrap line when window resized
Currently, when you change the window's width,
-
enlarge width: the line wrapped at the original width.
actual:
expected:------------------------- -------------------------------------- | $This is a long sente | | $This is a long sente | | nce that got wrapped | -> | nce that got wrapped | | before resize | | before resize | ------------------------- --------------------------------------
------------------------- -------------------------------------- | $This is a long sente | | $This is a long sentence that got | | nce that got wrapped | -> | wrapped before resize | | before resize | | | ------------------------- --------------------------------------
-
shrink width: the line got truncated at new width.
actual:
expected:------------------------- -------------------- | $This is a long sente | | $This is a long s| | nce that got wrapped | -> | nce that got wrap| | before resize | | before resize | ------------------------- --------------------
------------------------- -------------------- | $This is a long sente | | $This is a long | | nce that got wrapped | -> | sentence that go | | before resize | | t wrapped before | ------------------------- | resize | --------------------
I wonder if it is easy to do the re-wrapping of the text?
I've ran into the same issue but would be perfectly happy with a no-wrapping, no-truncating version. i.e:
+--------------------------------------------------+
| $ some program |
| > a very long output that should not wrap to avoi|d the resize issues
+--------------------------------------------------+
Which means I can peep into that buffer full-width/height if I need to grasp a potentially verbose stacktrace and reversely, if I don't, it can use the unbound hidden width to spread, rather than polluting a narrow vterm buffer.
I've tried Emacs's toggle-truncate-lines
and toggle-word-wrap
and no combination achieves it.
I also ran into this issue when testing out vterm
. vterm-min-window-width
kind of works around the issue if I set to a large enough number and turn on toggle-truncate-lines
. But that messes up the output for commands like ls
and the right sided prompt in zsh
.
Would be awesome if this could work similar to what emacs shell
is doing i.e. leave the word wrapping to emacs but still adhere to the column width of the buffer. As that would also solve the issue of when copying output, as right now it also includes the hardcoded word wrapping.
But looking at the code it looks like this is a limitation in libvterm
and not emacs-libvterm
, is that correct?
#274 might start getting this going. With #274 vterm now tracks where the "fake" newlines are inserted. This might help with re-flowing, but for sure will help when killing text.
@jixiuf or @mbrumlow Would you mind commenting on the current state of this?
This is a major problem when using tiling window managers, as frames are frequently moved and resized during tiling operations.
I am working around this bug by running screen
inside vterm to handle dynamic resizing and wrapping:
(setq vterm-shell "screen")
It is advisable to configure screen, in .screenrc
, to allow emacs to control scrollback (unless you prefer screen scroll facilities):
termcapinfo xterm* ti@:te@
This matches the vterm TERM=xterm-256color
.
I am also running into this problem. Screen splitting happens often in Emacs and this causes previous output to be hard-wrapped.
same here, also using vterm with compilation-shell-minor-mode
which fails to find the file path + line number when the path is split on several lines
Any update on this? Running into the same issue with some ncurses applications.