`x thread`

[adriangalilea]

`x thread`

[devhindo]

These are some pretty neat ideas!

for the thread command

I like the interactive mode for creating a thread and I'm thinking about making it a separate command to be just x thread to enter the interactive mode and start typing as you mentioned.

I also like the color feature when exceeding the tweet limit and I'm gonna implement it.

About 2. (replying to the last tweet). It would be a useful successor to x thread if a tweet for example needs to be added to the thread after posting. Got it. It might as well include a reverse index (staring from 0) to be x reply -n 5 -c "text" to reply to the 4th most recent tweet.

for 3. what about a separate command x reply? Ex: x reply -i <tweet-id> -c <reply-text> or x reply -n <reverse-index> -c <reply-text> ( -n indicates the tweet number in recent order starting from 0, Ex: 1 for the 2nd most recent tweet in profile.

That said, I'm planning to change the structure of the whole tool to be more professional and add some features to be more complete instead of just posting a simple tweet.

first I would change the -t flag thing to be a longer command as follows
x tweet -c "hi" -w 2d5h6m7s -d 2024-12-12 -t 3:34pm

-c for tweet content

• -w This is a wait flag that is optional for scheduling future tweets, in the previous example it's set to schedule the tweet to be posted after 2 days, 5 hours, 6 minutes, and 7 seconds (I might exclude the seconds). It also accepts multiple syntaxes like for example 5h, 2h6m, or 10m. As I said it's an optional flag and its default value is 0 indicating that the tweet should be posted now.
• -d and -t: date and time is an alternative for -w to indicate the day and time to post the tweets. Also, the default value if they don't get passed is now. You can't also enter -w with them, You gotta choose one, either the -w flag or -d and -t. If you entered just -t I'm assuming you want the tweet to be posted today in the specified time. and ofc errors will rise if you entered a date in the past.

So, the only required flag is -c for the content. Ex: x -c "Hello" so that's replacing the -t flag which is gone now.

I might as well include an optional flag --output-id to show the tweet id as you said.

example	behavior	terminal output
x tweet -c "Hello"	Hello tweet gets posted	tweet posted!
x tweet -c "Hello" --output-id	Hello tweet gets posted	tweet posted! \n id:
`x tweet -c "Hello" -d 12	posting a tweet on the 12th of the current month at the current time of the machine	tweet posted!
`x tweet -c "Hello" -d 5-15	posting a tweet on the 15th of May at the current time of the machine	tweet posted!

you might as well make an alias for x tweet -c to be tw for easier usage

So now we have 3 main commands

x tweet, x reply and x thread

any changes to the current commands or suggestions for new commands are welcomed

Thanks for your contribution

[adriangalilea]

I agree with mostly everything you said but I have a couple remarks:

I would love to preserve the option to tweet like x "Hello world! so everything else should go under -param, -reply / -r, -thread / -t instead of x thread I do feel like non - params in cli is confusing. Most common use-case will be simply tweeting, so that being the no parameter option is so ergonomic.

Additionally you can add simply x that being a simplistic "tui" that let's you choose your option.
Option A

$ x

⦿ tweet
o reply
o thread

Option B

$ x

1. tweet
2. reply
3. thread

That would initiate the same interactive mode we mentioned earlier.

So you could do $ x -> enter(Option A) or 1(Option B) and be in the tweeting mode, it's so simple you just get muscle memory doing it twice.

Either option is fine, the numbers give you the same number of keys for all the options, but the other one feels more interactive and inviting, and probably both can be combined now that I think of it.

And of course TUI's have so many possibilities and are a slippery slope that may overcomplicate the project depending of what you want, but since you like Go, I suggest taking a look at https://github.com/charmbracelet/bubbletea

Regarding the options of scheduling, which I don't need but totally understand others might, I want to point out that it creates some complications when designing the UX, for instance, if creating threads is mainly interactive, params are stale and can not be used, or have to be used before knowing if you actually are sending it or not, feels a bit odd, perhaps scheduling only being available for regular tweets or replies which are more simple is totally fine for now, just be aware of this.

I would also say that if you are going to implement scheduling one feature that I don't know if it's implemented or not would be a character check instead of just failing to send, so that it fails right when you make the schedule tweet command, not when it tries to send it and fails(assuming char length error).

Let me know what you think ;)

[devhindo]

For the non-params thing, I was following the syntax of the GitHub CLI tool if you are familiar with it. For example, it creates a GitHub repo like this gh repo create REPONAME --public --clone --gitignore Go --license it and it has other utilities you can check out their docs, it's pretty handy.

I also agree with you the x "Hello world!" should be preserved.

For the TUI x command, It's a great idea for taking the tool to the next level. I'm going with Option A with arrow navigation. Might as well create a combination of the two options or provide multiple ways for doing the same task to be more convenient.

