Jason Felice wrote:
> wrt the interface, I've written a small plugin that starts a terminal
> window with a program that runs my builds and prints their statuses. It
> doesn't have a lot of output. I'd like to be able to have normal-mode-ish
> keys for the window mapped (e.g. dd deletes a build result and makes it
> rerun, <Enter> opens the log of that build). I'm actually doing this now,
> but the terminal doesn't update while in normal mode, so I have to remember
> to put it back into terminal mode (which loses the cursor position). I can
> probably write this plugin to use the job_* functions somehow, but it
> *might* be a useful use case. (Not sure the best way to solve it.)
It sounds like this creates a fight between what is running inside the
terminal and Vim changing what's in the terminal window. There can be
only one cursor, and either Vim tells where it is (Normal mode) or the
job running in the terminal (not Normal mode), can't have both.
However, if the job in the terminal only adds lines at the end, such as
in a shell running "make", it might work. But as soon as you run Vim in
that shell it fails miserably. Not sure how to deal with this.
> I've had some performance problems with the terminal, but nothing else with
> the interface. It took a bit of getting used to, switching back from
> Neovim, but I'm now accustom to the default mappings and find it pretty
> nice to use. It would be nice to add an option to allow terminals to be
> abandoned on :qa and such, but that could also be added later without
> breaking the interface.
Yeah, having to exit the shell (or kill the tail command or whatever is
running there) can be a hassle. Again, in general it's not a good idea
to just kill whatever is running (e.g., make isn't finished yet). We
could add a flag to tell Vim it's OK to kill the job in the terminal, or
try sending keys to make it stop (e.g. send "exit<CR>" to the shell).
> The performance problems may be related to sudden copious output (a lot of
> rust compiler warnings at once trigger it for me), or maybe ANSI escapes of
> some kind. Vim locks up for say 30 or so seconds, moving the cursor but
> not really redrawing the terminal (as far as I can tell) and not being
> responsive to input. If I run the same command after suspending Vim, it
> takes <1 second.
There still is a bug that I haven't been able to pinpoint, where the
terminal doesn't update. On the other hand, what you describes sounds
like Vim skipping a redraw because more is coming, which is actually a
good thing. Libvterm isn't all that efficient when it comes to large
amounts of text to display.
--
At some point in the project somebody will start whining about the need to
determine the project "requirements". This involves interviewing people who
don't know what they want but, curiously, know exactly when they need it.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
