TODO

   1                                                         -*- mode: outline -*-
   2
   3 * Competition
   4 Look at the alternative and provide a comparative chart.
   5
   6 * --clon-error-handler=debug
   7 Emulate the Lisp debugger by computing restarts. THe real debugger is too much
   8 for the casual user.
   9
  10 * I18N
  11
  12 * Have a look at CMUCL
  13 It has built-in search-lists and wildcard match that could be useful for the
  14 path options.
  15
  16 * Provide a do-cmdline-option (without the s) macro
  17 for repeatedly getting one specific option (and doing BODY on it) until none
  18 is left on the command-line. This could be useful for processing options
  19 appearing several times (for instance, some programs like to have several
  20 calls to -v in order to increase the verbosity level).
  21
  22 Maybe also provide a getopt-last, or a key to getopt that would trigger
  23 warnings if an option is used several times but it's not supposed to. In such
  24 a case, the key would let the programmer decide on whether to discard the
  25 first or last ones.
  26
  27 * Support for option aliases
  28 An option could have several names instead of just one.
  29
  30 * Support for multiple environment variables
  31 An option could be associated with a list of environment variables instead of
  32 just one. Possible uses would be handling both DEBUG and NDEBUG (see below),
  33 but also program-specific versions of otherwise general variables, like trying
  34 MYPROG_NDEBUG first, and NDEBUG next.
  35
  36 * Support for value post-processing
  37 I'm especially thinking about multiple environment variable support, but maybe
  38 elsewhere. For instance, we could implement a --debug opton associated with
  39 a DEBUG env var, and also/or with a NDEBUG env var for which we should
  40 complement the conversion. Now the question is do we want to post-process the
  41 conversion value, the initial string value, or both ?
  42
  43 Another related thought: value post-processing could mean value
  44 canonicalization (especially useful when in the debugger, you're invited to
  45 provide another value). For instance, in path options, the converter handles
  46 ~/ abbreviations. However, this is not valid when typing a value directly,
  47 which is a shame.
  48
  49 And another post-processing-related idea: a :variable property to
  50 automatically setf a variable to the value of an option once it is retrieved.
  51
  52 Now if all options have post-processing, a simple (do-all-cmdline-options)
  53 macro could do all the work (just getopt and execute the associated
  54 post-process).
  55
  56 * Support for resource files ala X11
  57 This could be used to provide values for options depending on the
  58 application's class/name.
  59
  60 * Treat empty env vars as options called without their (optional) argument
  61 With the restriction that there's no notion of an env var set without
  62 argument. There's only empty arguments. This will lead to problems if the
  63 option is supposed to accept empty strings.
  64
  65 * Support for dynamic default value / fallback
  66 computed at run-time from a lambda expression for instance. But is this
  67 different from supporting post-processing ?
  68
  69 * Improve advanced usage support
  70 Maybe we need a way to support declarative definition of a synopsis *tree* for
  71 applications wanting to do things like "prog [options] cmd [options]" or even
  72 more complicated stuff.
  73
  74 There is also the problem that built-in options are duplicated every time we
  75 create new contexts (see section 5 "Advanced Usage" in the Clon User Manual).
  76 We would like those built-in options to apply on all sub-contexts (hint: we
  77 need a true notion of sub-context), but also with the ability to be overridden
  78 in those sub-contexts. This could also be extended to non built-in options.
  79
  80 * Extend abbreviated option matching to dash-parts
  81 e.g. --f-n == --family-name.
  82
  83 * Extend the path option class to accept wildcards in pathnames
  84 and expand them into actual directories.
  85
  86 * Extend the path option class to not ignore a final colon
  87 Like TeX variables, this would mean to append the built-in path after the
  88 user-specified part.
  89
  90 * Study POSIX behavior for cmdline options
  91 See if we can provide a POSIX compliant mode, that would be triggered by
  92 POSIXLY_CORRECT, POSIX_ME_HARDER, or other means (cmdline options?)
  93
  94 * Support for shell completion
  95 Implement automatic generation of whatever is needed for shell completion of
  96 options (zsh in particular, zcomp I think it is).
  97
  98 * Finer grain for conversion errors
  99 Currently, converters are supposed to raise an invalid-argument error, but we
 100 might want something more powerful (like handling a whole conversion-error
 101 hierarchy). For instance, when a path is wrong, we would like to provide a
 102 restart for modifying just the faulty path element. However, this is not
 103 currently possible because invalid-argument errors are trapped and converted
 104 to invalid-cmdline-argument or invalid-environment-value ones. So we can't
 105 benefit from all the restarts that we could define at the lower-level.
 106
 107 * Better detection of short packs
 108 When parsing a short call, we try a known option, a known option with a sticky
 109 argument, a pack, and then barf. Sometimes, a pack can be mistaken for a known
 110 option with a sticky (however invalid) argument. For instance, suppose we have
 111 a -d switch and a -v flag. Using -dv will lead to an invalid argument to -d,
 112 whereas the user probably meant -v -d (or -vd which works). We could improve
 113 the detection of this situation by catching the invalid argument error, and
 114 then trying a pack instead of immediately reporting the error.
 115
 116 * Better advertisement of short packs
 117 [ See also above ] When Clon computes the pack string for the synopsis, we
 118 should put flags first in the pack, because it does not make nay sense to
 119 start a pack with a valued option (the pack would be seen as an option with a
 120 sticky argument first).
 121
 122 * Extend the [items-]separator face property
 123 Item separation would ideally depend on what's before or/and after the item
 124 being displayed.
 125
 126 * Special --no-<name> option for switches
 127 (and probably switch-based options).
 128 For instance, you would have -d / --debug and +d / --no-debug.
 129
 130 * Support help string formatting for more than ttys
 131 For instance, it would be good to be able to generate texinfo, man (groff)
 132 etc. Currently, it is not very clear to me where exactly the limit between
 133 themes and format "drivers" stands. I think that what's in a theme depends on
 134 the driver you use (e.g. colors make sense for a tty driver, but not for a
 135 groff one).
 136
 137 * Support for GUI-based options browsing
 138 I'm quite proud of this idea ;-) Joe uses program for the first time, so he
 139 types "program --gui-help" and gets a GUI with all available options, their
 140 help strings as bubbles, the possibility to select them, provide values etc.
 141 He plays around and then clicks "Go", and the program continues with with the
 142 appropriate command-line (you can already have different contexts in CLon).
 143 Cool hey ?
 144
 145 * Provide a negated long form as well ?
 146 ++debug
 147
 148 * Store all release names in a hashtable
 149 and provide a short bio, with option --clon-about=RELEASE