Add command line argument for command(s) to run on startup

[cipharius]

This is a feature request for a new command line flag for the smos executable.

Idea is to allow specifying what command(s) to run on launching the smos TUI, so that one could start smos directly in some specific view. For example, one could launch smos --command reportNextActions and TUI would show next action list on startup. Other example could be launching smos with smos --command selectBrowserProjects, to launch smos directly in projects view.

I think this should be implemented as a command line argument, because that gives the flexibility of starting smos via shell aliases or desktop keybindings in a specific state.

---

Goal: Allow user to start smos TUI in a specific view and configure which is the default view.

Objectives:

• Update code to make it possible to programmatically specify startup view.
• Introduce configuration option starting-view which allows user to specify which is the default starting view.
• Introduce environment variable SMOS_STARTING_VIEW which allows user to override the default starting view.
• Introduce command line argument --starting-view, which allows user to override both of previous default view definitions.
• None of startup view options apply, if smos is started off of a specific file, example: smos file.smos
• Update documentation to include list of all available startup views.

[NorfairKing]

Hi! Thanks for filing this :D I don't think I've seen your avatar here before, nice to have you here!

I like this idea, but I'm a bit hesitant because it only works for commands that take no arguments, and before long someone will want to be able to run multiple commands and that might all get a bit hairy.

I think this should be implemented as a command line argument, because that gives the flexibility of starting smos via shell aliases or desktop keybindings in a specific state.

If we do this, it'll be all three as usual: flags, env vars and config file, not just one of the three.

Just thinking this through a bit further: If I understand correctly, what you really want is to be able to choose a startup view, rather than to be able to run a command, is that right? Which views are you looking to be able to start with?

EDIT: Also: smos-query, together with yank might already do a lot of what you want.

[cipharius]

I've been here year ago and decided to give smos another go.

The specific workflow I imagined is starting smos either in project view or some report view from desktop keybindings. That is, one keybinding to view all next actions (but still be able to use rest of TUI actions), other keybinding to open project list.

It's not that big of an issue, just more keys and distractions to get to the view I need. I suppose that always starting smos in next actions view would be good enough, as other views need to be checked less commonly.

[NorfairKing]

@cipharius

I've been here year ago and decided to give smos another go.

What made you stop before?

It's not that big of an issue, just more keys and distractions to get to the view I need. I suppose that always starting smos in next actions view would be good enough, as other views need to be checked less commonly.

I was thinking more to allow starting in different views instead of allowing starting with a given command. I personally have alias sm=smos, so the combination for me is <open terminal>sm<enter>rr which was good enough so far but it could indeed be improved.

I suppose that always starting smos in next actions view would be good enough, [...]

You'll probably want to use the work report instead, by the way. rr is the default keybinding.

[cipharius]

I stopped mainly because of too busy work schedule to figure out self organization workflow in parallel. Now I'm giving GTD like approach another attempt.

I also considered specifying views instead of commands, but wasn't sure how smos internally handles different views. If you say that starting in a specific view is simpler, then I think it would be equally good if not better. Commands can cause mutations to workflow files which wouldn't make sense as startup actions, so views make more sense.

As for views, how would user specify one, or know which are available? They probably need to be listable somehow, similarely how commands can be easily listed within TUI.

[ketzacoatl]

I was thinking more to allow starting in different views instead of allowing starting with a given command.

:heart: this would be nice!

[NorfairKing]

@cipharius I was thinking of having something like --starting-view next as a flag, SMOS_STARTING_VIEW=next as an env var and starting-view: next in the config file. We can add autocompletion on the command-line to make this listable.

What do you think?

Commands can cause mutations to workflow files which wouldn't make sense as startup actions, so views make more sense.

Excellent point, I hadn't even considered that.

[cipharius]

Those settings look good. I assume the precedence of those is: CLI argument over ENV variable, over configuration value?

Completion sounds good, although would be good to include --list-views command line flag, for use with dumber/unsupported shells.

[NorfairKing]

Those settings look good. I assume the precedence of those is: CLI argument over ENV variable, over configuration value?

Jup that's right

Completion sounds good, although would be good to include --list-views command line flag, for use with dumber/unsupported shells.

Can't do that, but we can make docs about it on the docs site.

[cipharius]

What design choices limit such command line flag?

I imagine such list be part of smos TUI, so that it's dynamically generated from the concrete version's capabilities. That way views would be defined in haskell source, instead of both maintained in source and in docs.

[NorfairKing]

What design choices limit such command line flag?

Well for one, things starting with -- are options, not commands. You could argue for a command list-views but that's probably making things more complex than they need to be.

I imagine such list be part of smos TUI, so that it's dynamically generated from the concrete version's capabilities. That way views would be defined in haskell source, instead of both maintained in source and in docs.

Docs are generated to be correct anyway, that's not a concern. You can see this in smos-docs-site.

[cipharius]

Then documenting the option seems good enough, especially since it won't be nescessary to use often, or at least to check it's available values.

[cipharius]

Seems like this discussion has all the nescessary details to get a PR going.

To summarize the goal and objectives of this issue:

Goal: Allow user to start smos TUI in a specific view and configure which is the default view.

Objectives:

• Update code to make it possible to programmatically specify startup view.
• Introduce configuration option starting-view which allows user to specify which is the default starting view.
• Introduce environment variable SMOS_STARTING_VIEW which allows user to override the default starting view.
• Introduce command line argument --starting-view, which allows user to override both of previous default view definitions.
• None of startup view options apply, if smos is started off of a specific file, example: smos file.smos
• Update documentation to include list of all available startup views.

If these look good, I'll update original message to include the summary. Then anyone up to it can create a PR. I would be interested in giving it a shot myself, but probably not in the upcoming days.

[NorfairKing]

If these look good, I'll update original message to include the summary.

Yes looks great. You'll see that fitting these thing in will feel natural given what's already there..

Then anyone up to it can create a PR. I would be interested in giving it a shot myself, but probably not in the upcoming days.

Go for it! I also don't have too much time to donate at the moment.

[NorfairKing]

PR still welcome