About scheduling tweets idk I feel like I want to post something but I don't feel like posting it now, maybe in a few hours. Or, maybe I want to schedule something to be posted every day at a specific time. Some people may use the tool for advertising as example, on an enterprise level. This would be helpful and easily automated to post on its own when linked with some other software.

Also, I don't understand how the conflict is gonna happen in threads while scheduling tweets. Can you clarify? how params are could stale and what params exactly are you talking about? The initial idea was for regular tweets but might extend to threads as well. So, How exactly could this be odd?

No, character length checking is not implemented yet, but for sure I'm going to implement all sorts of validation before scheduling to be sure that the tweet is valid. I might also add a check for X Premium users and based on that I would add the necessary configurations for the logged-in user. All that said, It's going to be shipped with the text turning red feature when exceeding the limit we talked about later.

[adriangalilea]

For the non-params thing, I was following the syntax of the GitHub CLI tool if you are familiar with it. For example, it creates a GitHub repo like this gh repo create REPONAME --public --clone --gitignore Go --license it and it has other utilities you can check out their docs, it's pretty handy.

I also agree with you the x "Hello world!" should be preserved.

1. I think these 2 are incompatible with each other, at least in a clean and convenient way.

2. The github CLI has several commands in which none of them seems to be more important than the rest so it makes sense to have different keywords, but not in this case.

My point: if you preserve x tweet and x thread what happens when you want to tweet that starts with "tweet"?, x tweet, does this produce a tweet with the word tweet or does it fail since it's a command without content? I just rather do -thread or -t to preserve the lack of - and assume whatever follows x is the tweet body.

About scheduling tweets idk I feel like I want to post something but I don't feel like posting it now, maybe in a few hours. Or, maybe I want to schedule something to be posted every day at a specific time. Some people may use the tool for advertising as example, on an enterprise level. This would be helpful and easily automated to post on its own when linked with some other software.
Also, I don't understand how the conflict is gonna happen in threads while scheduling tweets. Can you clarify? how params are could stale and what params exactly are you talking about? The initial idea was for regular tweets but might extend to threads as well. So, How exactly could this be odd?

Let me recap to make clear what I mean:

1. You can schedule like so:x "Hello world" -d 12

posting a tweet on the 12th of the current month at the current time of the machine

2. You can start interactive thread mode like so: x -t (or x thread it doesn't matter for this argument, but you know I favor the former)
   Which starts the interactive mode in where you create you thread as we explained earlier in this issue,

Then imagine you wanted to combine the 2, you gotta first think of the scheduling and then on the content of the thread, it's backwards to me, in fact until I wrote every piece of the thread I don't even know if I want to publish it. so in my mind, doing x -t -d 12 feels odd because I scheduled a tweet that's yet to be written and that it may not be written(aborted).

So it makes more sense to me, that interactive mode... let's you specify the schedule... interactively through another option in the interactive flow... just like you can press a keyword/option for sending, appending a new one or aborting, you can just have another one for scheduling.

Also, addressing your scheduling design, let me give you my thoughts there too.

first I would change the -t flag thing to be a longer command as follows
x tweet -c "hi" -w 2d5h6m7s -d 2024-12-12 -t 3:34pm

-c for tweet content

-w This is a wait flag that is optional for scheduling future tweets, in the previous example it's set to schedule the tweet to be posted after 2 days, 5 hours, 6 minutes, and 7 seconds (I might exclude the seconds). It also accepts multiple syntaxes like for example 5h, 2h6m, or 10m. As I said it's an optional flag and its default value is 0 indicating that the tweet should be posted now.
-d and -t: date and time is an alternative for -w to indicate the day and time to post the tweets. Also, the default value if they don't get passed is now. You can't also enter -w with them, You gotta choose one, either the > -w flag or -d and -t. If you entered just -t I'm assuming you want the tweet to be posted today in the specified time. and ofc errors will rise if you entered a date in the past.

I think you can combine all this into one and do better parsing, I've seen plenty examples

For instance I much rather have a single param for scheduling that I have to remember that let's me:

now tomorrow mon/monday
now+5h
today,12:00
2024-12-12,12:00
1st 2nd
eoy end of year eom end of month
soy start of the year som start of the month

I think -s is the right one for scheduling

So tweeting hello world next monday becomes
x -s monday hello world or just for readability x -s monday "hello world"

I see perhaps some problems if people want to use any param inside the tweet for a completely unrelated reason, but that could be handled by forcing the use of "" quotes on the tweet body when using params, to ensure none of the inside of the quotes get's parsed as params.

And of course, all this may be a bit too much to implement, so can be incrementally adopted, I just think 1 single param for scheduling is better than 3, both for a cleaner code base, to streamline usage and to remember easily.

Also, every time I think of scheduling I remember this which seems to me an amazing UX, just in case you want to consider.