Alternative writer interface `func(string)`

[ghostsquad]

I was wondering if you would be interested in providing an alternative interface for writing, a func(string) in the config.

This would allow support for some special cases when using a carriage return to "reset" the displayed string is not supported.

[theckman]

Are you able to be more specific about the use case? I'm not sure I follow.

Are you talking about when the output is piped?

[ghostsquad]

@theckman ya, happy to discuss more. Basically, my specific use case is I want to use yacspin within https://github.com/rivo/tview - That's a Terminal UI Framework. Since that framework is what "draws" on the screen, all I need from yacspin is the string that is produced, then notify tview to "redraw".

There's some more details here including some example code: https://github.com/rivo/tview/issues/462

[theckman]

@ghostsquad I'm fairly ignorant to how tview works, so apologies if I'm asking some obvious questions.

I assume the code with yacspin running is being invoked by tview, and then the output from the yacspin'd binary is being printed by tview?

If so, might it be better to say that the issue is yacspin blindly assumes it's in an interactive terminal session, and then tries to behave as such? Including using \r to overwrite the line? If it were to identify it's not connected to a TTY directly, we could have it behave differently and not write those characters out.

Would you say that's a reasonable understanding of the situation and one of the potential solutions? Trying to make sure I fully grok the problem. :)

[ghostsquad]

You nailed it. With one caveat. You can't really use io.Writer since that assumes it's ok to just continue writing updates to the same stream. I need to know the "current" state of the spinner.

[theckman]

Could you explain what you mean by needing to know the state?

[ghostsquad]

State == what should be on the screen at any given time

[theckman]

@ghostsquad I am trying to understand whether this is a problem that should be solved by yacspin, or if I should add support for detecting a TTY and then leave it up to the consumer to write a wrapper to support whatever peculiarities tview has. I am reluctant to expand the API to support behaviors of a project I hadn't seen before this issue was raised, without understanding the technical need and whether other things need the same type of hook.

Being very transparent, I'm now following the problem and what you need to solve the problem. Why do you need to know what's supposed to be on screen?

[ghostsquad]

So that I can update the contents of tview.TextView object or a TableCell. This is a primitive object that simply displays text. tview will update that text.

[ghostsquad]

Other clarifications. Since tview is a terminal gui, it would likely be running in a TTY, since that's it's primary use case.

[ghostsquad]

If you have a better way of providing an isolated "snapshot" of what the spinner should look like at any given moment, and provide that to the client. Then update that snapshot (not append, which is what is currently being done with io.Writer), I'm happy to hear it. But I'm pretty sure that's what my PR does.

[ghostsquad]

I'm not sure how else to explain it. Currently Yacspin supports only explicitly outputting to something like os.Stdout (assumed that it's a terminal), and takes advantage of carriage returns in order to "overwrite" previously written state. My PR allows each individual state update to be used however it's needed, as seen below. Each line would be considered a "snapshot" of the spinner.

| doing something
/ doing something
- doing something
\ doing something
✔️ done

[ghostsquad]

sorry for bothering you. This is clearly outside the scope of what you intend for this repo. I found an exceedingly simple alternative here that has the flexibility I need.

https://github.com/tj/go-spin