Multiple drawbacks with the design and functionality

[kqvanity]

Firstly i would like to thank for this plugin. However, it has some 'drawbacks' that kills the experience to some extent, namely

• Unable to have an option to save/update the buffer before running, and so if i modified the code, i'll have to explicitly write the buffer content, before executing, or else the plugin will keep running the old buffer/file itself.
• Interactive code (redirection of stdin) doesn't work
• If the code resulted in an error, then the plugin will display two redundant buffers, the second becomes completely vacant of code output, and the third buffer gets my cursor forcefully switch to. Afterwards, i'll have to hop back two buffer up. If there's a better design than this one, then that would be really great.
• No indication of endless loops. Just vacant output. And so, if you don't an indicator for CPU let's say, the background process would just go unnoticed in the background
• Buffer output and continuous output stream should change accordingly. Meaning that if i have a loop that outputs from 1 to 100, then the buffer should change its view/scroll down accordingly as the output populates.
• The output buffer should be subordinate to the typical code buffer. Meaning that, if i just closed the last 'typical code' buffer, the output buffer should automagically close too.

Thanks!

[erietz]

Thanks for the feedback!

Issue 1

Unable to have an option to save/update the buffer before running, and so
if i modified the code, i'll have to explicitly write the buffer content,
before executing, or else the plugin will keep running the old buffer/file
itself.

An easy fix to this would be to just save the file before running the code in
whichever functions those are. I don't see any harm in saving the file each
time you try to run the code. I will work on this soon.

Issue 2

Interactive code (redirection of stdin) doesn't work

I am not sure what you mean exactly by interactive code? For redirection of
stdin it seems to work for me (though I have never thought of doing this
before).

Redirecting stdin from a file like this correctly sorts test.txt.

TerminatorRunAltCmd sort < test.txt

For interactive stuff I also end up using TerminatorRunFileInTerminal rather
than the output buffer via TerminatorRunFileInOutputBuffer. Can you provide
an example of what you would like to do?

Issue 3

If the code resulted in an error, then the plugin will display two
redundant buffers, the second becomes completely vacant of code output, and
the third buffer gets my cursor forcefully switch to. Afterwards, i'll have
to hop back two buffer up. If there's a better design than this one, then
that would be really great.

This also drives me nuts! I have just never gotten around to fixing this
annoyance. Though it is not directly related to this issue, I have been
thinking I also want another command which closes the output buffer.
I personally don't like splits very much and usually end up doing
a <c-w><c-o> to focus on just the buffer that I am editing.

I have this in my init.lua

map('n', '<leader>c', ':cclose<bar>lclose<CR>', noremap)

If there was a command to close the output buffer, we could do something like

map('n', '<leader>c', ':cclose<bar>lclose<CR><bar>TerminatorClose', noremap)

to close all the splits.

Although this does not fix the root of the problem which is that there are

"two redundant buffers"

Without thinking about any code, what would be your ideal workflow in the case
of errors?

Issue 4

No indication of endless loops. Just vacant output. And so, if you don't an
indicator for CPU let's say, the background process would just go unnoticed
in the background

Yes this kind of suck too at the moment. What do you propose?

[kqvanity]

I don't see any harm in saving the file each time you try to run the code. I will work on this soon.

I just see it more intuitive that when i'm about to run the code, it would be more helpful to update buffers before execution. I rebound the keybinds and appended the command, but it would be more nice if it was the default behavior or at least toggable.

For interactive stuff I also end up using TerminatorRunFileInTerminal rather than the output buffer via TerminatorRunFileInOutputBuffer. Can you provide an example of what you would like to do?

Interactive in the sense of the code prompting for input. I've already tried out TerminatorRunFileInTerminal but it only pops up a vacant terminal pane.

Without thinking about any code, what would be your ideal workflow in the case
of errors?

