TODO

   1                                                         -*- mode: outline -*-
   2
   3 * Copyright (C) 2010, 2011, 2013 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 Cf. also current bug in clon-search-path default computation, which is done at
  74 compile time if defsynopsis is used as a toplevel form.
  75
  76 * Improve advanced usage support
  77 Maybe we need a way to support declarative definition of a synopsis *tree* for
  78 applications wanting to do things like "prog [options] cmd [options]" or even
  79 more complicated stuff.
  80
  81 There is also the problem that built-in options are duplicated every time we
  82 create new contexts (see section 5 "Advanced Usage" in the Clon User Manual).
  83 We would like those built-in options to apply on all sub-contexts (hint: we
  84 need a true notion of sub-context), but also with the ability to be overridden
  85 in those sub-contexts. This could also be extended to non built-in options.
  86
  87 * Extend abbreviated option matching to dash-parts
  88 e.g. --f-n == --family-name.
  89
  90 * Extend the path option class to accept wildcards in pathnames
  91 and expand them into actual directories.
  92
  93 * Extend the path option class to not ignore a final colon
  94 Like TeX variables, this would mean to append the built-in path after the
  95 user-specified part.
  96
  97 * Study POSIX behavior for cmdline options
  98 See if we can provide a POSIX compliant mode, that would be triggered by
  99 POSIXLY_CORRECT, POSIX_ME_HARDER, or other means (cmdline options?)
 100
 101 * Support for shell completion
 102 Implement automatic generation of whatever is needed for shell completion of
 103 options (zsh in particular, zcomp I think it is).
 104
 105 * Finer grain for conversion errors
 106 Currently, converters are supposed to raise an invalid-argument error, but we
 107 might want something more powerful (like handling a whole conversion-error
 108 hierarchy). For instance, when a path is wrong, we would like to provide a
 109 restart for modifying just the faulty path element. However, this is not
 110 currently possible because invalid-argument errors are trapped and converted
 111 to invalid-cmdline-argument or invalid-environment-value ones. So we can't
 112 benefit from all the restarts that we could define at the lower-level.
 113
 114 * Better detection of short packs
 115 When parsing a short call, we try a known option, a known option with a sticky
 116 argument, a pack, and then barf. Sometimes, a pack can be mistaken for a known
 117 option with a sticky (however invalid) argument. For instance, suppose we have
 118 a -d switch and a -v flag. Using -dv will lead to an invalid argument to -d,
 119 whereas the user probably meant -v -d (or -vd which works). We could improve
 120 the detection of this situation by catching the invalid argument error, and
 121 then trying a pack instead of immediately reporting the error.
 122
 123 * Better advertisement of short packs
 124 [ See also above ] When Clon computes the pack string for the synopsis, we
 125 should put flags first in the pack, because it does not make nay sense to
 126 start a pack with a valued option (the pack would be seen as an option with a
 127 sticky argument first).
 128
 129 * Extend the [items-]separator face property
 130 Item separation would ideally depend on what's before or/and after the item
 131 being displayed.
 132
 133 * Special --no-<name> option for switches
 134 (and probably switch-based options).
 135 For instance, you would have -d / --debug and +d / --no-debug.
 136
 137 * Support help string formatting for more than ttys
 138 For instance, it would be good to be able to generate texinfo, man (groff)
 139 etc. Currently, it is not very clear to me where exactly the limit between
 140 themes and format "drivers" stands. I think that what's in a theme depends on
 141 the driver you use (e.g. colors make sense for a tty driver, but not for a
 142 groff one).
 143
 144 * Support for GUI-based options browsing
 145 I'm quite proud of this idea ;-) Joe uses program for the first time, so he
 146 types "program --gui-help" and gets a GUI with all available options, their
 147 help strings as bubbles, the possibility to select them, provide values etc.
 148 He plays around and then clicks "Go", and the program continues with with the
 149 appropriate command-line (you can already have different contexts in CLon).
 150 Cool hey ?
 151
 152 * Provide a negated long form as well ?
 153 ++debug
 154
 155 * Store all release names in a hashtable
 156 and provide a short bio, with option --clon-about=RELEASE
 157
 158 * Pascal would like a simple way to declare options ala lambda list
 159 For instance define-main-function (&key opt1 opt2 ...), and be done with it.
 160
 161 * Cf. ECL's asdf implementation of make-build.