mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2020-02-17 12:26:09 -04:00
parent d2e0996c04
commit d04e6aac6c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 24 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

24
doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2020-02-17T16:06:26Z"
content="""
My design process for this feature included almost getting stuck on wanting
some kind of types for the values, and way to track which options are
required, or exclusive of other options, or dependencies of other options,
etc. All stuff that eg, an applicative option parser can support quite
well, but it would complicate the external protocol enourmously, if it
could be represented at all in it. So I had to eliminate all that.
I think it's fairly uncommon for tab completion to do anything special
about required parameters, or even mutually exclusive options (although
git-annex tab completion does handle the latter), and while I can imagine
a gui interface marking an input field as required, it seems
that would be the least of its problems if it doesn't know what kind of
control to use for the field?
It would be easy to add --whatelse-json, but it would be limited to the
name, a description of the purpose of the field, and maybe a description
of the expected value or list of valid values.
I'm unsure about the utility of that..
"""]]