Open gedw99 opened 1 month ago
Hi, @gedw99, I am glad you are interested in the project! It would be very cool if you could improve task-tui and I would like to participate a little bit in discussing those improvements.
Could you please provide some more details about what exact completions you are in mind?
I think the primary goals of task-tui are to make it easier to read summaries of tasks, choose which tasks to execute, and remove the need to remember specific commands. Therefore, the args necessary for using task-tui at the moment are the common go-task args, which adjust the execution flow and the path to a specific taskfile. The local shell usually assists with the second thing.
Another thing that might be useful is the completion of task commands in the filtering mode.
Do you mind if I do it in a Google doc ?
just easier to be more thorough…
converging all 3 things requires some deliberate design approach
Do you mind if I do it in a Google doc ?
Sure, it's a great idea!
Ok I wrote up a few thoughts on it.
https://docs.google.com/document/d/1BdkUJ_8CPK61VN4UlZ7bbdYc3rMCDu6hXNTt02RbjFI/edit?usp=sharing
I am on Telegram btw so we can discuss etc, setup a repo and get going if you feel the idea is something you like.
The telegram is on my Profile: https://github.com/gedw99
I've read your proposal, Gerard. Thank you and sorry for the delay!
Did I understand correctly that you want to sync changes between local and remote files? In that case, the task seems interesting, but I'm not sure how GUI or TUI tools can help with it. Maybe it's better to find or develop a more generic solution. How do you feel about that?
I need to back track;
The goal is to make it easy for devs and and devs to write tasks and edit task with a GUI. So both you and the other guy built a task parsers and golang strict model etc and then renderer.
But task is written in YAML, so then perhaps, I feel, a LSP written in golang that understands yaml is a better design approach. Thee already exist, and the LSP is still dumb though.
Local and remote sync that I am going on about, is to allow the TASK yaml to NOT need to be turned into some abstract golang struct, but for there client and servers to send literally yaml itself. The same yaml that makes up Task files. It's just sending fragments of YAML.
Once that works you can write a Task editor that is just doing exactly what Task does with JSON Schema. This is how Task validates itself. Or just use the AST at https://github.com/go-task/task/tree/main/taskfile/ast
Either way, the main thing is that the GUI has all of the task code and AST / JSON schema knowledge and so its easy to then write a GUI that can fully know when should or should not be next below an existing task fragment line.
This makes it very easy to write a task editor that evolves as Task evolves and so have full knowledge. For example tasks has imports of other tasks !. hence, my feeling that the only way to write a Task Editor is to fully have the task model on both sides.
Syncing then is just a matter of pushing literally yaml as a message then. We sync because we can then save it to disk. But also once it's all just yam messages you can easily do collaborative real time sync too. That yields other potential things with Task that we probably dont even know yet in terms of use cases . A task runner is so so useful in so many contexts IMHO:
You could say that then you can run Task inside a Browser or the GUI editor itself that edits task. And yes you could.
I hope I have explained mewl better this time. It's not easy sometimes, and please feel free to ask me if there is misunderstanding.
hey Aleksander
Your tui works really well for me. I like that arg passing package you're using. I will try to extend task-tui so that we get completions.Do you know if it can do completions btw ?
Also, https://github.com/titpetric/task-ui is a go-task web GUI, that works with Docker for remote management. It allows you to remotely control Task via a Browser.
The task-ui binary works great for Browser based control, but I also would like CLI control of that server running go-task.
So, I am contemplating if I can extend task-tui so that I can remotely connect to go-task running on a server, which is also running task-ui.