Tell us your ideas to improve PTerm!

[MarvinJWendt]

If you have any suggestions about what can be integrated into PTerm, or what can be used to improve PTerm, this is the place to discuss them 🚀

[m5lk3n]

Hi Marvin,

PTerm is great, thanks much for that!

One thing that I noticed is the following:

When I run

package main

import (
	"fmt"
)

func main() {
	const name, age = "Kim", 22
	fmt.Println(name, "is", age, "years old.")
}

I get

Kim is 22 years old.

while

package main

import (
	"github.com/pterm/pterm"
)

func main() {
	const name, age = "Kim", 22
	pterm.Println(name, "is", age, "years old.")
}

produces

Kimis22years old.

The example is taken from Golang's documentation here which states "Spaces are always added between operands".

What do you think? Would it make sense to support that as well?

Thanks and keep up the great work,

Michael

[MarvinJWendt]

Hi Michael, thanks for the compliment 😄 Yes this should definitely be the default behavior. I will be able to work on PTerm in February. If you want, you can create an issue (feature request) for that. If you'd like to make a PR, feel free to do so and I will merge it before February. Have a nice day, and stay healthy! 👍

[m5lk3n]

Great, thanks Marvin. FR created.

[profour]

Hi @MarvinJWendt!

Discovered this project through a recent HackerNews post and wanted to say PTerm is a great project so far in my experience. I saw you were asking for improvement ideas so I wanted to send in my use case and see if any ideas shake out of it. As PTerm is right now, it seems well tailored to embed directly into a CLI tool and directly feed a single local terminal. In my use, I'm trying to shim PTerm into a custom golang-based ssh server that could be hosting dozens of remote connections with PTerm generating content that is fed back to their terminals over ssh. To my knowledge, this isn't possible in PTerm's current state, because the input (keyboard) is tied to the local execution environment and also assumes there is only one terminal window size as shared global state. In the ssh scenario, I can have numerous terminal sizes active simultaneously as well as a unique input feed per ssh session. However, I did notice that the output (io.Writer) was pluggable for a lot of the printers and that was a great starting point for me to think about solving these other issues.

From there, I forked PTerm to play with it for my needs and was able to extract the issues identified above into a Terminal interface that would be provided to all of the different printers. The interface is basically a bundling of terminal window size, input keys and output writer, and a small tailoring for different line endings. I'm still a novice at golang and my effort was really a hack job going through to extract it all, but it does appear to be working now as a multi-headed terminal printer for my custom ssh server. I really appreciate all of the effort you put into unit testing as that made my job much easier to ensure I didn't break functionality as I was slashing my way through the codebase. It only took a few hours to make the changes I needed, which I think is quite a testament to how approachable the codebase is.

As far as feature proposals, the changes needed for this are pretty sweeping so I can understand if there isn't an interest, but you may see some value in the future to separate out the Terminal as a pluggable interface for printers. The WithWriter approach that you have in some printers could potentially be replaced with a WithTerminal approach to allow for multiple independent terminals. I believe I also have two additional enhancements I will need to make to really fit well in my SSH session context: on-demand reprint of PTerm content when a ssh session's terminal window is resized and possibly buffering content from the interactive printers on logical flush boundaries so it prints better over a latent network connection.

Thanks again for this cool project!

[MarvinJWendt]

Hi @profour, thanks for the complement and the very detailed proposal! This is definitely something we will (and should) consider. I've looked at your fork and I like the implementation so far, but sadly we cannot introduce such breaking changes. I do think, this should be possible without breaking anything, tho. If you want, you can make a feature request in the issues :)