Feature request: `vterm-exec`

[Massimiliano Mirra]

term-mode offers term-exec to reuse existing buffers:

(term-exec BUFFER NAME COMMAND STARTFILE SWITCHES)

Start up a process in buffer for term modes.
Blasts any old process running in the buffer.  Doesn’t set the buffer mode.
You can use this to cheaply run a series of processes in the same term
buffer.  The hook ‘term-exec-hook’ is run after each exec.

eat offers a similar eat-exec.

Could vterm provide a similar function that decouples mode setting from process execution, or are there gotchas specific to vterm that would make it a bad idea?

Background: bard/emacs-run-command#20 (comment)

[Gabriele Bozzola]

I don't fully follow what is happening and what is that you are asking for, but I can provide some additional background on how vterm works.

In contrast to term, and eat, vterm if half written in C half in elisp. The C part is very important as they interface with libvterm, which deal with all the nitty-gritty details of terminal emulation. The communication between the different parts happen by maintaining a pointer to a C struct. Each vterm buffer has its own pointer and we try to discourage changing major modes to avoid messing up with this pointer. By far, the easiest way to run a command in a vterm buffer is by sending a string to it with vterm-send-string, so that the code goes through everything that needs to be done from both the C and Emacs sides. Does this help?

[Massimiliano Mirra]

I could/should have summarized my question into: after the process I run in a vterm buffer is done, is it a bad idea to run another process in the existing vterm buffer?

Currently vterm complains that You cannot change major mode in vterm buffers, because for vterm (contrary to term and eat) process creation is coupled with mode setting.

However, in the case of running a process in the existing buffer, the buffer would go from vterm-mode → vterm-mode rather than vterm-mode → other-mode, so it should be fine? The hack I posted at bard/emacs-run-command#20 (comment) seems to indicate that it is, and that what prevents it now is the implementation rather than a design limitation.