TODO

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