Unfortunately i'm not knowledgeable about vim mechanics used in scripting, but generally there are two possible outputs for both interpreted and compiled languages. Interpreted ones will execute and result in outcome (if printing to stdout) while reading line by line, whereas compiled will yield in nothing but single error in one go, even if it's only last line that's missing a semicolon. Therefore i would say that you can't ditch the buffer output in favor error buffer when errors took place (as interpreted langs' users would probably sometimes want to see the code result before the error took place). I would say Having one pane being displayed, but all of the panes collectively have the inherent keybind-confined key combinations to toggle between them (at the single pane) . Maybe you could have their order for switching their order at the pane as the following putput/error/debugging log buffer.

Yes this kind of suck too at the moment. What do you propose?

I guess that you can't programmaticaly distinguish between and endless loops and computationally intensive operations, unless the interpreter have this internal analyzer , but this won't be the case always and not scalable. I would suggest the output buffer should have a more distinctive prompt (not shell prompt) that is normally non-running code state have this distinguishing look ,then as long as it's executing code/binary output running then it should be in another state (indicating of running operation). When i say another distinguishing, i mean it has to be always different, so if you have this loop that you mindlessly initialized, and the computer cycles is looping over and over again on it whether its outputting anything anything to stdout or not, then the output prompt should be always having a separate indicator of a running job.

I also appended another point at the first comment.

Buffer output and continuous output stream should change accordingly. Meaning that if i have a loop that outputs from 1 to 100, then the buffer should change its view/scroll down accordingly as the output populates.

I guess this can be implemented in a way that the output pane will be always of a invariable size, and that the buffer always shows the latest/output data tail, where tail size is the amount of rows the pane haze in size (don't know if this is attinable or not, but just speculating)

[erietz]

For the multiple redundant windows thing, I think the easiest thing would be to just set a flag from False to True if the process generates any STDOUT at all. Then if the exit code is non-zero and the flag has not been set, I should automatically close the output buffer.

I've been busy but I'll try to get most of these fixed this week.

[erietz]

I may end up separating these bullet points out into their own issues while working on the fixes. Thanks again for the ideas.

[erietz]

Unable to have an option to save/update the buffer before running, and so if i modified the code, i'll have to explicitly write the buffer content, before executing, or else the plugin will keep running the old buffer/file itself.

This has been fixed

[erietz]

I have also just pushed some changes to attempt to fix the multiple redundant buffers issue on error. @z0xyz can you please give it a shot and let me know if these changes make sense to you?

You can try running this file with the exit(0) and with the exit(1) to test the differences.

vim-terminator/test/manual/errors.py

Line 7 in 76d7442

# exit(0)

Note that I have also added a command TerminatorToggleOutputBuffer so that you can still open up the output buffer on errors if you want to see if anything went to stdout.

Also are you on vim or neovim?

[kqvanity]

This has been fixed

Indeed. I've removed the prepended update command, and it still executed the latest buffer changes.

You can try running this file with the exit(0) and with the exit(1) to test the differences.

It only works with exit(1) manually added. If lets say i had a typo at one of the lines, resulting in typical error, it would still fallback to the previous behavior i.e. two buffers stacked on top of each other.

Also are you on vim or neovim?

I'm on vim.

I may end up separating these bullet points out into their own issues while working on the fixes.

I've reformatted them to checkboxes. Still, if you would still want to separate them into multiple issues, i'm okay that. Thanks for the current fixes.

[erietz]

Aww, the buffer issue I only fixed for neovim. I’ll figure out plain vim in the morning.

…

On Apr 7, 2022, at 9:01 PM, polendina ***@***.***> wrote:  This has been fixed Indeed. I've removed the prepended update command, and it still executed the latest buffer changes. You can try running this file with the exit(0) and with the exit(1) to test the differences. It only works with exit(1) manually added. If lets say i had a typo at one of the lines, resulting in typical error, it would still fallback to the previous behavior i.e. two buffers stacked on top of each other. Also are you on vim or neovim? I'm on vim. I may end up separating these bullet points out into their own issues while working on the fixes. I've reformatted them to checkboxes. Still, if you would still want to separate them into multiple issues, i'm okay that. Thanks for the current fixes. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[erietz]

I have made the same changes on the vim side as were done for the neovim side. While testing using vim, I noticed that running the file in the terminal does not work! This explains this comment:

Interactive in the sense of the code prompting for input. I've already tried out TerminatorRunFileInTerminal but it only pops up a vacant terminal pane.

I have created a new issue for this #20

I'll continue working on the rest.

[erietz]

@z0xyz I have made many changes (hopefully fixes) and I hope you agree with these new design choices. Please give the newest changes from the main branch a try.

No indication of endless loops. Just vacant output. And so, if you don't an indicator for CPU let's say, the background process would just go unnoticed in the background

I have changed it so that you can only run one job at any given time in the output buffer. Before any new job actually starts the current running job is terminated. If you have a long running job that you do not want to wait for, you can close the output buffer using either the commands :TerminatorOutputBufferClose or :TerminatorOutputBufferToggle. By doing this, the user has mentally acknowledged that they have a job running and they are ignoring it. It is up to them to keep track of it.

Buffer output and continuous output stream should change accordingly. Meaning that if i have a loop that outputs from 1 to 100, then the buffer should change its view/scroll down accordingly as the output populates.

This happens automatically if you run the file in the terminal via :TerminatorRunFileInTerminal. Some changes were made on the vim side of things since I initially wrote the plugin which had broken this functionality. This should be fixed now. Interactive commands can also be ran in the terminal using the same command.

The output buffer should be subordinate to the typical code buffer. Meaning that, if i just closed the last 'typical code' buffer, the output buffer should automagically close too.

This is the one remaining check box which I do not know how to implement very easily.

[kqvanity]

Some changes were made on the vim side of things since I initially wrote the plugin which had broken this functionality. This should be fixed now.

Unfortunately, the same old behavior is still remaining.

This is the one remaining check box which I do not know how to implement very easily.

I've tried to accomplish this by looping through all the opened buffers, and if they're not of output_buffer and qf file types, then quit the editor. However, i guess the loop and check should be invoked with an event that gets fired "after" the buffer is unloaded or wiped out, not before.