suonlight / multi-vterm Goto Github PK

But everything is fine at the first terminal.

https://github.com/akermu/emacs-libvterm#vterm-buffer-name-string

Since multi-vterm-project looks for the buffer by name, setting vterm-buffer-name-string to "%s" will break its ability to toggle the buffer. Instead it creates a new buffer each time.

Ever since the update multi-vterm-dedicated-open will open a dedicated window but with the current buffer selected instead of the vterm-buffer.

Here is a short screen-cast to describe what I mean:

https://streamable.com/htstzv

How about using project.el instead? Built in to emacs, can have projectile support added easily with a few lines.

It would be great to have either a screenshot or even better a GIF screencast in the README to visually see how this package works.

I am trying to get the title (as defined by the shell) to appear in my buffer names. vterm will replace %s by the title when vterm-buffer-name-string is non-nil, as explained in https://github.com/akermu/emacs-libvterm#vterm-buffer-name-string=

However, multi-vterm seems to override that setting and always uses multi-vterm-buffer-name, which does not substitute %s for the title. Is there a way around this?

The changes done yesterday break multi-term-next and multi-term-prev because multi-vterm-buffer-list was converted into a local variable inside multi-vterm function in this line

I've created a pull request (#8) reverting this line.

The way that multi-vterm-project works is that it creates a hidden buffer, enables vterm-mode and then displays it. There appears to be a race condition wherein vterm will set a terminal width to something that is wider than the window it is about to be displayed in. It has no way to know where it is about to be displayed. When the buffer is eventually displayed in a window, it is resized and it looks wrong. To make matters worse, vterm won't detect the size again immediately, it requires some other window or frame event to get it to recalculate.

Bad

Good

This is likely why vterm itself forces you to provide the pop to/display buffer function in the internal function that causes the buffer to have vterm-mode enabled:

https://github.com/akermu/emacs-libvterm/blob/f14d113ee4618f052879509ec378feb9766b871b/vterm.el#L1327-L1342

Since the last update was merged, I am no longer able to provide a buffer name to the multi-libvterm function. Looks like the argument was removed?

EDIT: Not really sure how this actually works, but just adding the optional argument back in and nothing else results in the previous behaviour.. I'm sure it's something I just don't understand about elisp (is the optional arg being passed through implicitly somhow??)

Sending a PR that reverts the behavior for review

The error occurs when the multi-vterm-current-window-height is equal to the multi-vterm-selected-window-height.

 (defun multi-vterm-dedicated-get-window ()
   (setq multi-vterm-dedicated-window
         (split-window
          (selected-window)
          (- (multi-vterm-current-window-height) multi-vterm-dedicated-window-height))))

which is defined

(defcustom multi-vterm-dedicated-window-height 30 ... )

which is what causes the error

(error "Window #<window 3 on *scratch*> too small for spli...")

To solve the problem, I wrote:

(use-package multi-vterm
  :ensure t
  :config
  (progn
    ...
    (setq multi-vterm-dedicated-window-height (/ (frame-height) 2))))

P.S. I hope you find a more elegant solution

Howdy,
When I am using multi-vterm with several vterminal buffers and trying to switch to next / priv one I get error message Attemp to disply deleted buffer even I have three *vterminal*<_> buffer.
E.g.:

ELISP> (seq-filter (apply-partially #'string-match-p "vterminal") (mapcar #'buffer-name (buffer-list)))
("*vterminal<3>*" "*vterminal<1>*" "*vterminal<2>*")
ELISP> (mapcar #'buffer-name multi-vterm-buffer-list)
(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil "*vterminal<2>*" nil "*vterminal<3>*")

as you can see, there is no vterminal<1> in multi-vterm-buffer-list. And I can't use multi-vterm-next when working at vterminal<2> even though there is third vterminal.

BR,
Chengjun

The usage of switch-to-buffer in the multi-vterm command makes the initial display of vterm ignore the user's display-buffer-alist customization.

To reproduce this, you can set:

(setq display-buffer-alist
'(("^\\*vterminal.*$" display-buffer-at-bottom)))

and run M-x multi-vterm.

Consider replacing it with pop-to-buffer-same-window, or let-binding switch-to-buffer-obey-display-actions around the switch-to-buffer call instead?

thanks for working on this package. I have this itch with multi-vterm-dedicated-toggle, I would like to open additional terms on the same dedicated window akin to opening term tabs in Gnome's terminal so I can always have the same amount of screen space while different terms are used for different things or are in different "cwd".

Whenever I try to use the multi-libvterm-prev/next commnads, I get the following error: symbols function definition is void: position

multi-term also uses the same function position, but its not having any issues? Any idea how I can fix this?

EDIT: figured out how to fix this issue, replace position with cl-position from cl-lib

Is it possible to make this package available on MELPA? It would help a lot new users installing and updating! Thank you very much for creating this package 🙌 👏