> We do not issue refunds at this time.

I would consider the information from the FAQ to be a clear sign that you shouldn't really trust the output of this service, even if you didn't know that Chat GPT shouldn't be trusted.

> Some helpful advice for writing is to not be afraid to throw away what you wrote

This has been the most solid advice for me I've received around writing. Usually that panic writing after I've thrown something out and can't recover it produces much better results than the first time around.

For this kind of editing, I like to keep a scratch file (I use notational velocity, but any plain text file works) with sections denoted by Markdown pull-quotes `>` so I can track where I moved them from and what I'm thinking about them. I then use three octothorps `###` to denote breaks between "sections" which is especially helpful when I'm working across multiple documents.

I'll also use diff tools built into Vim/Neovim as well to show progress. I personally like the diffing feature and since I normally edit everything in a Vim-like editor it helps me stay focused with the tools I like.

tldr; I use Notational Velocity to capture ideas or copied text, then create an A and B document while I'm editing to determine progress. I repeat the process as needed. But not usually more than two or three times.

> I like to keep a scratch file

Thanks. I think I am doing something very similiar and will definitely stay close to bare text (Markdown). Your comment shows me that there is no escape from marking up text (places where sth was deleted or some auxiliary header) and working through text couple of times, probably making some copies along way.

> I'll also use diff tools built into Vim/Neovim

Diffing workflow is completely out of bauds for me, maybe will try to learn some new ways in close future (Vim/Spacemacs in general). If you could say some more on how you quickly see diffs, that would be great. Are you using version control for this?

As a side note, I see that it just takes time to tune mind to work efficiently with bigger pieces these days. Modern times, refocus req'ed.

Your comment was very helpful for me, thank you.

If you're more familiar with VSCode, you could use it as your visual diff tool, https://vscode.one/diff-vscode/

But essentially I only ever care about two versions of my writing. The current version that has been edited, and the previous version that basis for the editing. This lets me not have to put things in version control and allows me to only ever really have two versions of something on my plate at any given moment.

If you are more comfortable in the Terminal, you could use a tool like `opendiff` as well which just shows you the lines that have changed. I normally only do this after I have had some rest in between the document revisions. But this view will produce a diff and also is good when you're unsure about certain sections.

I'll part on one last piece of advice which is that you should focus on the goal of what you're doing and pick up new things along the way. What works for me might not work for you exactly and you might have better ways of approach the same given problem. Don't sweat the details until you have enough of them in your tool belt. Good luck!

My most productive time is when I am thoughtful of what I want to accomplish and write it down before I start. It’s really helped me using a script wrapped around Tmux sessions to achieve this. Two simple questions:

What are you working on? What did you work on?

If you're interested in getting better at the terminal, I recommend you learn how to customize it. it'll really help you learn by doing and figuring out what it is you want to learn how to do first.

It's what worked for me, though. There are also some workflow ideas that have really helped a lot. Autocompletion and being about to look through your history for commands is super helpful too.

``` cat $HOME/.bash_history | grep -E 'command|argument' ```

https://github.com/zsh-users/zsh-autosuggestions

I just finished a guid on my site about my terminal setup. I hope to read yours once you've customized the pixels out of it.

Aside from things to get your interested in the internals of your shell via bash scripting, you should also consider writing more shell scripts specifically around your workflows. I keep mine in a .files repo on GitHub. Take a look at the install script. It took me over a year to get really fluent in bash scripting enough to make it possible to get better and better at it.

Good luck on your journey!