Proposal for design of CLI

[KunaPrime]

Checklist

• [x] I searched the :help documentation using / for helpful information
• [x] I have read the frequently asked questions
• [x] I did not find any similar issues in the issue tracker
• [x] I prefer making an issue instead of using discussions, Matrix or Telegram

Addition or change In order to better control vieb instances form command line and to enable better scripting support make CLI that reuses existing commands and actions using already established mapping syntax:

vieb --execute "<:command><action> args"

for example if one would like to open url from clipboard in specific instance(defined by datafolder):

vieb --datafolder=<some direcotory> --execute "<:tabnew><openFromClipboard>"

additional changes

variables with this model and current use templates (vieb://help#use) it would be possible for example to query currently opened page title:

vieb --datafolder=<some direcotory> --execute "<useCurrentTitle>"

it may be more natural to give namespace for variables like <var.currentTitle> or <info.currentTitle> or maybe introduce value returning commands such as <:currentTitle>.

security

in order to prevent specific instance to be controlled via CLI additional startup option can be introduced --lock that disables CLI completely.

[Jelmerro]

I like the general idea here, this would make a lot of extra integrations possible. I would like to change this a tiny bit in that your suggestion seems to be to introduce a mix of the current command syntax into this new --execute flag, which in my ideal case would be exactly the same as running commands, but then from the CLI. So instead of doing -- execute "<:tabnew><openFromClipboard>", it would be -- execute ":call <:tabnew><openFromClipboard>". This would mean two things, both of which I would say are an advantage: first it means the syntax is the same for regular commands as it is for this new execute flag, without losing functionality, as all your current examples would work by prefixing them with :call, and secondly, it would make running any other command via this --execute flag possible, which opens up a whole range of different functionality, such as :set, :map and basically any command you would like, while still being able to run actions with :call.

As for getting data this way, I am considering if I would prefer to have a separate flag, such as the one proposed in #155: --get-val, as that would explicitly show that the intent is getting a variable, and also allow getting variables for which there is no use yet, though it would mean an additional piece of syntax that isn't there inside Vieb, so I might prefer just having --execute and then return back whatever notifications that gives into the CLI. With the addition of a new command that could notify the values of use "variables" perhaps.

Let me know your thoughts on this and if I missed anything here, all ideas are welcome at this stage.

[KunaPrime]

i completely agree that unification is beneficial and use of :call and friends is much more powerful so i'm all for it!. Initially i haven't fully realized that :call is "symmetrical" to :set and :map so that was the reason for omission.

As for --get-val i think it is limited, because it is difficult to know all the variables and on the other hand, mapping form command to the notification/value is natural. As you have said, :set useragent for example is notifying it's value that should in --execute be only passed back to command line. Now i'm unsure how are internals of notifications are made (or for :set and friends), so some reworking of them should be needed to ensure that all commands are returning/notifying something (even if it is to be ignored).

Also i think that if we aim for uniformity (which i think is right direction, less surprises) than one should also consider custom commands for which --get-val would not easily work (without some additional registers or similar acrobatics)

[Jelmerro]

I think the --execute flag would fulfill all the requirements of both getting runtime variables, as well as interacting with Vieb from outside, thanks for the great suggestion, I'll try to implement this soon.

[Jelmerro]

Implemented in 10.4.0 :tada: